InDesign Version: All

Background:
An accessible PDF needs for all graphics and pictures a bounding box.
This is used by AT e.g. to set a focus to a visual impaired user.
Using the PDF export a bounding box is defined for all linked images.

Problem:
Often the bounding box does not fit to the visible area.
AT user get wrong information, in fact the file is not accessible.

Steps to reproduce the issues:
Place an asset, where only a part of the linked asset is visibily placed in InDesign, the rest is cropped.

Expected result:
Bounding box fits to visible area

Actual result:
The bounding box is bigger than the visible area, if the assets content is bigger than the area show.

Workaround:
You can fix this in Acrobat theoretically, but this is nor real workaround as you only edit values and dont have visual feedback.

Attachement:
InDesign sample files and accessible PDF with bounding box example + visible error.

I am using InDesign CC 2019 14.01 x64.

Once a stroke weight has been added, if you then change the stroke weight back to zero, then when you export to pdf the pdf will have a stroke weight added to the text, even though the indesign document looks correct. It may not have the original amount of weight that was added, but it will definitely have what looks to be around a .2 weight added.

However, if you were to start a new document, then add stroke weight, then click edit - undo stroke weight, then it would export to pdf just fine. However if you saved the document with the stroke weight added, and then re-opened and changed the weight to zero, then when you export to pdf it will have a stroke weight still added (around .2, same as above).

So once you have saved a document with the stroke weight added, then no matter what you do the document will not print without the added weight.

If ANYBODY has any idea how to fix this then PLEASE let me know :) I was on chat for 4 hours but no luck. I'm really not trying to redo this 600 page book.

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

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.

My InDesign opens the destination folder when exporting PDF-files. In my work I export files daily and I have to export them separately. So when I do this, after the export has completed successfully, the destination folder opens up automatically, which is very annoying. I can't seem to find any place, where I can turn this off. I can only turn it ON, if I don't export separately.

1. brand new update CC 2019


2. Create a document with more than 2 pages. Export all the pages separately.


3. That it exports the pages separately into the destination folder without having the need to watch them in that folder (I use Bridge).


4. It opens the destination folder in a new folder window.

I'm reporting this bug on behalf of the type design studio Dalton Maag. To reproduce: use the provided test font, write the lowercase letter "p" in Indesign, and choose the "Hair Italic" instance, or equivalently, set:
- the font's weight axis to the minimum,
- the width to its default value
- the italic axis to its maximum.

Glyphs are shown without fault within InDesign itself. However, when exported to PDF format and opened on Acrobat Reader, there is an issue with how the letter “p” is displayed (see aktiv_vf_p_bug.png).

We are suspecting the issue is caused by a point on the glyph with coordinate x=0. For our purpose of releasing a working version of the font, we were able to circumvent this problem by moving the offending point by one pixel to the right in the Hair Italic master. However, this is not an acceptable longterm solution from a design standpoint.

We also suspect that the problem happens during the conversion from variable font to a static font for inclusion in the PDF, because we extracted from the PDF the static Hair Italic font that gets embedded, and saw that the bottom right point is misplaced in that font.

I can't attach the pdf but I can send it to you for reproducibility.

When placing an Arabic weight statement (e.g. "13g") followed by a tab and a percentage (e.g. "19%"), the weight declaration ("g" or "mg") moves to the percentage when exporting to pdf. Only when setting PDFX/1a:2001 is selected the output is correct. But this setting removes all layers and flattens transparencies so it's not very useful.
A workaround is to place a space after the tab (so on the left side since this is a right to left language).
See screen shot in attachment. On top = InDesign file, bottom = pdf created from this file using PDFX/4. The top line in the Indesign file has no space after the tab, resulting in a wrong placement of the "غ" (= Arabic "g") as marked red in the screen shot.
Sample file : https://www.dropbox.com/s/15db51rlwen8ehg/SFDA-test.indd?dl=0