Regarding @gdball’s experience with exporting PDF from Dorico on Windows using the built-in graphics export and using e.g. Microsoft’s Print to PDF feature, there is indeed a difference, which comes down to a limitation in Qt (the application framework that Dorico relies upon). It’s very technical, so I apologise in advance for the jargon.
The highest quality font rendering technology available on Windows is DirectWrite, which is much better, richer and more accurate than the old Win32 GDI and GDI+ technologies. DirectWrite supports sub-pixel positioning, a much greater set of glyph shaping and positioning features in general, and OpenType font features. It’s great, and gives Windows a fighting chance of making fonts look good on screen.
Unfortunately, printing DirectWrite is a bit complicated: it requires the use of Direct2D (even though DirectWrite predates Direct2D), which is significantly different and more complex than the old GDI system. Qt currently uses GDI for printing, and so it’s unable to render fonts directly when printing or exporting PDF in the way that it draws them to the screen.
What it therefore does, to ensure that the printed and exported output matches the on-screen appearance as closely as possible, is convert every glyph – whether in a symbol font or a text font – to an outline so that it can be output at precisely the right size and position. The good news is that the printed page or the exported PDF looks great, just as it should. The downside is that the fonts are not embedded.
We raised this issue with Qt several years ago and they have so far not yet prioritised implementing a Direct2D backend for printing on Windows, which is understandable since, in the scheme of things, despite the fact that three (!) of the major music notation applications are built on Qt, overall this kind of requirement is needed by very few Qt customers.