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.

Page_spread_01_112617 - shows the page spread I was working with; each page is 10”x12.25”.
Page_spread_02_112617 - 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.
Page_spread_03_112617 - If I move page 2 down in the Pages panel, and realign it with page 1, the margin disappears.

1 – InDesign 2020 15.0
2 – Have standard copy with headings and body copy with PDF export tags applied (H1, H2, P etc). Add images between sections of text. Drag elements into the Articles panel in the correct reading order and tick 'Use for Reading Order in Tagged PDF.
3 – Images should be in the right order
4 – Images are not in the right order. All figures are in a <Art> tag. This was not an issue in InDesign 2019.
5 – Order should be first block of text, image (1) and then second block of text with an anchored image (2). Result (in second screenshot) is first block of text, second block of text and the anchored image, THEN image 1.

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

I have set up articles in multiple files InDesign 2020 (files first created in InDesign 2019 and updated to 2020 yesterday and today). When I export to PDF, all image tags are added to a new article in the bottom of the tags panel in Acrobat DC rather than in the articles that I assigned them to in InDesign. Luckily, I preserved a version of InDesign 2019 and can open them in there and export to have the tags show up in the correct place. FYI, I also made sure my layers order in InDesign is as I want it to be.

A much used droplet to export one or more InDesign documents to PDF (with dialog and settings) will not work with InDesign 2020 (v15.0.0.155) anymore (fine with InDesign CC 2019). InDesign 2020 opens the first (or the only) document. I can select options in the upcoming dialogue box, but then crashes immediately by clicking OK with an error message (see screenshot).

However, the same base code of the script works directly from InDesign to export the active document to PDF without any problems.

InDesign 2020 may not handle "on open ..." and / or "repeat with ..." in the droplet ?!

macOS Mojave 10.14.6
same on MacBook Pro 2019 and MacPro 2012

Joerg

I'm experiencing a bug where Nested Line Styles are interfering with Grep Styles.

To reproduce:
1. Create a Character Style "Small Caps" that only applies OpenType All Small Caps.
2. Create a Character Style "No Break" that only applies the No Break rule.
3. Create a Paragraph Style "Test":
    a. In Nested Styles, add Small Caps for 1 line
    b. In Grep Styles, add:
        i. Small Caps: ([\u\d&@#\$%/]{2,}(?!\l{2,}))|([\d\&@#$%]+)|(I'D)
        ii. No Break: (?<=.{55}).{15}$
4. Fill with placeholder text, and add a string of capital letters (something that matched the Small Caps grep) somewhere in the middle

You'll notice that the line style and grep small caps work, but the No Break style isn't being applied. Switch the order of the grep styles (No Break first) and now it's the opposite—No Break works but not Small Caps.

Now, remove the Line Style, and suddenly both grep styles work.

Refer to the attached screen shot. I can also provide a sample .indd file with the styles prepared. I've used styles set up like this for a while without problems, so this may be related to a recent InDesign update.