Text Find/Change seems to have a bug: let's suppose we have 2 paragraph styles, for example a title style and a body text style. In the document I received from our partner sometimes the body paragraphs wear the title style and they were manually overridden to look like the body style. To fix this error I tried to search for texts that has the title style but the font used is that of the body style. Indesign Finds something at the beginning of the body paragraph (a thin cursor-like thing can be seen there: it is the selected something) that is - as Indesign states - of the title style. But as you can see on the screenshot it is definitely not of the title style.

In grep Find/Change the problem doesn't exist.

1. Affected: InDesign CC all versions that are working with CC Libraries.
Tested with InDesign CC 2018.1 and InDesign CC 2019 version 14.0.2.324 on Windows 10. InDesign versions on Mac OS X are also reported.

2. Steps to reproduce the issue:
Do a new CC Library.
Add TIFF images saved from PhotoShop CC 2019 to the new library.
Two options how you can do this that I know of:
A. Drag the files from your file system to the open and empty library.
B. Use Adobe Bridge CC 2019 to drag files to the open library.

3. Expected result:
If I want to use an image TIFF asset in my layout and place it on the page from a CC Library the placed image should show up as TIFF image with all the right properties, like the right color space, original resolution etc.pp.

4. Actual result:
The placed TIFF is converted to PNG, color space is always RGB, regradless of the original. Always indicating transparency. Even if the original file stored in the CC Library has no transparency at all.

More details can be seen in this discussion at Adobe InDesign User Forum:

Bibliotecas CC - Indesign convierte imágenes TIFF en PNG
franp30034553 Jul 16, 2019 11:02 AM
https://forums.adobe.com/message/11168505#11168505

Regards,
Uwe Laubender
( ACP )

PS: We can see the same issue with Adobe Illustrator.

PPS: Also did a bug report at Adobe Bridge Uservoice.

https://adobebridge.uservoice.com/forums/905377-report-bugs/suggestions/38165185-tiff-images-added-to-cc-library-are-considered-as

I've created a test file with links and images and test text to try and replicate the fault. Follow the steps in the InDesign file attached.

Put simply, text – whether it is UTF-8 or UTF-16 can import unicode characters that are meant to represent emojis etc, and this is demonstrated in the test file. While not in the minion character set, I've created a GREP style that looks for unicode characters and changes them to apple color emoji. That bit works.
What does NOT work is when importing the text as part of a data merge... instead the unicode characters are completely skipped.
Links to the testfile are here: https://www.dropbox.com/sh/32graq18jww5itp/AAAu0Y2bJnCiXjseSTBBFLcJa?dl=0

This is version 14.0.2 of InDesign for the mac

For example, in a business card, some employees have a direct and mobile phone number, some employees only have a direct phone number. If there is a "Direct" paragraph style and a "Mobile" paragraph style, on a record where there isn't a Mobile number, after previewing the next record with both numbers the "Direct" paragraph style is now applied to the Mobile number.

The data merge should retain the paragraph styles based on the placeholders, not the previewed data.

Images I have attached:
1: placeholder view showing Direct style
2: placeholder view showing Mobile style
3: preview view showing record without mobile number
4: preview view showing next record with mobile number (both lines have "O:" instead of top have "O:" and bottom having "M:").

See https://indesignsecrets.com/data-merge-remove-unwanted-lines.php for a better description of the problem.

Hope that helps describe the issue.

SITUATION
We migrated our old Active Directory "OldAD.ads" to a complete new one "NewAD.ads"
We use InDesign CC2019 (latest Version)

All out file-shares are mounted on client computers with Microsoft DFS-Links.
- Old DFS-Link: \\OldAD\DFS\OldShare - The DFS-Links points to a share on our old fileserver: \\OldFileServer.OldAD.ads\Share_OLD
All shares on the old fileserver are closed, so the DFS-Links have no destination but are still "available".

- New DFS-Link: \\NewAD\DFS\NewShare - The DFS-Links points to a share on our new fileserver: \\NewFileServer.NewAD.ads\Share_NEW

Both fileservers hold "their" (Active Directory based) DFS-structure.

Of course, all users open their files on the new fileserver, shares are mounted via the new DFS-structure.

THE REAL STRANGE ERROR
As long as the old fileserver and old Domaincontroller are up, InDesign acts as expected: We open an old document, the windows "missing links in document" comes up, we fix the broken links, the document opens, everything is fine.

BUT when I shut down the fileserver and the last domaincontroller, the following happens: We open an old document (containing links to documents, that were on shares mounted via the old DFS on our old fileserver), InDesign freezes and the mouse pointer circles. I waited up to 30 minutes, nothing happened. And now comes the really strange thing: When I unplug the network cable (no joke), the "missing links in document"-windows comes to front and I can fix the broken links after plugging in the cable again.
When I turn on the old fileserver and domaincontroller again, everything works fine again.

I can reproduce this error on all our 4 InDesign-workstations. The error only appears when the broken path contains a DFS-Link and the link is not available any more - no matter if the "real" share behind the link is available or not.
The InDesign option "Ignore missing links when opening a document" does not affect the error, it happens when the option is set or not.

I am seeing many issues with the new updated InDesign - it seems a lot of the issues are solved if you have no browsers open. But let's be honest that is ridiculous! First I was not able to scale items proportionately while holding down the shift key. Now I can't create new guides, however the minute I close out all my browsers this functionality begins to work.

Please fix the many conflicts between INDD and the web browsers. I am on a MacBook Pro using High Sierra. The conflicts appear when either Chrome or FireFox are open. I need to be able to use my CC programs along with my browsers at the same time - hope these issues can be resolved quickly.

Thanks

The Prevent Manual Positioning creates a Locked Object, but unlocking the widget doesn't remove the Prevent manual override.

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