Different (wrong) rendering in print mode


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.

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 :slight_smile:

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!