To place a graphicItem with text wrap, it is not an object-based indent like 2020, but a text frame-based indent before 2019.

1 Version
16.0.1(macOS10.14/10.15.6)

2 Steps to reproduce the issues
1. Make TextFrame. To places graphicItem above the textFrame and set text wrap.
2. The indent set in the textFrame does not take effect for the object for which wrap text is set like before 2019.

3 Expected result
Indent set in the textFrame does take effect for the object for which wrap text is set like 2020.
Please refer below Community article.
https://community.adobe.com/t5/indesignフォーラム/indesign2020ではできていた回り込み時のインデント設定の維持が2021ではなくなっている/m-p/11677071

4 Actual result
The indent set in the textFrame does not take effect for the object for which text wrap is set like before 2019.

I'd like to report a bug. Please follow the scenario below:

1. In a single column with lots of text in it, make two columns for a fragment of text

2. In text within the two-column setup, make a footnote. Add several lines of text to the footnote

3. Turn on the "Span Footnotes Across Columns" feature so that footnote ends up in the same group with the footnotes at the bottom of the page rather than below the two-column fragment

4. Expected behaviour: normal editing can be performed after these manipulations

5. Observed behaviour: any text editing after turning on the "Span Footnotes Across Columns" feature becomes lethargic and near impossible. Turning this option off immediately solves the speed issues.

Please log a bug to fix this behaviour.

Dear Support,

with the GREP position marker "^" for "Beginning of Paragraph", the GREP-search should consider the position of the beginning of a paragraph.
But this marker does not only recognize the beginning of a paragraph, but also the beginning of a new line after a forced line break (SHIFT-RETURN).

This is not correct: A forced new line is not the beginning of a paragraph.
The only correct way would be to consider the beginning of a paragraph (RETURN).

Sometimes you can use "(?=\r)\w+" to look for a word behind a Return instead of "^\w+" to find only the hits at the beginning of a paragraph. However, a combination with the search for a paragraph format can be disturbing here: with the lookbehind combined with a paragraph style only those places are found, where two consecutive paragraphs have the same paragraph style.

Please correct the effect of ^ to only beginning of paragraph (and not forced line break).

Adobe InDesign (ME) 2021, 2020, CC 2019, ..., CS6
macOS and Windows

InDesign's WorldReady settings (Paragraph Direction, Kashidas, etc.) are being stripped from a document's [No Paragraph Style] style when opened on a machine with a missing 3rd-party plug-in (like Em Software's InCatalog). This appears to happen with any 3rd-party plug-in that adds a text attribute with a prefix that's lower than the WorldReady plug-in's prefix. While the following steps use the Middle Eastern app (English Arabic), where there's a UI to see the style's empty/blank WorldReady entries, we've confirmed that this problem affects all app variants (including English (Roman)).

To reproduce:
1. Install ME version of InDesign 2021 (English Arabic).
2. Install Em Software's InCatalog plug-in (http://emsoftware.com/products/emcatalog/ ) or any plug-in that adds a text attribute with a prefix ID below that of WorldReady's 0x50f00. (The SDK's BasicTextAdornment sample will work if its kBscTAPrefixNumber is changed to something like 0x43a00.)
3. Restart InDesign while holding down Shift-Control-Option/Alt (to ensure the session workspace's [Basic Paragraph] style is rebuilt to include the new plug-in's text attribute).
4. Create a new document and add a text frame containing a few paragraphs using the [Basic Paragraph] style. This text should compose as right-to-left (the ME version's default direction, as specified by WorldReady's kParagraphDirAttrBoss). Create a numbered list, since that's a great way to see the problem.
5. Save the document.
6. Quit InDesign.
7. Remove InCatalog (or whatever plug-in was installed in step 2).
8. Restart InDesign.
9. Open the document that was saved in step 5.

Alternatively:
1. Install ME version of InDesign 2021 (English Arabic).
2. Restart InDesign while holding down Shift-Control-Option/Alt (to ensure a clean session workspace)
3. Open the attached SavedWithInCat(2021ME).indd file. (Well, UserVoice won't let me upload it. Ask & I can send directly.)

Notice that the text frame in the opened document incorrectly flows left-to-right and the numbered list's numbers wrongly show on the left rather than the right. Edit the [Basic Paragraph] style and note that the WorldReady settings in the Middle East Character Formats and Indents and Spacing panels are blank/empty. (See attached before-after screenshots.) One would expect a style to survive intact even when opened on a machine with a missing 3rd-party plug-in, but instead some of its settings may be at risk of being lost.

We've used WorldReady as the victim here, but this problem affects any plug-in, Adobe or 3rd party, that adds a text attribute with a prefix that's higher than the missing plug-in's prefix (such as Em Software's InData).

Details: We've isolated what looks like a long-standing problem (bug?) with the SDK's AttributeBossList::CopyInto(), where it stops the copy when it encounters an attribute whose plug-in is missing. Instead, the copy should continue after the missing plug-in's entry order to produce a complete list of non-missing attributes. Copies produced by AttributeBossList's Duplicate(), ApplyAttributes(), and its copy-constructor are all affected.

1. Version of Adobe InDesign
   This issue appears in every InDesign versions since footnotes are supported.
   Bug reports / feature requests (from CS3 up to CS6) have been ignored in the past.

2. Steps to reproduce the issues
   given:
   a) a footnote with three text lines
   b) splitting footnotes allowed in the footnote options
   c) keep options: at start/end of Paragraph 2/2 (2 lines at start, 2 lines at end)

