I wondered if that might be the issue. Glad you got it figured out.
On my Mac, the fonts installed for all users by default as did the rest of Dorico.
Many non-Adobe pdf readers will interpret pages as pictures if the font information is not present. That is why some “worked” and others won’t. Acrobat Reader follows the spec and doesn’t do this as you discovered. Perhaps Adobe should follow the lead the cheapware and freeware.
Being on a Mac, I use Preview, part of the OS, which eliminates any need for Acrobat Reader.
I use Acrobat Pro in my work but not as a pdf reader. There is no 3rd party tool that has Pro’s functionality, unfortunately, because it is expensive—but so is my time.
Where do those non-Adobe readers get the “pictures” to reproduce the text, if it’s not coming from the font?
I could display the PDF correctly in a non-Adobe reader, including all the text, in the correct fonts, and I definitely don’t have those fonts installed on my own (Windows) PC.
If anyone is having this issue specifically with a font they use through Adobe Fonts (Creative Cloud), the solution Pieter mentions works, but it’s harder to find the fonts. See the following link—
And if anyone needs help figuring out precisely what to do, feel free to message me here.
For what it’s worth, you won’t need to worry about this in future versions of Dorico. The problem is specifically that the path for the font exceeds a certain length when a font is installed in the user-level fonts folder rather than in the system font folder, and this causes the name of the embedded font to be encoded in a way that upsets Adobe Reader. We have fixed this problem in the Qt framework and the fix will be included in the next version of Dorico.