Issue:
When using the ›World-Ready Composer‹, the character ›Nonbreaking Space‹ (^S) behaves exactly like the character ›Nonbreaking Space (Fixed Width)‹ (^s); i.e.: in justified paragraphs, its width does not adjust (like regular spaces do), but it is fixed and unchanging.
This only occurs with the ›Adobe World-Ready Composer‹ (both ›Paragraph‹ and ›Single-line‹) and not with the regular ›Adobe Composer‹ (neither ›Paragraph‹ nor ›Single-line‹).
It is not related to the font used, it has been tested with many different fonts.

1. Versions with this bug, tested and confirmed by myself or colleagues:
   InDesign (Standard Version) CS6, CC2015.0
   InDesign (Middle Eastern Version) CC2020 (15.1.2), CC2021 (16.0)
   I suppose it occurs in all versions since CS6 (when the ›World-Ready Composer‹ was first introduced, afaik)!




2. Steps to reproduce this issue
   Enter a few lines of text and insert the character ›Nonbreaking Space‹ somewhere. Choose any of the ›Justify‹ paragraph styles and select the ›World-Ready Composer‹. Switch to the regular ›Adobe Composer‹ with the same setup and compare the result.




3. Expected Result:
   The ›Nonbreaking Space‹ should adjust its width just like any other of the regular spaces.




4. Actual Result:
   The ›Nonbreaking Space‹ does not adjust its width.




5. Example as Screenshot attached.
   (Menu is in German: ›Globaler Adobe-Absatzsetzer‹ = ›Adobe World-Ready Composer‹; ›Adobe-Absatzsetzer‹ = ›Adobe Composer‹)

As far as I know, this issue has been reported only once before (https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/39403822-non-breaking-space-is-smaller-than-regular-space-w). But in this report, it is stated incorrectly that the Nonbreaking Space would be smaller than a regular space. It can, in fact, be larger as well (e.g. in a tight line with regular spaces smaller than their 100% optimum). The real nature of the issue is that it does not vary its size.

PLEASE FIX ASAP!
Thanks

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.

Hi, InDesign team.

I've run into a serious bug with GREP styles. Any GREP expression containing an ampersand character that is entered as a GREP style in a paragraph style will suddenly acquire additional ampersands whenever I scroll through the list of GREP styles.

STEPS TO REPRODUCE:

Create a simple GREP style as part of a paragraph style.
The entire GREP expression should consist of the single character &. (Though this also happens when the & is part of longer expressions.)
Make enough other GREP styles that you need to scroll in the window to see them all.
Close the paragraph style window and reopen it.
Scroll through the list of GREP styles.
When you scroll, you will see that "&" has become "&&."

HERE ARE OTHER DESCRIPTIONS OF THIS ISSUE:

https://community.adobe.com/t5/indesign/ampersand-gets-doubled-in-grep-style/td-p/10329693?page=1

https://community.adobe.com/t5/indesign/self-propagating-ampersands-in-grep-in-a-paragragh-style/td-p/5881764?page=1

https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/36196819-paragraph-style-grep-functions-are-unreliable

I believe I have gotten around the bug by using the Unicode value for an ampersand, but this is not ideal. I need to be able to trust that the GREP style implementation is solid.

Thank you.

After choosing »Delete all comments« from the fly-out menu of the PDF comments panel at every position, where a comment was before the removal, a <FEFF> char is left behind, which shows up as a zero-width colon (:), when special characters are turned on.

Since this is a useless char after deleting the comments, the <FEFF> should also be removed, when selecting the removal in the fly-out.

<FEFF> shows up with XML tags, notes and index markers, so we can’t simply do a TEXT search for <FEFF> to remove it.
BTW:
\x{feff} doesn’t work in GREP search, which is kind of strange ...

Hi Adobe, we are still having major issues with a lot of spinning wheels in InDesign version 15.1.1. because of the AdobeFnt22.lst files that are created with every document. Basically when we open a document it resyncs/updates the AdobeFnt22.lst file of every document that was previously worked from that Mac. This is causing a lot of network traffic and spinning wheels in InDesign. The problem is fixed if we restart the Mac or rename the "Document fonts" folder so that InDesign no longer uses the fonts so does not create an "AdobeFnt.lst" file. Can you please sort this out, it is killing our production, some of our designers are reverting back to using QuarkXpress

InDesign version: 15.1.1
Additional versions tried: 15.0.3, 15.0, 14.0.3
MacOS Mojave (10.14.6) on two different computers

To reproduce:
1. Create a new empty document.
2. Add a second page to the document.
3. Place Image, onto the page you're viewing (I did a PNG)
4. Save and close the document.
5. Open the document.
6. Wait 2-20 seconds, doing nothing to change the document.

Expected result: document opens to page with placed image, nothing else happens / changes.

Actual result: document opens to page with placed image, and after a delay the document is marked as changed (asterisk appears in tab before the filename, InDesign prompts to save document when you close it)

Additional detail: It seems to key off of viewing the page with the linked image, not just opening the file. If you save the document while viewing the page without the image, then when you re-open it (and see the imageless page) the file is not marked be as dirty even if you wait. However, if you then go to the page with the linked image (by clicking, scrolling, or command-J), shortly after you get there the file will be marked as dirty. (If you scroll, the key event seems to be hitting the boundary to the new page; the linked image does not need to actually be displayed.)

