InDesign 14.0.2 on Windows 10

1) Set display performance to high quality
2) Paste an EPS or PDF into a text frame as an inline graphic. It should render crisply as you'd expect in high quality mode..
3) Start typing in the text frame that contains the inline graphic. The inline graphic pixelates.
4) Click out of the text frame or stop typing for ~10 seconds. The graphic returns to its unpixelated, high-quality state.

Context: we are upgrading 100 users from InDesign 2014 to InDesign 2019. This worked perfectly well without any pixelation or lag in InDesign 2014, but is significantly worse in InDesign 2019.
InDesign support advised me that InDesign is working as intended and I should post here if I wanted anything to change. This is not a step forward!

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.

Issue: InDesign does not support Mongolian vertical text direction from left-to-right.

Version: InDesign 2019, 14.0.2 x64

Steps:
1. Place or paste Mongolian text into an InDesign text frame by using the attached Word document
2. Skew the text frame 90 degrees (as done with vertical Chinese and Japanese).

Expected result: Please see the attached Word document and screenshot.

Actual result: Notice that the vertical text direction is right-to-left and not left-to-right. Even if the text frame is skewed in the opposite direction (minus 90 degrees) the text is just mirrored and thus not readable.

Test files and screenshot: They are attached. If need be you can download the Google Noto font called Noto Sans Mongolian that we used.

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've defined a text variable that I use for a running header. This variable is defined from the first use of a "chapter title" paragraph style that I've also defined. I've inserted this variable on my A-master page, which is synced between documents in my book. The problem I'm running into is that I've used a number of glyphs in the text comprising the first use of that style, and the text variable (my running header) looks garbled: it's missing letters and has mixed caps. If it matters, the font I'm using is Orpheus Pro Bold.

Attached are two screenshots: the first page where the header is defined (as chapter title), and subsequent pages where you'll see the garbled header at the top right.

short:
Tables, vertical lines white (in front), horizontal lines in black (in the back)
after undefined cause: horiziontal in front, vertical in the back.
Workaround: click (in top menue) on the white color again (for the vertical lines)

describe:
There is some serious complications with vertical table lines! I want to have the vertical lines cut out of the horizontal ones. This is easy, with doing white vertical table-lines. Works perfekt. But sometimes, not always to reproduce, there is a trouble, where the white lines, hide behind the black herizontal ones after copy&paste or changes in the layout. There is not really a special case where it always happen, it just happen unexpecting. The quick solution ist to mark the table, only pick the vertical line in the top menue, click on the line-color icon (where already white is choosen) and choose white again. Normaly, nothing should change, but then all things are correct again. Seems definitly like a bug.
Can you please take a look on this behavior?

InDesign version: CC 2018
MS Word version: 2013

When I import a .docx file that uses text boxes/text frames/shapes into InDesign, most of the index entries within the .docx file is lost. When I import the same .docx file after removing all the shapes, all index entries remain intact.
I've attached reference .docx files so that you can see what I mean. The .docx file (lorem_ipsum_index.docx) has five index entries, that are lost when imported to InDesign. On removing the text box from the .docx file (lorem_ipsum_index_wo_txt_box.docx), the index entries are imported properly.
My assumption is that this is an InDesign bug. Let me know if there's a fix for this.

InDesign version: CC 2018
MS Word version: 2013

When I import a .docx file that uses text boxes/text frames/shapes into InDesign, most of the index entries within the .docx file is lost. When I import the same .docx file after removing all the shapes, all index entries remain intact.
I've attached reference .docx and .indd files so that you can see what I mean. The .docx file (lorem_ipsum_index.docx) has five index entries, that are lost when imported to InDesign (lorem_ipsum_index.indd). On removing the text box from the .docx file (lorem_ipsum_index_wo_txt_box.docx), the index entries are imported properly (lorem_ipsum_index_wo_txt_box.indd).
My assumption is that this is an InDesign bug. Let me know if there's a fix for this.