There are multiple listings of the same font in the Find Font menu in CC2019. All information is the same, all applied characters are the same, but there is odd behavior.

--FileACC2019WithDocumentsfontsfolder.png shows double listing of Trade Gothic LT Pro Roman.

--FileACC2019WithoutDocumentfontsfolder.png (when I take away access to Document fonts folder, no other changes), one instance switches to "Regular" instead of "Roman"

--FileACC2017WithDocumentfontsfolder.png shows what happens with I open this file in CC2017 (no double listing)

--FileACC2017WithoutDocumentfontsfolder.png (Document fonts folder hidden) shows what happens with I open this file in CC2017 (no double listing)

I process large volumes of files; this is not an isolated incident nor a corrupted file. Packaging results in InDesign only grabbing the single correct font file, so that isn't broken. This behavior with Find Font is seemingly new to CC2019 (I'm working on 14.0.2). The multiple listing of same font, variation of font name when fonts enabled/disabled, and Find Font showing fonts missing that aren't because of what seems to be a name issue in Find Font. Has something changed in the way that InDesign reads fonts/accesses Document fonts folders?

The inclusion of ~F in a character class invalidates grep expressions in endnotes.

InDesign version: 14.0.2.324 (with the GREP fix installed)

Steps to reproduce:

1. Open the attached document. It contains a single page with text and an endnote.


2. In the GREP tab of the Find/What window, enter the following GREP expression:

\d[^.,;~F]+

And target the document. The expression matches from a digit up to the next period, comma, semicolon, or footnote marker.

Expected result: The expression should match some text in the main text and in the endnote.
Actual Result: The expression does not match anything in the endnote.

To show that it's ~F that's the problem, use this expression:

\d[^.,;]+

It matches in the main text and in the footnote, as expected.

InDesign 14.0.2 and Acrobat Continuous 2019.10.20099

This issue is about the behavior and appearance of interactive check boxes in documents that have been exported to Interactive PDFs.

There is a difference in the way that check boxes created in InDesign behave and appear versus those created in Acrobat Pro. The Acrobat Pro Forms preferences are involved in this difference.

When, in Acrobat Pro Forms Preferences, under Highlight Color, the “Show border hover color for fields” option is selected, check boxes created in InDesign behave and appear in the following manner.

When a check box is made active, it first appears the same as the check box that was created in InDesign. When you tab to or select another check box, or when you save the selection in the PDF, the appearance of the check box reverts to a default generic check mark.

When, in Acrobat Pro Forms Preferences, under Highlight Color, the “Show border hover color for fields” option is not selected, check boxes created in InDesign behave and appear in the following manner.

When a check box is made active, it first appears the same as the check box that was created in InDesign and remains as such.

This degrades the purpose of using the highlighted fields, which is to call attention to fields that need to be filled.

When the check boxes are created in Acrobat, it makes no difference in appearance or behavior if the “Show border hover color for fields” is selected or not. They always appear as the checkbox style you have chosen to use. They do not revert to a generic check mark.

This is the way that custom check boxes created in InDesign should behave. Thus, they would allow the use of a highlighted field without the appearance of the “selected” custom graphic changing to an unwanted generic graphic.

Please refer to the InDesign Forums message at this link for examples:

https://forums.adobe.com/message/11063952#11063952

Code below works fine on Windows and CC 2018 on Mac. But CC 2019 Mac it hangs the app once clicking the OK button in window 2. I've tried three different Macs including Mojave and High Sierra. All the same result. Pretty sure it's not just me. This bug has broken a number of my scripts that present a secondary window for saving settings.

var w1 = new Window("dialog", "Window 1");

var btnOpenWindow2 = w1.add("button", undefined, "Open Window 2");

var btnOk1 = w1.add("button", undefined, "OK");

btnOpenWindow2.onClick = function () {

openWindow2();  

};

btnOk1 = function () {

w1.close();  

};

w1.show();

function openWindow2 () {

var w2 = new Window("dialog", "Window 2");  

var btnOk2 = w2.add("button", undefined, "OK");  

btnOk2.onClick = function () {  

    w2.close();  

};  

w2.show();  

}

We are developping a plugin for inDesign and while testing a new feature on a Mac we noticed that sometimes InDesign was crashing. We managed to reproduce this bug in a very simple indesign script that make inDesign crash 100% of the time and I'm looking for a way to get around this inDesign bug.

The crash occurs when we programatically add an htmlItem to a pageItem then close the document too quicky, It's only on Mac, doing that on windows works perfectly. The crash error seems to be a memory usage problem on inDesign's side.

Here is the script code :

var document = app.activeDocument;

var sourcePageItem = document.allPageItems[0];

sourcePageItem.htmlItems.add(

document.activeLayer,

LocationOptions.AT_END,

sourcePageItem,

{

  geometricBounds: sourcePageItem.geometricBounds,  

  htmlContent: '<b>Hello</b>',  

}

);

document.close(SaveOptions.NO);

other observations :

-Doing a sourcePageItem.htmlItems[0].remove(); to remove the htmlItem after adding it doesn't change anything, so the problem comes from using the function htmlItems.add() and not having an htmlItem in the document.
-Delaying the close by using $.sleep(5000) before fix the crash, but we can't rely on it as the delay needed increase with the number of htmlItems added and it might be different from a computer to another due to performances.
-Saving the document or not doesn't change anything

I've added my clean document with just a rectangle frame, the script and the crash report on this url : https://we.tl/t-uFpX658s0o since we can't add an indeed file to the post

If there is no way to fix it, do you have an idea to get around this inDesign bug ?

How to repeat the issue:

1. Activate Clipboard history in windows settings (win 10)


2. Copy a random number to your clipboard (my testnumber "-2,375")


3. Create a new document and place a rectangle (or random object) on your page


4. Select the object and click (focus) in the field for the y-coordinates


5. hit "windows+V" to open your clipboard history (must be activated in the settings)


6. Click on your previous copied number.

6-Bug. The number has been pasted two times in the y-coordinates field.

Test system:
- Win 10 pro (1809)
- current Indesign CC version (how to check the actual version?)

By the way, if you try the clipboard history in a text field in inDesign, it works totally fine.

Thanks for your help.

Using CC2019 on a Mac running High Sierra

Steps to reproduce:
1) Create a document with a few hyperlinks in it.
2) Whilst this document is open, open a 2nd document, and copy/paste the links from one document to the other.
3) Save both and close.
4) Trash source document

Expected result: hyper links should work in Target document as expected.

Actual result: hyperlinks all appear broken in document. Whilst an exported PDF appears to still work, ID reports all those links as broken.

Other details:
If you retrieve the source document from the trash, it the links in the target document suddenly start working again, meaning your not actually pasting the hyperlink, but theres some sort of link that exists between the source and target document.

Saving target file as a new file, saving as idml, has no effect – those links are still tied to the source document.

This in an absolute tragedy if you are working on large documents with lots of links, and needs fixing ASAP