Skip to main content
Fred.L
Inspiring
May 13, 2025
Question

About asynchronousExportFile()

  • May 13, 2025
  • 3 replies
  • 1849 views

Hi guys, experts, fellows

 

I've been enjoyed scripting for some time and faced erratic behavior regarding asynchronousExportFile().

 

The issue :

asynchronousExportFile() works usually fine but 1/10th of the time (not sure about the real ratio. just a guess) exports doesn't go through and is stuck at 0% or 99% freezes ID, cursor is spinning constantly etc.

 

Me wondering:

Is there a way to "protect" / help / do something to increase the ratio of success?

 

As you know, regular export does prevent us to use ID when exporting. I'm dealing with dozen of files a day, regular export is just not a viable solution.

Force quitting ID is annoying, as you have to open it again/ recover the files /save /quit /open again and sometimes even set up again a few things (last shortcuts, Quick-Apply reset etc.)

 

Any thoughts on the matter?

Thanks for your personal insight

3 replies

Community Expert
July 6, 2025

Hi @Fred.L ,

hm, instead opening the exported PDF file in Acrobat, you could show the folder / directory where the exported file is exported to in macOS Finder or Windows Explorer. At the end of the export process just add:

 

// Show the folder of the exported file
// The folder will pop up
exportPrintFile.parent.execute();

FWIW: File.execute() and Folder.execute() was broken in a recent version of InDesign 2025 v20.4.0, but will work in the fixed InDesign 2025 v20.4.1.

 

Also: Does the issue happen when you try to overwrite an already written PDF file?

This would be a big problem if the "old" PDF was opened in Acrobat just before.

And maybe that is leading to a 0-byte file size…

 

Regards,
Uwe Laubender
( Adobe Community Expert )

Fred.L
Fred.LAuthor
Inspiring
July 9, 2025

Thanks for the tip, I didn't think of opening the folder. It may be more convenient in the end. I need to think about it a bit more.

 

I haven't found anything troublesome when it comes to overwriting a file, even if it's already open. As a matter of fact, this scenario has happened before and the only "thing" to do is to not forget to close/ open again the PDF so the "new" version comes up.

 

As for the extra tests, issues happened recently even with a single PDF asynchronous export, no queuing anything, not doing anything else than watching the progression moving to 99% and fail.
I've decided to use regular export when I wanted to make sure it goes through without crashing and it works as a charm. Very robust. 

It becomes very hard not to think it's a problem of asynchronous export 😕😕 

leo.r
Community Expert
Community Expert
July 9, 2025
quote

It becomes very hard not to think it's a problem of asynchronous export 😕😕 


By @Fred.L

 

Yes, problems with asynchronous export are being reported once in a while.

 

I'm still not sure about the following two things from reading your posts:

 

-Does the problem happen only when using scripts, or also when you export PDF manually?

-When using scripts, do I understand correctly that if you do not use the viewPDF option, then the problem never happens?

leo.r
Community Expert
Community Expert
May 14, 2025
quote

The issue :

asynchronousExportFile() works usually fine but 1/10th of the time (not sure about the real ratio. just a guess) exports doesn't go through and is stuck at 0% or 99% freezes ID, cursor is spinning constantly etc.


By @Fred.L

 

Does this only happen when the stuck file is in a batch, or does it also happen when you export individual files?

Fred.L
Fred.LAuthor
Inspiring
May 16, 2025

Hey @leo.r ,

Thanks for your reply

 

Now that you're pointing that out, it's very possible that this can happen only when I try to export a pdf  while there is one going on already. 

I'll be attentive to this and get back to say otherwise, if this is the case.

 

Besides not exporting multiple files, what  could you say to help with it?

I admit the big added value of asynchronous export is to be able to export files in a row

 

leo.r
Community Expert
Community Expert
May 18, 2025
quote

Now that you're pointing that out, it's very possible that this can happen only when I try to export a pdf  while there is one going on already.

Besides not exporting multiple files, what  could you say to help with it?


By @Fred.L

 

