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

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

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.

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

Adding Hunspell dictionaries breaks code-signing, and results in the whole of InDesign's spelling system being sand-boxed by OSX.

Steps to reproduce:

1. On High Sierra and InDesign CC, add a Hunspell dictionary, as detailed here: https://helpx.adobe.com/indesign/kb/addcsdictionaries.html




2. Spell-check any InDesign document using the new dictionary and spell-checking then becomes unusable, until InDesign is uninstalled then re-installed.

The following types of errors are produced in the console, showing that it's a code-signing issue, caused by dictionaries being installed within the Hunspell plugin bundle.

Can I suggest that there should be another place to install additional languages, outside the InDesign application.

The only way I can work with Latin and Ancient Greek languages currently is to use an El Capitan Mac, which does not have the sandboxing.

AMFI: Check-fix enabled for binary '/Applications/Adobe InDesign CC 2018/Resources/Dictionaries/LILO/Linguistics/Providers/Plugins2/AdobeHunspellPlugin.bundl e/Contents/MacOS/AdobeHunspellPlugin' with TeamID 'JQ525L2MZD', identifier 'com.adobe.adobehunspellplugin2': broken signature treated as unsigned without privileges. This workaround will not work for software built on or after 10.12.