To create a (navigable) Epub TOC you check the 'Make text anchor in source paragraph' checkbox. The links are created correctly when the TOC is created manually, but when the TOC is created by a script, the links are not created.

To confirm, please open the attached document and run this very simple script:

app.documents[0].createTOC (app.documents[0].tocStyles.item('Epub'), true);

The used TOC style ('Epub') has the 'Make text anchor in source paragraph' box checked.

Then export the document to reflowable Epub. In the Export dialog's General tab, select 'Multilevel (TOC Style)' at 'Navigation TOC' and at 'TOC Style, select the Epub style. Click OK.

Expected result: An error-free export and a valid Epub file.

Actual result: An error message saying "Found TOC hyperlinks which lack target text anchor information. Please update TOC with 'Make text anchor in source paragraph' option turned on."

To verify that this is a scripting problem, re-open the document and export it manually. The error does not occur, and the epub has a valid html TOC.

In the Appearance Panel, the (Black) color swatch is not a TRUE BLACK color and when this color swatch is used and a file is exported to PDF, Rich black is not achieved.

The attached document shows a few shapes that are black. The top right is a true black color and the color swatch had to be changed from the standard (BLACK) color swatch in order to be achieved when exporting to a PDF. The left and bottom color swatches have the (Black) color swatch from the appearance panel applied.

Please, Please, Please, make the (Black) color swatch a true rich black color (since users cannot adjust this color).

Since the standard (Black) color swatch isn't true black, it will take me quite a bit of time to apply a new color to all my previously designed files that use your standard (Black) color swatch.

It would be useful to be able to create an Event Listener that would fire when a document failed to open. It would be great if we could cancel the default behavior using the PreventDefault.

My use case is the following. We offer a script that adds a custom menu item to allow users to select, convert, and open files that aren't usually supported by InDesign. We want to be able to offer the same type of functionality if the user attempts to open one of our supported file types through the standard Open Dialog (File->Open).

We would set up an Event Listener for "failedToOpen," which would validate that the file is one we support. If so, we would PreventDefault and prompt the user, asking if they'd like the file converted. If we didn't support the file type, we would allow the default behavior.

Note: my sample code is jsx, but the problem may not be limited to jsx. Change the filetype of my provided files from txt to jsx prior to using!

We have multiple products that sometimes show a problem with document.close() not actually closing the file, leading to incorrect functioning, memory bloat, slowdowns, and we believe some crashes. I provide a test script that takes a currently open document and iteratively copies it, opens the copy, then closes the copy -- after the loop is finished, the copy files are removed.

Important: If run from the ESTK or Scripts Panel, the script works as expected -- no problems. If run from a custom menu (setup script also provided), the problem happens every time.

We believe we've seen this in cases where a custom menu is not the launch mechanism, and may be intermittent in those cases.

We believe we've seen this in InDesign Server as well. My scripts have been tested in CC 2019 and CC 2020 and on both Win and Mac.

In order to run the "Test_menu.jsx" script for using a custom menu, the "Documents left open on close.jsx" script must be in a "TestScripts" folder in your 'home' or 'user' folder (i.e., inside of "~/TestScripts").

This problem is a real headache and is difficult to work around. It affects multiple product areas; we urge prompt attention to this problem.

Thanks.