Hi,
I noticed a different rendering in Write/Engrave Mode and Print Mode :
The rendering in Print Mode is obviously not correct.
Interestingly, the exported PDF is rendered correctly.
The rendering in Print Mode is obviously not correct.
I wouldn’t worry too much about this provided what gets printed to paper and exported to PDF looks correct.
Daniel, I am a solid Dorico fan and have the greatest respect and admiration for your role in overseeing an absolutely top-notch team and communicating so faithfully with Dorico users on this forum and elsewhere. However, I am so surprised by your answer that I wonder if I misunderstand the nature of Andreas’s concern. Assuming the two attachments are screenshots of what appears on the screen in Write and Print modes, is it acceptable to the Dorico team to require users who see apparent mistakes on their screen in Print mode to have to print out hard copies to verify whether the mistakes also appear on the printed page? My apologies if I am misunderstanding something here.
We have limited control over what appears in the print preview in Print mode, since it’s rendered for us by a standard “widget” provided by the application framework we use. Unfortunately it is impractical for Dorico to use precisely the same drawing APIs when drawing normally to the screen, when drawing to the print preview, when drawing to the printer, and when drawing to a PDF or other graphics file. In general these different “surfaces” are abstracted away by the application framework, and in general you do get consistent results between them. However, in particular when it comes to font characters, there can be some variation, particularly when the requested character is not available in the chosen font: then the behaviour is essentially undefined, or at least impossible for an end user to predict, because the application framework will make its own choice about which font to use to show that character, and different pathways through the drawing can cause the framework to produce different results.
What is happening in this particular case is that the “almost equal to” character (≈) is not present in Petaluma Script, and so it is being substituted by the application framework; as I say, this can result in different results depending on the pathway that is taken to eventually displaying the character. Ultimately the correct solution is to add this character to Petaluma Script, which we’ll try to do in the future.
Hi Daniel, thanks for the detailed explanation. I already suspected that the rendering in print mode is kind of a 3rd-party thing, like the “famous” qt-framework 
Daniel, thank you for your explanation. I appreciate understanding what gives rise to the problem but also regret sending my earlier post when I’m sure you have many, many more pressing things on your plate with the continuing work on Dorico 3. You and your team are a blessing to musicians everywhere!
I realize this is an old thread, but I was about to open a new thread and figured the answer might be the same (i.e. “we can’t do much about it.”) But this is a significantly different symptom, so I’d like to get it in the record.
I have noticed that the page representation (i.e. the white rectangle with a drop shadow) that one sees in PRINT mode is almost always reasonable. However, when I have a condensed score going to LETTER paper in PORTRAIT mode. the dimensions of the rectangle are completely wrong. As in the older case above, the rendered PDF is correct, so it is more of a “What did I do wrong? Oh I guess that’s just the way it is.” moment.
For the record, here is an example.
And here are the options for that layout:
All the parts layouts in this project are also Letter-Portrait and they display properly in PRINT mode.
I have only seen this with condensed scores with Letter-Portrait, but I have only been doing such condensed scores recently – and I must add that feature is absolute magic. But everybody knows that already. I don’t know that this problem is associated with condensing. If anybody is interested, I can do more experimentation.
Are you printing or exporting graphics, Craig? In particular when you show the “print” preview for graphics export, Dorico is actually using whatever the current settings are in the Print destination, rather than the Graphics destination, so if your printer is currently set to produce a landscape print, that would explain the disparity.
You are correct, sir. I never print directly from Dorico, but the print setting for that layout was set to LANDSCAPE while the PDF setting was PORTRAIT.
That all makes sense. Is it not possible for the display to match the mode (printer or graphics) one is currently viewing? Again, this is a very minor thing, but one of those nitpicky things that might annoy a new user who is struggling to love the product.
And I should also mention I continue to be amazed at how fast Dorico renders PDFs. It is almost too fast because late at light I sometimes wonder if I actually clicked the export button. Can we have a setting to slow things down after midnight?
This is what I see when I ask for a landscape Print of a 747 x 420mm layout, regardless of whether I stipulate graphic or printer.
Right, but as Daniel says, the actual display uses only the settings in the Printer tab. I bet your print and export dimensions and orientation are both set the same. Mine were set differently, which caused the confusion.