Thank you for your response. I believe this is likely an API interface issue, and I'm afraid this problem can only be resolved by Adobe officially. ... View more

It is said that InDesign CC 2017 version supported this, but later versions have had issues. I dont understand why this bug still hasnt been fixed after so many years of InDesign iterations. ... View more

Thank you to @m1b  for your help. I have successfully completed the code to change the tagColor. The previous failure was caused by other errors in the code. Thanks again!     var doc = app.activeDocument; var xmlTags = doc.xmlTags; for (var i = 0; i < xmlTags.length; i++) { if (xmlTags[i].name == "A") { xmlTags[i].tagColor = 1766025324; break; } }   ... View more

@m1b Thank you once again. You and Bob are just like Doraemon. ... View more

@m1b I added two lines to the script to change item.name: javascriptCopy Code var newName = 'New Text Box Name'; item.name = newName; However, it didn't work because the text box is not in a selected state. What are some good ways to solve this problem? Thank you! ... View more

Thank you very much to @m1b  for the help, the problem has been resolved ... View more

My idea is to use scripting to quickly switch between different panel positions and sizes. The solution provided by @Robert at ID-Tasker could partially address this issue, but scripting might be more flexible and faster. However, I feel that scripts may not be able to obtain this information Thank you for your help. ... View more

@Robert at ID-Tasker  I apologize, but due to confidentiality reasons, I cannot share screenshots of the files provided by the client. Please accept my apologies for this limitation.   However, I can provide a detailed explanation of the content. The document in question is a catalogue spanning several hundred pages, containing a significant amount of text and graphics. The graphics include various formats such as TIFF, PDF, EPS, etc. Typically, each page contains dozens or even hundreds of linked graphics. To cater to different publishing requirements, these catalogues often include links in the same name but different color modes, such as Gray, CMYK, and RGB. Consequently, three separate PDFs are generated: one in RGB mode, one in Gray mode, and one in CMYK mode. After meticulously proofing and publishing the PDF in RGB mode, the next step is to update the links to generate PDFs in Gray and CMYK modes. Additionally, each mode has its subfolders, further increasing the complexity of the process. The total number of links often exceeds ten thousand, hence my pursuit of efficiency.   And furthermore, I find myself caught in a peculiar cycle: whenever I encounter tasks that require repetitive completion, I invest a significant amount of time in writing scripts or plugins to reduce the workload. However, once the workload is reduced, it grants me ample free time. Subsequently, I use this free time to write more scripts or plugins to further reduce the workload.   Well, I admit it, I am the Ouroboros of productivity...   Once again, I apologize for the inability to share screenshots of the document. I am deeply grateful for your assistance and understanding. ... View more

I am planning to use the following code to decide whether to use app.doScript: if (undoCheckbox) { app.doScript(main, ScriptLanguage.JAVASCRIPT, undefined, UndoModes.FAST_ENTIRE_SCRIPT, "Update Links"); } else { main(); } ... View more

From my testing, I found that using UndoModes, regardless of the parameter value, significantly increases processing time. Therefore, I have no choice but to abandon its usage. Regarding the topic discussed by @m1b , "Why is manual link folder replacement faster than script in InDesign?", we have successfully reduced the processing time of the script compared to the native functionality. So, we should express our gratitude for your participation and assistance. ... View more

  I tried using the method of editing .idml files five or six years ago, and it has two issues: Firstly, saving as an idml file takes a long time, and secondly, opening the idml file after editing takes even longer. So, this method might not be the best approach for modifying links. Editing idml files is typically applied in cases where third-party plugins are used, and some hidden characters or links cannot be modified. In such cases, editing idml files is a good method. Additionally, if the code we're discussing includes: app.doScript(main, ScriptLanguage.JAVASCRIPT, undefined, UndoModes.FAST_ENTIRE_SCRIPT, "Update Links"); This code will also significantly increase the processing time. Therefore, when dealing with a large number of link changes, I tend to avoid using UndoModes. ... View more

The code provided by @rob day: links = app.activeDocument.links.itemByRange(si,li).getElements(); Took 9724.496 seconds to execute, and I nearly went crazy during testing. After analyzing it, I came to the following conclusions: This segmented retrieval method indeed reduces memory usage because it only extracts a small portion of link objects each time, which is relatively more efficient. However, in practice, each retrieval operation for link objects involves interaction with the InDesign engine, introducing certain overheads including execution time and computational resources. On the other hand, the previous method, although retrieving all link objects at once, may consume more memory but reduces the number of interactions with the engine. Therefore, in most cases, the overall execution efficiency might be higher. Additionally, when processing links in bulk, the number of links in each batch is not the only factor affecting performance; other factors such as nested loops and specific operations performed on links will also impact performance. ... View more

There is also a possibility that the issue is unrelated to the UNDO history. Processing the segmented array would release memory as it processes, and this is the reason for the speed improvement. ... View more

Yes, the UNDO history is like a Ouroboros, ultimately leading to system crashes. Even when using InDesign’s built-in link panel to update a large number of links, it freezes. I think the discussion of our topic should serve as a reference for Adobe developers. ... View more

