Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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....)
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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...
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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
Find more inspiration, events, and resources on the new Adobe Community
Explore Now