Fonts displayed incorrectly and justified differently on-screen and in PDF

Dorico
1

Hello @Jazzisfaction,
If you decide to make the “censured” duplicate version, I would welcome to see it appearing, and we’ll look at it. We experience also serious problems of divergence between the Dorico display on screen in Engrave mode and on paper (they are identical), but differences in export of SVG and PDF, related to the use of fonts in the Museo family (like: on screen a text block is justified, in SVG and PDF export it is left aligned).
@Lillie_Harris : should we report these issues in the present thread, or create a new thread?
Robrecht

2

I’ve moved this discussion to a new thread. You’ll need to provide a minimal example that allows us to reproduce the problem. You should also supply the actual fonts you are using. It is probably contrary to the licensing terms of the fonts to post them publicly, so I suggest you send the material directly to me at d dot spreadbury at steinberg dot de.

3

Thanks Daniel.
We were using Museo fonts that were publicly available on the web, but that are causing problems.
We’ll document the issue here as good as possible, with relevant material, and links to the fonts we were using.
We are also using demo fonts (Museo Slab family) that we received last week from Fontspring.com, we’ll check with them whether we can use the fonts to illustrate the issues here.

4

We created a small test project that contains 1 page with text, and a second page with a staff without music. Only the first page is relevant for this post.
We test two font families:

Please note that this font family has two styles: Regular and Italic. Bold and Bold Italic do not exist. The weight of the font is given by a number in the font, for example Museo Slab 300 is lighter than Museo 500 which is lighter than Museo 700.

The Dorico project was created on a Windows 10 (up to date) pc with Dorico 4.3.20.1130. Here are the files:

Test conclusions:

  • On the Windows pc that created these files, the visual display on screen and the paper print of the 2 PDF’s and the PNG match the visual display Dorico Engrave and Print modes. The paper prints can be put on top of each other, and no difference can be seen when keeping the superimposed pages against the sunlight.
  • On that same Windows pc, the rendering of the SVG is a total disaster: the Museo fonts are not rendered correctly, and the text is left aligned instead of fully aligned.
  • When opening the .dorico project on a Mac with all the necessary fonts installed, Dorico says the fonts are not present, and the window to replace fonts pops up.
  • When looking at the SVG on Mac, the Zapf Dingbats is not recognized.
  • When inspecting this SVG with Programmer’s Notepad, a lot of anomalies can be seen, for example
    image
    image713×134 10.2 KB
  • Anomalies are: a font-family “MS Shell Dig” is mentioned. No idea where this comes from.
  • font-weight=“400”; actually, the font weights used are 100, 300, 500, 700, not 400.
  • font-size=“11” in line 169, and 285 in line 171; actually, font sizes used are 10 en 14.
  • When opening the SVG on Mac, the ZapfDingbats is not recognize (the Mac has not that font installed).
  • The problem is specific for the Museo family. When replacing the Museo Slab by Times New Roman, and Museo Sans by Arial,
    Dorico Museo font Arial - Times test 02.dorico (1.3 MB)
    and you generate an SVG, the display obtained is correct:
    Dorico Museo font Arial - Times test 02 - Full score 001
    Dorico Museo font Arial - Times test 02 - Full score 0014950×7008 354 KB

What’s the utility of an SVG if you need the proper fonts to be installed, and that even if the proper fonts are installed, they are wrongly referenced?

If anyone knows a solution to generate correct SVG’s, or if you see what we are doing wrongly, you are most welcome.
Robrecht

5

Zapf Dingbats comes bundled with MacOS, so adding a Bitstream version creates a conflict. What do you see in FontBook on the Mac? Perhaps the Bitstream font has been automatically disabled.

6

I’m not sure I really understand “MS Shell Dig 2” either, but I have noticed that if I force Dorico to reference a Paragraph Style that doesn’t exist, then it will substitute it.
shelldig

In the above example, I have a shortcut set up for my “System Text” paragraph style. If I delete my userlibrary.xml file so that paragraph style no longer exists, restart Dorico, and attempt to apply the shortcut, MS Shell Dig 2 is substituted. I’m not sure how exactly that applies to your example, but I’m guessing there’s some sort substitution issue at play where Dorico is substituting it instead of your desired font.

7

This is what I see on the Mac:

Font Book Zapf Dingbats
Font Book Zapf Dingbats1318×804 99.3 KB

8

Yes, but do you see both versions in the list, and is one of them disabled?

9

I see only one version…

10

I’m intrigued too.
On the next line (171) the Museo Sans 700 is being referenced. So why is there first a reference to that MS Shell Dlg 2?

11

Just to illustrate one more issue with the Museo fonts:
I sent a project containing Museo fonts to a colleague. After he edits it, I open his work, and get the message
image
Obviously, I do have these fonts installed, as the original project came from me…

12

This is probably an interaction between: the not-very-good way that font styles are handled in Windows; the not-very-good name definitions used in the fonts; and Dorico’s handling of font styles (which is probably that of the Qt framework, and therefore out of Dorico’s hands).

Windows assumes that every font has styles named Regular, Bold, Italic, and Bold Italic – even if they don’t exist. Styles with other names e.g. SemiBold, Condensed, are handled as separate font families., each with their own Regular, Italic, Bold and Bold Italic styles.

There’s also something screwy in the font weight numbering, as 300 is used for the Regular and the Light.

As for Zapf Dingbats: as said, that’s a system font in macOS, which may differ from your Bitstream version.

13

Hello Ben,
Could be, but the QT framework is not out of Dorico’s hand. As that framework is open source, the Dorico team has the possibility to change / improve the code, particularly if it contains errors, which is not demonstrated in this particular case. However it is demonstrated here that

  • the font handling in SVG exports from Dorico is problematic
  • the font handling within Dorico between Windows and MacOS is problematic.

@dspreadbury : does your team have any light to shed onto this issue, please? If useful, we can supply more test files.
Robrecht

14

Please don’t bump threads. I know it can be frustrating to wait for an answer, but when you are posting a very complex issue that may require multiple hours (or even days) of investigation, you will have to be patient. As you can appreciate, I have many other duties beyond handling threads here on the forum. Thanks for your forbearance.

1 Like
15

Hello Daniel and Team,
Sorry that my message came over as “bumping”. I didn’t mean that whatsoever, and was not aware that it could come over like that. For me, not being a daily user of the Forum, it is not yet always clear whether a discussion on the Forum is just between members, or whether the Dorico team is also actively involved. In this particular thread, I was not aware that is was already on your radar screen.
Thank you so much for taking care of the issue. I’ll wait patiently :slight_smile: .
Warm regards, Robrecht

16

Dear Robrecht, @dspreadbury reads every post, we users simply try to lighten its burden when we can :wink:

2 Likes
17

Thanks Marc, I’m absolutely impressed that Daniel can manage that. My admiration and respect for that is very profound. Robrecht

2 Likes