Dear Sir or Madame,

since the automatic End-/footnotes have been implemented in indesign we have critical issues working with the program.
We are a publishing company with several designers and do also publications with different languages (CC2014 was the last version, which worked without problems, as there have not yet been automatic footnotes).
If we have a publication/book with two or more languages we work with different layers in indesign – for each language one layer. The problem starts, when we have also footnotes to work with. After finishing the layout in the first language, we have to duplicate the layer in indesign for the second language. In doing so, the footnotes start to become one piece of mess. Wether its that the copied footnotes or endnotes are automatically implemented in an obviously chaotic way (even in layers which have been blocked) or they crash/destroy the whole layout in adding one new page automatically and you can't do a thing about it (in effect, the whole layout is misaligned after this new page has been added).
We would strongly recommend to debug this and/or make it possible to deactivate the automatic foontnotes, so you can do it also manually as before.

Best
Hannes Halder

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?

Adobe InDesign version: 2019 CC

We are currently trying to establish the best workflow in creating fully accessible PDF's for screen readers and I believe we have come across a bug in the communication between InDesign and Acrobat.

Quick summary:

H1 elements on multiple lines read as separate elements unless assigned manually in Acrobat
The Structure and Article order does not transfer to the PDF

To explain the issue clearly I have numbered the images in the process order.

1. Image: 1 InDesign Accessibility setup.png


2. I have setup ‘paragraph styles’ and used the correct ‘Export Tagging’ tags for each style.


3. I have added the content I want to be read in Articles and put them in the correct order


4. I have created tags and assigned all the content correctly


5. I have reordered the ‘Structure’ to be in the reading order too

Please note - the order of the ‘Structure’ and or ‘Articles’ does not transfer to Acrobat (after selecting the correct export settings.

1. Image: 2 Interactive PDF with options selected.png
   This image shows I have selected Interactive PDF and selected:
   ‘Create tagged PDF’
   ‘Use structure for Tab Order’




2. Image: 3 Initial PDF review - incorrect content order.png
   You can see the reading order does not match either the ‘Article’ or ‘Structure’ order from InDesign which I have set up.

You can also see that the elements are ‘Spans’ not H1, H2 and P tags.

1. Image: 4 Initial PDF review - Tag number ordering incorrect.png
   You can see the screen readers reading order by the numbers shown on this image which again does not match the order I set up in InDesign.




2. 5 Initial PDF review - tag h1 splitting.png
   The tag order doesn’t match the structure setup in InDesign
   Also there is another bug when reading H1 tags on multiple lines.

You can see how the H1 tag is broken by 4 lines. This has been tested and you have to swipe 4 times to listen to the full H1 header.

1. 6 Initial PDF review - tag h1 splitting - fix by order assigning.png
   In Acrobat I have then gone into the reading order and manually set the main header to a H1 tag. This then groups the text in the tag order window and fixes the issue of it being multilines.
   You can then also see the tag has changed from Span to H1.

The same thing needs to be done for the other multi layered heading tags.

I hope this is clear enough to understand.

1. Adobe InDesign Middle Eastern Version, 2019-2020

Non Breaking Space is smaller than regular space when text is full justified with Adobe World ready Paragraph Composer

1. Steps to reproduce the issues
   2.1 Create a paragraph with some lines
   2.2. Define it with: Paragraph pannel>Justification>Composer>Adobe World Ready Paragraph Composer
   2.3 Full justify the Paragraph and change one space to non breaking space.




2. Expected result
   Non breaking space should be the same width like all the spaces in the same line.




3. Actual result
   Non Breaking Space is smaller than regular space in the same line




4. Test file, screenshot, video or GIF capturing the issue (optional)

There is no workaround unless the document is not in Hebrew and then you can choose the Adobe paragraph Composer instead of the World ready Paragraph composer.

When working with Arabic and wanting to have Roman Digits, one needs to choose the "Arabic" digits option.
More option that should be set for Arabic are:
Character direction should be set to "default"
Paragraph direction should be set to "Right to Left"
Paragraph composer should be set to "Adobe World-Ready Paragraph Composer"
Language should be set to "Arabic"
Ligatures should be "On"

BUT
If I type a date that suppose to be presented like this:
9/1/2020
as soon as selecting "Arabic" for language the order is reversed to this:
2020/1/9

As digits has a built in Left to Right direction, all neutral characters between the numbers should get the same definition. This is how it worked until the 2020 update.
Now it looks that all the "/" characters where not effected by the numbers direction and remained Right to Left direction.

Mac Pro (Late 2013)
Software OS X 10.14.6 (18G2022)
Processor 3.5 GHz 6-Core Intel Xeon E5
Memory 32 GB 1867 MHz DDR3 ECC
Adobe Software version: 2020