Play with the textframes hight so that the footnote is forced to be splitted. It will only split 2/1, not 1/2.

1. Actual result
   The footnots splits with 2 lines in the textframe within the footnote starts and ends with one single line (widow) in the next textframe.

2. Expected result
   a) best choice: hold the keep options!
   (e.g. 2 at start / 2 at end; so don't split a footnote with 3 and less lines).
   b) alternative: make an orphan (full line at the start of a footnote paragraph) instead of a widow; widows are absolutely not allowed (because they ony fill a part of a line, maybe only one word)

3. Test file, screenshot, video or GIF capturing the issue (optional)
   Screenshots appended

1. InDesign CS4 - CC2017

2. Generate an Excel spreadsheet that contains at least one cell with the value "-1". Save as XLSX. Import/place (cmd-d) this file as "unformatted table".

3. the cells with the value "-1" should still have this value.

4. the cells are empty. All other values seem to show up correctly.

Additional information: Working regularly on Annual Reports with 100+ tables, our choice is to import as „unformatted table“ and to do all formatting in InDesign. After changes in Excel, all we have to do is updating the linked tables via the link panel. Table contents change, formatting stays. Perfect. But we are dependent on our clients still willing to use the outdated XLS format.

Please have a look at this problem! Thank you in advance.

Best regards

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.

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

We use to be able to search all text in a story by using this (?s).+ code. It’s working fine in CS6. But in CC2019, 2020, and 2021 on both Mac and Windows it will fail to select all text in the story if there is more than ~ 50000 character. Only the first ~ 50000 will be selected.

This might be related to an old bug that was introduced in 14.0.2 that was fixed in 14.0.3.

Steps to Reproduce:
1. Create a document with one story containing more than 50000 characters
2. Do a GREP Find using (?s).+

A similar issues when trying to use \X+ to select all text in a story. Only some portions of the text over multiple of ~ 50000 text will be selected.

Cursor Direction when typing Arabic or other RTL languages. in Middle Eastern version ONLY.

1. All Middle Eastern versions (English يدعم العربية)

2. Type Arabic text. Place the cursor within text. Hold "Shift" key and click on right arrow key on the keyboard to select/highlight text. Cursor moves left and select next character on the left while clicking on right arrow.

3. To select a character to the left of the cursor, we should hold (Shift+left arrow) To select a character to the right of the cursor, we should hold (Shift+right arrow)

4. What actually is happening now and for over 20 years when we had Adobe PageMaker ME and Adobe Illustrator ME is the opposite cursor behavior to the what we're trying to select. We hold (Shift+right arrow) cursor will move and select text to the left, we hold (Shift+left arrow) cursor will move and select text to the right.

5. see animated GIF on InDesign forums here… https://forums.adobe.com/message/10174226#10174226

Excel filter rejects custom Cell Range for 26-column sheets (.xlsx-only)

Steps to reproduce the issues:
1. Create a new document.
2. Select File > Place, check Show Import Options, select attached Columns_26.xlsx file.
3. Note nonstandard default Cell Range: A1:A@10 (should be A1:Z10).
4. Enter custom (valid) Cell Range "A1:E5"

Expected result:
No error and a table containing cells A1 through E5.

Actual result:
Error message, "You have not entered a valid 'Cell Range'. (See attached screenshot.)

This error is given for any sheet whose right-most column is a multiple of 26 (so Z, AZ, BZ, etc.). Place the attached Columns_52.xlsx with range "A1:E5", for example.

Adding/removing a column (attached Columns_27.xlsx file) avoids the error.

Versions of Adobe InDesign:
CS6 through CC 2018.0, Windows and macOS

Test files and screenshot of error attached.