--FileA_CC2019_WithoutDocumentfontsfolder.png (when I take away access to Document fonts folder, no other changes), one instance switches to "Regular" instead of "Roman"

--FileA_CC2017_WithDocumentfontsfolder.png shows what happens with I open this file in CC2017 (no double listing)

--FileA_CC2017_WithoutDocumentfontsfolder.png (Document fonts folder hidden) shows what happens with I open this file in CC2017 (no double listing)

I process large volumes of files; this is not an isolated incident nor a corrupted file. Packaging results in InDesign only grabbing the *single* correct font file, so that isn't broken. This behavior with Find Font is seemingly new to CC2019 (I'm working on 14.0.2). The multiple listing of same font, variation of font name when fonts enabled/disabled, and Find Font showing fonts missing that aren't because of what seems to be a name issue in Find Font. Has something changed in the way that InDesign reads fonts/accesses Document fonts folders?

There are multiple listings of the same font in the Find Font menu in CC2019. All information is the same, all applied characters are the same, but there is odd behavior.

When placing a Text-Frame that Adjusts in height inside of a "Master-Textframe" (Often used in DatabasedPublishing to paginate Products that should not split between columns etc.) InDesign fails to redraw the placements of other Objects correctly - AND IT EXPORTS TO PDF!

This is horrible and has already lead to some huge problems in big Projects where we needed to work this way but InDesign made it a pain.

When you check to "Prevent Manual Override" an anchored object receives a lock adornment. An object Style can be created from this object. If that lock is unlocked the Object style shows as override, but the "Prevent Manual Override" is still checked.

If the object style is redefined. The lock adornment is still unlocked, and the "Prevent Manual Positioning" is still checked. Reapplying the style locks the object.

There should be more consistent behaviour of "Prevent Manual Positioning" and the "Lock". Even though they are similar they are not the same. If checking "Prevent Manual Positioning" activates the Lock. Unlocking should also uncheck "Prevent Manual Positioning".

When you check to "Prevent Manual Override" an anchored object receives a lock adornment. An object Style can be created from this object. If that lock is unlocked the Object style shows as override, but the "Prevent Manual Override" is still checked.

If the object style is redefined. The lock adornment is still unlocked, and the "Prevent Manual Positioning" is still checked. Reapplying the style locks the object.

There should be more consistent behaviour of "Prevent Manual Positioning" and the "Lock". Even…

There is interesting bug with arabic letters. When we have aleef-lyam-aleef with harakats + footnote references with more than one symbol (from 1 to 9, no problem, 10+ or (1), problems starts) on the line, harakats swap together. Have tried with multiple fonts, most of them (adobe font too) got this error.

Tested this in 2014 and 2018 ME versions of Indesign.

Hope you can easily fix it, cause it's a real problem for book publishing.
Thank you!

If Data Merge tries to select a data source where one of its header fields is called 'table' (all lowercase), it fails to import (InDesign v 13.0.1). It doesn't seem to matter which column it's in, but changing it to anything else (e.g. 'Table' with uppercase 'T') seems to fix it.

Tried it on 2 machines, same result. Adobe Customer Care on Twitter confirmed they could replicate it and suggested I post it here.

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.

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

InDesign CC 2019 (14.0.0.130) for Mac
Filetype is the same as CC 2018. Each version has been given a unique Filetype. The only exception is v6.0.0–6.0.3 (CS4), but it was fixed as a bug in 6.0.4. I also expect it to be fixed as a bug of 14.0.0 as well.

This has been done to preclude any new entries for CFBundleTypeOSTypes. The previous release, CC2018 had CFBundleTypeOSType as IDdD but for the new release, we have not created the new OSType entry as IDdE rather kept the previos entry intact.

Apple had deprecated any entries of the form of CFBundleType from 10.5 and now recommends using a UTType(Uniform Type Identifier) entry instead of creating CFBundleType entries. We might choose creating UTTypes in the future. However, for now we have stopped creating separate CFBundleTypes for the new releases.
It would helpful to know from you as to how you use these entries in your workflows so that we can suggest you an alternative.

If I replace a swatch the text wraps at one place. It happens just with one color in the document... I doesn't matter which swatch I use for replacing... I never seen this before. I image how risky that is when you're replacing a swatch in a large project like a catalog and than somewhere in the document text is wraping...