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.

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.

Version : Adobe InDesign 2021(ver.16.0.1 ja_JP)
OS : macOS10.15.6

1.Steps to reproduce the issues

1. Open Find/Change Window.

2. Select "文字種変換" and click "Specify attributes to Find" and Select Style button.

3. The selected Style does not shown in "Find Format" area and we can't apply it. However, click the button, we can see selected Style we selected previouse step.

4. The Change Format in "文字種変換" also unavailable.

2.Expected result
The selected style is displayed correctly in Find Style area and is correctly apply.
Also, the replacement style is set correctly in Change Style and replaced as well like InDesign 2021.

1. Actual result
   We can't set Find Format and Change Format options in "文字種変換" in Find/Change window.
   Test file, screenshot, video or GIF capturing the issue (optional)

Japanese.
1.問題を再現する手順

 1.検索と置換ウィンドウを開きます。

 2.「文字種変換」を選択し、「検索形式」をクリックして、「検索する属性を指定」ボタンをクリックします。

 3.選択したスタイルが検索形式のエリアに表示されず、適用できません。ただし、再度「検索する属性を指定」ボタンをクリックすると、前の手順で選択したスタイルが表示されます。

 4.「置換形式」のスタイルも利用できません。

2.期待される結果
InDesign2021と同様に、選択したスタイルが「検索形式」エリアに正しく表示され、検索対象として正しく機能する。また、「置換形式」も同様に設定できて正しく置換が行える。

3.実際の結果
「検索と置換」ウィンドウの「文字種変換」で「フォーマットの検索」および「フォーマットの変更」オプションを設定することはできません。

Please refer below,
https://community.adobe.com/t5/indesignフォーラム/文字種変換で検索形式の指定ができません/m-p/11695809

Since a few weeks (we think since the InDesign 16.1 x64 update), we see a major problem in a lot of our books:
Words that already contain a hyphen (minus sign: -), and that are hyphenated automatically by InDesign, get a double hyphen!
Normally, when hyphenated words are at the end of the line, the 'hard typed' hyphen gets replaced by the automatic hyphen (with the blue ~ added above it), but now the automated hyphen is added, so we get two consecutive hyphens (--). Sometimes on the same line, sometimes one on the next (see example screenshot).

This is a serious and big problem, experienced by everyone in our team (10 people), on multiple different projects (using templates we use for years already).

It causes a major liability issue towards our customers, when the books are printed this way! Please fix this.

We are all on Windows 10 Pro and have the latest version installed (InDesign 16.1 x64)

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).

Anchored textframe with auto-sizing/auto-adjusting "height", text aligned to baseline and anchored object settings "anchored position: custom", "anchorPoint: bottom left/center/right" causes InDesign 2020 (15.0.1) to freeze (on Mac and PC).

1. create an new document (size doesn't matter)


2. create an new textframe (dimensions doesn't matter)


3. create a second textframe (dimensions doesn't matter)


4. insert some text in second generated textframe


5. select the text and apply the option "align to baseline".


6. anchor second textframe into the first created textframe


7. set anchored object settings of the anchored textframe to: "anchored position: custom" and "anchorPoint: bottom left or bottom center or bottom right"



8. select the anchored textframe




9. choose the textframe fit option "frame to content" or use the shortcut "strg + alt + c" on PC

InDesign 2020 freezes.

or repeat steps 1. to 8. and choose auto-sizing type "height" or "height and width" or "height and width proportionally" for the anchored textframe

InDesign 2020 freezes.

see attached screenshot. I can't attach a .indd or .idml file cause this is not allowed (error: invalid file type)

In previous versions (CC 2018, CC 2019) auto-adjusting "height" works as expected

In InDesign 2021 (the latest version both on Mac and Windows), I add a text frame and fill it with placeholder text which is set, by default, to Minion Pro - Regular.
Then I go to the find-change dialog box and set 'find format > basic character format > font style' to Book.
And guess what happens when I hit the ‘find next’ button? It selects all the ‘regular text. (The document has no text with the 'book' font style applied!)
Selecting another style — e.g. Bold, Italic, etc. — results, as expected, in the 'cannot find match' alert.
Looks like a bug to me!
The same problem occurs with GREP search as well.
Also, other users reported me that it happens in CS6, CC 2017, 2019 and 2020.

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.

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

ID CC 2017-2021; Hebrew (Middle East English)
Mac 10.14.6

Description:
On mac, some letters with diacritics has lost their ability to produce diactritics and no longer work.

The letters and how to type them with Hebrew script installed on system:
1. Vav Holam
2. Vav Shuruk
3. Shin
4. Sin
5. Lamed holam

An InDesign document is attached with samples and explanations.

Steps to Reproduce:
1. On a mac, add Hebrew Script to you system language.
2. Open InDesign Middle Eastern Version and create a text box with the a Right to left Text tool.
3. While the system script is set to Hebrew, try to type the following letters with the following shortcuts:
1. Vav Holam - Shift+u
2. Vav Shuruk - Atl+u
3. Shin - Shift+a
4. Sin - Alt+a
5. Lamed Holam - Shit+k

Actual Result:
1. Vav Holam - Shift+u Produce ו
2. Vav Shuruk - Atl+u Produce ו
3. Shin - Shift+u Produce ש
4. Sin - Atl+u Produce ש
5. Lamed Holam - Shit+k Produce ל

Expected Result::
1. Vav Holam - Shift+u Should Produce וֹ
2. Vav Shuruk - Alt+u Should Produce וּ
3. Shin - Shift+a Should Produce שׁ
4. Sin - Alt+a Should Produce שׂ
5. Lamed Holam - Shit+k Should Produce לֹ

This was reported to Adobe Pre-Release on Oct 21, 2018 and nothing was done about it!

This report contains another letter with diacritics (number 5) that can't be typed in InDesign.