Hi,
I just got a strange bug, I’m not sure if it was introduced in 2.0 or 2.1, but it definitely wasn’t there in 1.x.
I often export pdfs then import them in illustrator for additional graphics, harmonic analysis when preparing teaching materials, and such. Today when I exported a pdf using the “Graphics” tab which I always do, the resulting PDF opened fine in Acrobat, BUT when I loaded it in illustrator, it said it could not find the required fonts for Academico and Bravura (even if they are obviously installed), and seemed to try and replace some Bravura elements with Myriad Pro. After trying all sorts of things, I went to the “Print” tab, and printed a pdf using the Acrobat PDF printer. The resulting PDF, while identical visually, now opened just fine in Illustrator. There is a small 3KB difference between the two files.
This leads me to think that maybe something is not written correctly concerning font registration using Dorico’s export vs Acrobat’s export.
I’m attaching the dorico project and the 2 pdf files, for investigation.
PS: I am on Windows 10 latest update, and like I said eralier, in Dorico 1.x graphics export then open in Illustrator worked without issues.
Thanks!
Dorico PDF Bug.zip (1.82 MB)
I’m afraid I don’t think there has been any change in this area recently (though it’s possible that the behaviour changed between Dorico 1.2.10 and Dorico 2; PDF export support is provided to Dorico by the Qt application framework, and we certainly upgraded between Dorico 1.2.10 and Dorico 2). Dorico embeds the fonts as subsets but the names it chooses appear to trip up the Adobe applications, which have their own expected way of namng fonts. There’s no ideal solution to this: we aren’t likely to write our own PDF export back-end any time soon; we could introduce an option to prevent any kind of font embedding, but that would make the situation worse rather than better because then all the text would be outlined and non-editable in Illustrator.
That would be useful for svg export when you need the resulting graphics to be independent from locally installed fonts.
Thanks for the reply! I expected this to be on the “difficult to solve” side of things, unfortunately. The issue might indeed be introduced with a Qt update…
In any case, users who will use Illustrator etc. will have access to the Acrobat Distiller on their systems as part of Adobe’s CC, so at least printing throught that instead of Dorico’s export is an easy workaround. Maybe it will magically fix itself through Qt, or you will be able to address it in some distant future, it’s clearly not a priority thing to fix, but I thought it important to report.
It has to be said that Illustrator will frequently ‘not find’ subset fonts in a PDF, and the issue is not unique to Dorico’s PDFs. Surprisingly, other vector artwork editors can be better at importing PDFs than Adobe’s own!
Technically, not embedding the font doesn’t necessarily outline the glyphs, but relies on the fonts being available in the OS, in order to display them. And of course, outlined data can still be edited in apps like Illustrator, though just as vector objects.
According to Acrobat’s Preflight checks, PDFs from Dorico are well-formed PDFs, compliant to the 1.4 spec.
So as long as Dorico can export ‘good’ PDFs, then there are legions of apps to do whatever further processing might be required for other purposes, and I’d suggest that further PDF options should be much lower down the priority list than notation improvements.