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.

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

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.

Not sure if InDesign or Acrobat issue: Using 13.1. InDesign - Recently noticed that if I have text that flows to 2 lines and that has a hyperlink behind it, in Acrobat, the tags show the link as having two Link-OBJR, but they are the reverse of reading order. So if you tab the page, you go from 2nd line of text to first. So,

'Go to
the store'

tabs as if it is 'the store' 'go to'. The underlying link is fine--no issue there--it's the tab order and tag order (tag order perhaps then impacting screen readers/accessibility???).

This is in a single paragraph block, so not an issue of Article content out of order--the system is doing this. I think this is a recent bug (last 4-6 months?) --but whether in how InDesign feeds this to Acrobat or how Acrobat interprets, I don't know. I can manually fix in Acrobat but re-ordering the Link-OBJR tags, but it makes no sense that I should have to do so. Any idea what is going on?

Hi together,
to explain the issue:

Sometimes backling from endnote text to endnote reference number will not work.

To make it work at all I found the following minimum requirements for PDF export:

PDF Export (Print)

Compatibility: Acrobat 5 (PDF 1.4)

[x] Create Tagged PDF

[x] Hyperlinks enabled

Even with that sometimes only linking from the endnote reference number to the endnote text will work, but not backlinking from the endnote number in the endnote text to the reference in the main text.

What I found:

If you want linking back from the endnote number at the start of the endnote text you have to be careful with formatting of that endnote number which in fact is a special character.

WHAT WORKED:

The endnote is using a paragraph style without any specialities. No overrides, no character styles applied:

RESULT: No issue with linking back and forth between endnote reference number and number in the endnote text.

Now I had the idea to format that special character, the number that starts the endnote text with a character style.

RESULT: Linking from the endnote reference number to the endnote text worked. BACKLINKING DID NOT WORK.

MORE DETAILS IN THIS THREAD:

Endnotes not exporting with links to PDF
Mr_Wonderstuff, Nov 18, 2020

https://community.adobe.com/t5/indesign/endnotes-not-exporting-with-links-to-pdf/m-p/11628582#M40545...

https://community.adobe.com/t5/indesign/endnotes-not-exporting-with-links-to-pdf/m-p/11628643#M40546...

WHAT BROKE THE BACKLINKING:

[1] Character style applied through a GREP Style

[2] Character style applied directly as formatting

[3] Properties directly applied as overrides without a character style

WHAT FINALLY WORKED:

[4] Character style applied as nested style through the applied paragraph style:

Character style to 1 tabulator character

I did not test on to eliminate other factors.

Maybe one of the used properties are the real culprit?

What I defined in that character style and also tried to apply as character override was:

Character width and height: 70%

Baseline Offset: 2 Pt

Fill Color: "C=100 M=0 Y=0 K=0"

Regards,
Uwe Laubender

( ACP )

All InDesign 2021 test documents and the exported PDFs. Also the used joboptions-file can be downloaded from my Dropbox account:
https://www.dropbox.com/s/k2bwr5ljvhde4vx/201127-1-Backlinking-Endnote-Refs-and%20Endnote-Texts.zip?dl=1

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.

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