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.

I have reported a variation of this—back with CS6—but it seems not to have been fixed. I assume it's a bug, but if someone can enlighten me about what I might be doing wrong and how I can fix this, I'd appreciate it.

I often work on books that include Arabic and Hebrew words and phrases in the middle of English text. They only way to get the Arabic ligatures to form is to use one of the World Ready composers. When I do that, though, the kerning around some English characters often—but not always—is affected. I have tried turning on and off various settings—justification settings, kashidas, etc.—and their effect seems to be random. Sometimes the changes fix the problem until the page redraws, sometimes the errant kerning is corrected in one location but shows up in another location, sometimes nothing happens at all. I'm attaching two screen captures of a book that I have in production now with the word "economics" selected in each. In the shot with the World-Ready Paragraph Composer active, you can see the extra kerning between the "e" and the "c." In the shot with the WRPC deactivated, the word looks as it should.

Is this a bug? If not, what am I doing wrong? If it is, when might we expect a fix. Unfortunately, I have a deadline on this project now and can't see any reasonable way to fix this. Thanks for considering this problem.

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.

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

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

I am trying to create a 9x12 horizontal postcard with 4 vertical columns and 5 horizontal rows. Then I merge cells to create different size ad boxes. By the time I get to the last merge, it pulls everything up and looks like it is adding another row at the bottom. For example: merge the whole bottom row into one ad box; merge the right column 4 boxes into one ad box; merge the left 3 boxes beginning from the top into one ad box; merge the center 6 boxes into one large ad box. So, there should be a total of 7 ad boxes. InDesign is making it into 8 ad boxes with the additional one at the bottom. How do I avoid this? I have tried it with a different merge pattern and it continues to do the same thing.