Attempted fixes which did not resolve the problem:
• Deleting my InDesign preferences (by holding down CTL-CMD-OPT-SHIFT during program startup)
• Deleting my Cache

Hi,
Last week i noticed that InDesign crashes when I fit the textframe to its contents, when that textframe is anchored as "text" inside another textframe (anchor-option: incline or above line) when it is not separated by paragraph breaks or whitespaces.

I have a file that has one textframe for the main column. In it I placed several smaller textframes with more than one column as textelements.
I didn't separate them by a space or linebreak. When fitting one of the smaller frames to its content by double clicking the lower reference point in the middle to get rid of whitespace inbetween the smaller frames, indesign crashes immediatly.

When adding linebreaks inbetween the anchored textframes inside the main one, the "fitting frame to content"-action works fine.

Attached is a video of the problem.
If you have any questions feel free to ask.

Please fix the problem.
My company is using this textframe-in-textframe solution as templates to automatically populate the frames with text using a script. When executing that script Indesign crashed and we had to go look for the issue. Fixed the templates by adding linebreaks.

I added my bugreport on another Bug that seemed similar but after reviewing it it seems like it's a separate bug: https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/39398323-anchored-textframe-with-auto-sizing-auto-adjusting
Maybe it's still helpful...

We are a group of 16 graphic designers working on Macs. Our OS are varied between Sierra, High Sierra and Mojave. We work in InDesign 14.03 and 15.02 (with linked InCopy assets), Bridge 9.1 and 10.03, Photoshop 20.0.8 and 21.1, and Illustrator 23.1.1 and 24.1. We work on Box Drive and store our layout files and absolute-linked image assets there. It is critical that we are able to work on each others’ files in a high-volume, high-production environment. We don’t believe this is an issue related to our connection speeds.

Looking for a resolution to these issues:

InDesign: Not all image and InCopy files are automatically updating / relinking to original assets on Box. This occurs when both original and different users open the InDesign file to edit it.

Box Drive: Writers cannot always see ICML and Assignments files on Box Drive (in the Finder) after an Art Director has exported them for the writer to work on. This typically occurs shortly after exporting the assets.

Bridge: time to load image previews can take up to 15 minutes for some designers.

Version of Adobe InDesign, InCopy or InDesign Server

Adobe InDesign 15.0.1

macOS High Sierra 10.13.6

iMac 27 Zoll End 2012

Steps to reproduce the issues

See also attached video

Open Document "02VKLeerzeilenTEMPEnde.indd"
Open Data-Merge Panel
Generate a merged document with click on the button
Uncheck "Remove Blank Lines for Empty Fields" in Content Placement Options
Press [OK]
Repeat Step 3 this time Check "Remove Blank Lines for Empty Fields" in Content Placement Options
Press [OK]
Put the documents side by side
Activate "Show Style override" in the paragraph panel
Jump to page 2
On the left side (Merged Document, Blank line intact) you can see the 2 markers followed by a paragraph symbol
On the right side (Merged Document, Blank line removed) you can see that the 2 markers with paragraph symbol moved 1 line up behind the 7 and the other paragraph symbol is deleted
Everything is o.k. because the paragraph style (07padresse) of the line "Mobile" and the deleted "Blank line" are the same
Jump to page 3
On the left side you can see the 2 markers followed by a paragraph symbol
On the right side (Merged Document, Blank line removed) you can see that the 2 markers with paragraph symbol moved 1 line up and the other paragraph symbol (blue highlighted on the left side) is deleted BUT this time the paragraph style of these 2 paragraph are NOT the same! The result is a bigger gap between the two sentence "Frau Marie…" and Tel: 012…" on the right then it should be as you can see on the left

Expected result
The Blank line (2 markers and paragraph symbol) should be deleted/removed

Actual result
Instead of the Blank line (2 markers and paragraph symbol) the paragraph symbol before that (blue highlighted on the left side) is removed AND the remaining paragraph also picks up the paragraph style from the "Blank line" (if there were text in my example you could see that as well)

Workaround
You can generate a merged document with Blank lines and delete/remove them with Find/Change
Find > (markers) + paragraph symbol = <FEFF><FEFF>^p
Change > to nothing
This way everything stays intact!

Test file, screenshot, video or GIF capturing the issue (optional)
Video and sample files attached

I am trying to update a library item. It's a previously created library item that I've made changes to. There used to be a contextual menu item called "Update Library Item" but it's gone.

When resetting the prefences with Shift+Option+Command+Control at the start of InDesign or (for me) uninstalling and reinstalling a certain plugin, that menu item appears again.
One user found out this:
Renamed Adobe Indesign folder in ~/Library/Caches. That did the trick for me !!
For the ultimate test, I put back the "old" Adobe Indesign folder and the issue was back again.

Link to the old forum thread: https://community.adobe.com/t5/indesign/update-library-item-missing/td-p/10193293?page=1

To me this is not an issue that should be fixed by the user in such a way.
That menu item shouldn't disappear in the first place. That's why I'm opening a bugreport.

Attached are Screenshots of the issue.