Enter only "^" in the GREP search string field and click the search button to select the insertion point at the beginning of the paragraph. But this cannot be used for replacement. The replacement result is 0.
I gave up that it was only useful for simple pointing tricks, but when I run it from a script the application hangs.

It is like this. (When executed, the rainbow cursor will rotate forever.
Please be careful. )

app.findGrepPreferences.findWhat = "^";
var res = app.activeDocument.findGrep ();

If the replacement string field is "~ c" (the contents of the clipboard), the first character is lost from the original text instead of entering it.
This is also a very dangerous behavior.

Requests for improvement include:
Improved to prevent hang when executing the above script,
If possible, replace text (add a character string to the beginning of a paragraph).

GREP検索文字列の欄に"^"だけを入力、検索ボタンをクリックすると、段落の先頭の挿入点が選択されます。しかしこれを置換には利用できません。置換結果は0個となります。
単なるポインティングの小技にしか役に立たないと諦めていましたが、これをスクリプトから実行するとアプリケーションがハングアップします。

こんな具合です。（実行するとレインボーカーソルが永遠に回転します。
ご注意ください。）

app.findGrepPreferences.findWhat = "^";
var res = app.activeDocument.findGrep();

また、置換文字列の欄が"~c"（クリップボードの内容）などの場合、それが入る代わりに元のテキストから先頭の1文字が失われます。
これも非常に危険な挙動であると言えます。

改善の要望としては、
上記のようなスクリプトを実行した際にハングアップしないよう改善、
そして可能であればテキストを置換（段落の先頭に文字列を追加）できるよう改善。

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.

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

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

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.

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.

After updated to 2020 version that added support to Asian languages (include Thai), it look like Indesign force user (in my case Thai) to set language in Advanced Character Formats to Thai. After set the language Indesign also require me to use World-Ready Composer to set all tone marks in place.
.
Before the latest version, I always avoid to use World-Ready Composer because it combines a word to single object, not just locks tone mark and float vowel to character in the right position. By which it impossible to navigate with text tool to the position of text that I want to revise, even if I use right/left key to navigate. It mostly skips word by word, not only character by character. And when I delete a word or a character, some time it not only deletes backward but forward too. (I think because of when I delete character form a word Indesign instantly recognises new word and forces to delete that new word.) But After updated to 2020, I think, I anymore cannot avoid World-Ready Composer.
.
After I designed to use World-Ready Composer, I found one more bug. Because in many situations when I craft the spacing in layout (especially in Thai), I always use thin-space to separate character like “ๆ” form word before and after to make the space between them look good. But After I set to World-Ready I found that when thin-space (include other spacial white space like en or em) is in the back of the line the spaces in question act like normal character, so the last character of the line when use left justify do not snap to right frame border. The space still there like It becames one of character. So you can see the gap between the last character and the right frame border. (you can find this instance in attachment in file “space issue.”)
.
But the serious issue still there after the update. I, and all of my co-workers, found that everything about word wrapping in Thai language goes wrong after updated to 2020 version. This never happen in the former versions. I don't understand why this issue is happen. Even if I use Discretionary Line Break to help Indesign to wrap text properly. But It is not productive at all, because I had been forced to read text all over again and to insert Discretionary Line Break to every lines. (you can find this instance in attachment in file “wrap gone wrong.” In the high-light is the words that should be stick together.)
.
PS. while I wrote this issue report, my co-worker tried to migrate back form 2020 to 2019 and she found that when copy revised text back to 2019 it not the same character encoding. I advised her to try to place that text to TextEdit. It appears that some character is changed to something that is not unicode at all. That never happen in previous versions too. ((you can find this instance in attachment in file “text form 2020” and “text form 2020.” the text form 2020 at frist did in 2019 before migrate to 2020.)

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