I suspect it’s related to undo. If you try Link.reinitLink first and then manually update all the links at once, you’ll find that disk usage gradually increases to astonishing levels, eventually causing a freeze. Segmentation isn’t due to array size, but rather due to memory usage during the relinking process, and it’s not waiting for memory usage to become too high before resorting to using inefficient disk space as cache. That’s why I keep testing frantically and come to the conclusion that the array needs to be segmented for processing. I can analyze the reasons, but I don’t have @rob day  knowledge base, so I can only suggest ideas and wait for @rob day to pull out the desserts from his pocket time and time again…   As for @m1b speculation that traversing the array takes some time, although it’s very small, it adds up when there are over ten thousand links, which has a noticeable impact, but it’s still not as significant as not segmenting the array ... View more

@rob day always has updated and better desserts (methods) in his pocket, thank you for your reply. But why don’t you just take them all out at once? Now I have to stay up late testing again… 🤣 ... View more

Batch exporting PDFs cannot disable preflight checks, otherwise quality accidents may occur.😅 ... View more

I have already attempted this method in another script called "InDesign Batch Export PDF". It noticeably improves speed but also has limitations, such as the inability to use Preflight Check. ... View more

  Final statistical report: Document size 752,016KB, 365 pages, with 40 links per page, totaling 14,595 links. As per guidance from @Peter Kahrel , among these, 729 are actual links, while the remaining 13,866 are pointers. ======================================================================= Using @m1b  method, due to the ineffectiveness of directly using link.update() in the code, the reinitLink method was first employed to change the links, taking 26.133s. Then, updating the links using link.update() in a subsequent loop took 295.888s, totaling 322.021s, occupying 1GB of disk space. Since direct use of link.update() in the code wasn't possible, the method had to be abandoned after two script executions. Although this method was fast, I couldn't fully grasp the technical details, rendering it impractical. ======================================================================= I employed a method of splitting links.length: var links = doc.links.everyItem().getElements(); var batchSize = 100; var totalLinks = links.length; for (var i = 0; i < totalLinks; i += batchSize) { var batchLinks = []; var endIndex = Math.min(i + batchSize, totalLinks); for (var j = i; j < endIndex; j++) { batchLinks.push(links[j]); } for (var k = 0; k < batchLinks.length; k++) { var link = batchLinks[k]; This method took 275.817s and occupied approximately 1GB of disk space. ======================================================================= Using @rob day  code: var p = app.activeDocument.pages.everyItem().getElements() This method successfully reduced the processing time from over an hour to 280.275s and occupied approximately 1.1GB of disk space. ======================================================================= @rob day  solution had the shortest processing time and minimal disk space usage, making it the champion and the most technically superior solution. ======================================================================= My solution is experimental and requires extensive testing to ensure there are no bugs. However, its advantage lies in its flexibility in splitting links.length and adjusting batchSize according to different document requirements. ======================================================================= In conclusion, the three solutions differ mainly in specific details, but their techniques are similar, all involving dividing the entire document into smaller chunks for processing. The observed differences in processing time are not stable and should be taken as reference only. Once again, I extend my gratitude to @rob day @m1b @Robert at ID-Tasker @leo.r  and @Peter Kahrel  for their guidance and participation. Thank you. ... View more

  I added     link.update();     but it still doesn't work. I also included: for (var i = pageGraphics.length - 1; i >= 0; i--) { link = pageGraphics[i].itemLink; originalLinkURI = decodeURI(link.linkResourceURI); originalFileName = link.name; if (0 !== originalLinkURI.indexOf(originalFolderURI)) // no match continue; var targetLinkURI = originalLinkURI.replace(originalFolderURI, targetFolderURI); targetLinkURI = encodeURI(targetLinkURI); link.reinitLink(targetLinkURI); if (link.status === LinkStatus.LINK_OUT_OF_DATE) { $.writeln('is me'); link.update(); updatedLinksCount++; } } Still ineffective, cannot update immediately. However, I think this method might be the fastest way. ... View more

@rob day @Robert at ID-Tasker @leo.r  @m1b @Peter Kahrel This topic may be the most lively in the InDesign community recently. Thanks to all the teachers for their participation. I will test various solutions promptly and provide detailed test data. ... View more

for (var i = pageGraphics.length - 1; i >= 0; i--) { link = pageGraphics[i].itemLink; originalLinkURI = decodeURI(link.linkResourceURI); // Decode the link path originalFileName = link.name; if (originalLinkURI.indexOf(originalFolderURI) === 0) { // Check if the link is located in the original folder var targetLinkURI = originalLinkURI.replace(originalFolderURI, targetFolderURI); targetLinkURI = encodeURI(targetLinkURI); // Encode the target link path link.reinitLink(targetLinkURI); // Update the link path updatedLinksCount++; } } Successfully changed the link paths, but the files whose paths were changed weren't updated. You still need to manually click "Update All Links" in the Links panel. ... View more