If that's indeed the case, then try to queue the tasks instead of running them concurrently. That is, fire one task, poll its progress, then fire the next one once the previous is done. Time-wise it probably won't be much different. 

 

Also, I'm not sure if you can queue upcoming tasks in advance (that is, create a task without actually running it, then fire it when needed), or that you must wait till the running task is finished and only then create the next task.

 

Other than that, I don't know what else can help as I'm not sure why you are running into this issue at all.

BarlaeDC
Community Expert
Community Expert
May 13, 2025

Hi,

 

Can you provide more information about how you are using the function? perhaps a script or snippet showing its use?

What about the documents, are they all roughly the same, are there any documents that have an obvious difference ( double the size....)

Fred.L
Fred.LAuthor
Inspiring
May 13, 2025

Hey @BarlaeDC ,

Thanks for stepping in

 

I sure can:

- Documents : I believe only big documents are creating issues. I'm working on books and Inlays/ Book blocks are most of the time within 100-400 pages.
- Size : Varies quite a lot. with lots of images (always unbedded). The total Links folder goes within 1-7Gb, sometimes even more. Indd files are from 50Mb to 600Mb. Print PDFs can go as high as 2.5Gb.
- Platform : MacBook M3 Max - 64Mb Ram - Sequoia 15.4.1 - 12/4  Cores - 40 graphic cores 

 

I'm using a big custom script for dealing with exports. See UI panel attached.

 

For the coding part, here's the part where I deal with the print PDF

    // Access and modify the PDF export Print presets =================
    var myJobOptionsPrint = gCol2e1.text;
    if (inPrRarSp.value == true)   {app.pdfExportPresets.item(myJobOptionsPrint).exportReaderSpreads = true} 
    else {app.pdfExportPresets.item(myJobOptionsPrint).exportReaderSpreads = false};
    
    // Set PDF export preferences
    app.pdfExportPreferences.properties = {
        pageRange : inPrPaSele1.text, // ========================
        effectivePDFDestinationProfile : gCol1e1.text,
        viewPDF : true,
        optimizePDF : false,
    }
    if (inExpPrefSync.value == true) {
    // Export the document with asynchronous method =================
    var exportPrintFile = setEditPrintPath.text + gFole1.text + "/" + gFe1.text + gExeInPr.text + ".pdf"; // Chemin de destination du fichier exporté
    app.activeDocument.asynchronousExportFile(ExportFormat.PDF_TYPE, exportPrintFile, false, myJobOptionsPrint, "", false);
    } else 
    {
… 

 

 

I'm pretty happy with it and the script itself appears to work just fine. Never had any error/ bad argument or else. It's just that sometimes, with no special pattern, the export goes into the background tasks and either doesn't start (stays at 0%) or is stuck at 99%.

If it's an "normal" issue that goes with the use of the inner behavior of the function, it's ok I guess. But if there is somehow something we could do to help it, well, I'm eager to know.


I've read a while ago (can't remember where/ who wrote it) a post of one Adobe expert who were talking about some very technical stuff on how PDF exports were done, and why multi-cores processors couldn't help speeding up the process. As far as I understood correctly, exports can only be done on one core. Since we, users, don't have to handle the cores, I would assume that if bad luck happens, the conjunction of an export on one core which was already busy doing something else on the computer would create some kind of overload and make the export impossible. That would probably not happen if the export is not asynchronous, just because of the way cores are handled.

That was my understanding then, took it for granted, and explains why I didn't ask about it sooner.

Now, as Confucius said  “He who asks a question is a fool for a minute; he who does not ask is a fool for life.”

 

Any feedback would be then well received

Thanks

Robert at ID-Tasker
Legend
May 13, 2025

@Fred.L 

 

InDesign, overall, is a single-threaded application. 

Number of cores doesn't matter - but helps for the whole system - only MHz and amount of RAM influences  InDesig's performance. 

 

https://indesign.uservoice.com/forums/601021-adobe-indesign-feature-requests/suggestions/32235082-support-for-multicores-performance?category_id=209251&page=2&per_page=20