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.