About asynchronousExportFile()

[Fred.L]

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

[BarlaeDC]

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]

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]

@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-su...

[Fred.L]

Interesting,
Thanks for the link
I actually did vote ^^
just did some research and…

I guess going multicore must be like revamping Indesign in depth. I have little hope to see it coming in the next few years. Even Photoshop is falling beihind. It seems that it can only handle well 2 cores, and performances are dropping fast after two.

[Robert at ID-Tasker]

@Fred.L

I think, with InDesign, there is too many things to handle - or rather "follow" - at once.

Rendering text on the Page - or rather per Spread - isn't a big deal - TextFrames and formatting is in place already - but there are a lot of "links" - Hyperlinks, foot/end-notes, X-refs, Index markers, etc. 

And those would've to be synchronised between separately generated Pages / Spreads...

[leo.r]

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]

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]

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.

[Fred.L]

Hey,
Thanks for the tips, it helps thinking deeper about it

I'll give them a try and see how it goes

I've got a single script that exports PDFs based on checkbox choices. The main two of them that cause issues are for Book Inlays (big files then) that I want exported in PDF for Web and for Print. So when issue happens, it is basically this scenario:

-Checkboxes for exporting Print PDF and Web PDF are ticked

- Web PDF starts
- Print PDF is put on queue
- Web PDF export is  running nicely

- Once finished, Print PDF export should start but for some reasons is stuck at 0% or starts well but will be stuck at 99%

I'll try something exporting

- one PDF at the time, not both of them within one instance of the script

- Export both, but delaying the second by 10sec

I'll get back to give a feedback

[Fred.L]

As to feed a bit more the topic with some data…

Sometimes, exporting a PDF with asynchronous way (with the option to open the pdf created)  brings an error, saying that pdf file is either not supported or corrupted. 

I found the option to open the pdf very handy, as it says when the task is finished.

I wonder again whther there wouldn't be some kind of tight timing in the process that would create suche an issue.

Anyone has ever had the same problem?

[leo.r]

Sometimes, exporting a PDF with asynchronous way (with the option to open the pdf created)  brings an error, saying that pdf file is either not supported or corrupted. 

I found the option to open the pdf very handy, as it says when the task is finished.

By @Fred.L

I don't know why you get this error when using the option to open the created PDF automatically.

However, do you only need this option to determine when the task is done? Because you just can poll the task's status and percent done properties to obtain this info.

Also, do you ever have the issue of a corrupted PDF when you don't use the option to open it automatically?

[Fred.L]

Hey, 

Thanks for the reply,

I often find myself in a middle of demands that need very high reactivity. Having the pdf opened automatically is very helpful not to waste any second. I can share it as soon as it is out. I admit the argument may sound a bit overkill, but time is of the essence in our worflow, I must say.

I've neither had the issue of a possible corrupted file when I don't use the option to open it automatically, not when I don't use asynchronous export. In the meantime, something important, the pdf file size shows 0k. That leads me to think that the error message regarding the corrupted file comes from the fact that the creation process of the pdf didn't go through. The error message would then come from the fact that there is no real file to open., and therefore not be an issue of the option of "automatically open" but from something before, ie, the export.

[Laubender]

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]

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]

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?

[Fred.L]

Hey,

Thanks for the questions. 

I was going to answer them in a very confident way, but as I'm writing the answers, I actually think the issue may be more subtle than initially assessed.

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

Good question. It's been quite a while since I've used the manual way to export a PDF. On a regular basis, I mean. I may export about 40 PDFs per day, so going manually is a no-go now. It's hard to say for certain, but as far as I remember, it's always been there, even in the early times when I was doing exports manually. Hence, I'd say yes, it does also happen when exporting PDFs manually. As much ? That's something I'd like to verify. I believe I'm really noticing it because of the volume of PDF exports I'm doing; it makes it more visible. If I was only exporting a couple of PDFs per day, I wouldn't probably remember much.

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

Again, good point. I think the view PDF option only helps me see the issue as soon as it pops up.  But since I've always been using this option, how can I be sure of it? I believe it happens even if the view PDF option is off. But again, I'm going to check that out.

Thanks again for the comments; it helps me think out of the box and not take my own statements for granted.