Export pdf vs graphic pdf

So other than feeling stupid (which I should be used to) I feel like I learned something. Though the original question got answered - it might not be the most readable thread at the moment. A summary in penance for my own contribution to that:

  1. Not all PDF’s are created the same

  2. The option under Print Mode → “Printer” → may be O/S specific or belong a third party "IE Microsoft Print to “PDF” does not create a searchable PDF and contains less information.

  3. The option under Print Mode → “Graphics” is preferred because it is searchable and consistent.

Thank you Pianoleo and Ben for your patience.

4 Likes

I most definitely get different results from Print/Graphics/Export vs Adobe PDF and Microsoft Print to PDF as well. A big issue I have with Dorico’s Qt Print module is that at least on Windows, there is no way to directly access the settings of any individual print driver. If I open the Adobe Acrobat Distiller standalone to modify settings, I can specify all sorts of settings including font embedding, Acrobat compatibility, etc., but these all just get ignored when “printing” to it from Dorico and it uses some sort of baked in defaults, even though I’ve saved my own settings as the default (which Finale can correctly access BTW). Selecting Adobe’s “Adobe PDF” as the Printer can access any custom page sizes created through Windows Print Server Properties though.

Microsoft Print to PDF gets by far the worst results for me. It doesn’t correctly embed fonts, and it can’t access any custom page sizes, even though I created them with Windows Print Server Properties.

Dorico’s Graphics/PDF Export is the only functional one for me that correctly embeds fonts and can get the page size correct on export. The page size is quite often wrong on screen though which makes it not very useful as a final proofing pass. Creating a PDF is also an intermediate step I have to always use when printing hard copy. Because Dorico’s Qt Print module can’t access the system print settings, there is no way for me to specify the correct output size for printed output unless it is a default size for my Ricoh 6330 printer. I have many custom print sizes saved such as 9.5"x12.5" and 11"x14" that I often use for music, but Dorico can’t access them as they aren’t default sizes. (Again, this is no problem with Finale or any other program on my system.) It would be great if the Print module capability could be expanded to allow settings to be selected directly from the printer properties, like pretty much every other program I use.

tldr: Print/Graphics/Export is the only reliable way to get both page sizes and font embedding correct when creating PDFs from Dorico in Windows.

3 Likes

I was under the impression that the print size (w/h ratio) in PDF was taken from the definition in the individual Layouts.

1 Like

It is, and it exports the PDF correctly. It just displays incorrectly in the Print preview (sometimes).

I also would love to see that improved. There’s something about seeing that final step of the Print Preview display correctly before the export…

2 Likes

Yes, more accuracy in Print Preview would be a useful, confidence building feature down the road.

I’ve never quite fully understood why getting the PDF Print Preview size correct was so difficult. Perhaps I’m misremembering, but I thought Daniel at some point had said this was due to the fact that the Print Preview was created by the selected print driver, not Dorico itself. Ok, so below is from the Print module of a New from Template/Modern Orchestra file where the template defaults to A3.

The Page Setup size for the Print Preview (which is incorrect and greyed out) is 12" x 18". If Dorico knows the preview size is 12" x 18" and also knows the correct size specified in Layout Options is A3, then it doesn’t seem terribly difficult to simply mask off the additional incorrect portions of the page when rendering the preview. Maybe it is, but if I wanted I could probably do it myself with a calculator, construction paper, and scissors then tape it to the screen to view the correct size.

If Dorico knows the size of the preview reported by the print driver, and knows the user specified size in Layout Options, I still don’t really understand why it can’t come up with a correct PDF preview size.

The Dorico Development Team has accomplished so much in such a relatively short time that I don’t worry about why something “hasn’t already been done.” I trust that important things will be added or improved in good time.

It kinda works, right? :grin:

I‘m not sure if this helps, but if I have the wrong paper size in Print mode, I change from the Graphics to the Printer tab, where I am able to change it. Dorico keeps the adjusted settings for the Graphics/PDF as well as the preview and seems to save it in the project, so I won‘t have to do this frequently. So while I also wondered why we are not allowed to change the paper size in the graphics tab, it’s easy to work around.

It’s a waste of time, though. Try exporting with the wrong size in the right panel of Print mode, and then look at the resulting PDF. See?

You’re right, the PDF is correct anyways. Nevertheless, I feel I’m actually saving time because this way I can actually use the internal print mode view for what it’s meant for instead of always exporting before I can take a realistic look at the page (or take the scissors to get my frame right)! :wink:

:joy: :joy: :joy: It would be nice if Dorico could do this automatically though for final proofing before exporting.

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.

8 Likes

Thanks Daniel, these sorts of technical sidebars are incredibly helpful for those of us who are just users!

2 Likes

And they are rather interesting for the nerdy types. I enjoy these little glimpses into the machinery behind the facade of dorico.

3 Likes