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.

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.

The last cell in a table is a “dead” cell as far as Track Changes is concerned. If you copy cells from another row and paste them in the last table row, if the selection you are pasting into contains the last cell in the table, the pasted text will not be marked as a change. Likewise, inserting a new row in a table as the last row via drag and drop isn’t marked as an insertion at all. Inserting a new column in a table as the last column via drag and drop is tracked as an insertion for each cell in the column, except for the bottom cell.

I recognize that there are some limitations with Track Changes in tables, but the Track Changes feature should work consistently whether or not the bottom-right cell of the table is selected.

InDesign CC 2018.1, Mac OS X 10.12.6

InDesign 2018 CC 13.0.1

Pages and spreads are doing weird things when I resize my document. It creates some odd margin after resize of pages. I start out with 2 pages, document shuffling allowed, facing pages turned off.

Pagespread01112617 - shows the page spread I was working with; each page is 10”x12.25”.
Pagespread02112617 - after I changed the size to 10.68”x11.239” for another ad spread, a weird margin showed up. The content boxes show how there is an odd overlap; each box is 10.68" wide.
Pagespread03_112617 - If I move page 2 down in the Pages panel, and realign it with page 1, the margin disappears.

1) This bug occurred on InDesign cc2017 and CS6. 2) Follow these steps to replicate the bug: create a shape, let's say a circle, and then copy this circle and paste it in a separate layer directly over the top of the first. To better see the effects of the bug, make the fill of the top circle red, and the bottom blue. At this point, the bottom blue circle is completely hidden by the red circle above it. Now put a 4pt stroke with an outside alignment on the bottom blue circle. The blue circle is still hidden, and now it appears as if the red circle on top has a stroke. Before making any changes to the shapes, make sure the Dimensions Include Stroke Weight and Adjust Stroke Weight when Scaling are DESELECTED in the Transform panel options. Make sure both the Info palette and the Transform palette are visible so you can read the starting and ending measurements in both palettes. Using the selection tool, select BOTH circles together, and then pull on any corner to enlarge the two shapes together. 3) EXPECTED RESULT: the two shapes should scale together. They start with the equal measurements in both the Info and Transform palettes, and once scaled, the shapes and the measurements should still read as being equal (albeit larger) sizes. 4) THE ACTUAL RESULT: the two shapes are different sizes after scaling. Remember that Dimensions Include Stroke Weight was deselected, so the stroke shouldn’t have any effect on the shape size, and yet, the bottom shape is slightly bigger than the top. Not only is the blue circle now clearly visible and peeking out from beneath the red circle, but the Info and Transform palettes read TWO different sizes. The following are images that illustrate the bug: