pdf export gives strange results under Windows for font different from Emmentaler

• May 16, 2014 - 15:32
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
Tags
windows
font
2.0

Steps:
1- Open Promenade example
2- Style -> General... -> switch font to Bravura of Gonville
3- File -> Export... and save as pdf

See attached files for the results (compared to Emmentaler case). All fonts (noteheads, clefs, time signatures, etc...) are shifted to the left with respect to barlines and stems.

Windows 8.1, GIT commit: e47d772

Attachment Size
Promenade_Example_emmentaler.pdf 32.22 KB
Promenade_Example_bravura.pdf 37.42 KB
Promenade_Example_gonville.pdf 32.38 KB

Comments

• May 16, 2014 - 16:14

Perhaps (probably) related:

Even when using Emmentaler as your basic score font, the quarter (or other) note symbol in tempo text markings is also displaced to the left in an exported PDF. In all cases, things look fine on screen, and also in direct print. Only PDF export is messed up.

BTW, I wonder if this also might be related to #25754: Dynamics in Palette look wrong (post crossed with above :-). Do you see the same messed up dynamics palette? Or, do people who *don't* have the messed up dynamics palette see the issue with PDF export?

Reply

• May 16, 2014 - 16:23

> Do you see the same messed up dynamics palette?
Yes, I see the very same strange alignments in the dynamics palette.

I also found that a pdf saved with Nightly Build ef4c692 (which I found lying in an almost forgotten folder inside my PC) exhibits the same problem, so this bug has been around for a while. Maybe since the switch to Qt5.2?

Reply

• May 17, 2014 - 09:52

Fall back to Qt 5.2.0? Even if only to verify whether it it Qt issue?
I could give it a try, but most probably won't find time this weekend, RL in the way ;-)

Reply

• May 17, 2014 - 10:16

I converted the two fonts (Bravura and Gonville) to TTF fonts and modified the code to use them. PDF export is working correctly then. So we have a workaround...

Reply

• May 19, 2014 - 08:03

So no need to try with Qt 5.1.0? Are you going to add the TTFs and the modification to use them to the repository? Or are we waiting whether Qt 5.3 final will have it fixed, or even wait for Qt 5.3.1?

Reply

• May 19, 2014 - 14:52

FWIW, during the brief period when the builds were using the plain vanilla FreeSerif fonts, on-screen rendering suddenly improved. The TTF conversions have reverted back to to the previous behavior. I've seen it mentioned on the forums but don't know how system-specific it is. Basically, the FreeSerif font renders quite poorly on screen at various different point sizes and scaling ("space" setting and/or zoom) where you wouldn't really expect problems. In particular, the tempo text on the Promenade example has looked terrible on initial load pretty much for as long as we've been using FreeSerif. Thin horizontal strokes tend to disappear.

Not sure how well this will work, but here is a screenshot of how it appears for me (and has for a very long time, except for that brief period when it suddenly got better):

FreeSerif-render.png

Attachment Size
FreeSerif-render.png 1.71 KB

Reply

• Sep 15, 2014 - 18:04

If it is that and considering that this is more than 4 years old, to me indicates itf won't get fixed any time soon, so a workaround is needed.

Reply

• Sep 15, 2014 - 18:26

According to the description and details, Qt 5.x is not in the affected versions list so it seems like it's been overlooked, and yet is still open. Sounds like it needs a "bump" to remind someone.

Reply

• Sep 15, 2014 - 18:58

I'm using Qt 5.3.1 in my home-built version (3338af9), and PDF export using both Gonville and Bravure (both using Symbols and Text fonts) was indeed quite bad. The stems and heads were not together.

Reply

• Sep 15, 2014 - 19:03

same here, also the Windows nightlies use 5.3.1.
Oh, text fonts too? Then I need to amend my PR and convert these too
Have a test file for me?

Reply

• Sep 15, 2014 - 19:05

No, I mean I just selected both fonts (so Gonville and Gonville Text) under Style/General to be complete. That way I was using one complete font family.

Reply

• Sep 15, 2014 - 19:34

I just included the text font, I never checked the text positions of text items. So under Style/General I would select...

Musical symbols font: Gonville
Musical text font: Gonville Text

If that means you need to check the text font for the bug, so be it.

Reply

• Sep 15, 2014 - 21:44

Problem is with QT. ONLY with QT. Bravura, Bravura Text, Gonville and Gonville Text are correct font files. This is the last time to replace PDF exporter for something better than QT.

Reply

• Sep 15, 2014 - 23:34

There's no doubt the issue is with Qt and not the fonts. The preferred solution is a Qt fix or a PDF exporter that supports all 3 OS's.

Reply

• Sep 16, 2014 - 11:04

Following Jojo-Schmitz 's suggestion (http://musescore.org/en/node/31361#comment-140786) I tried to recompile Qt for windows applying the patch proposed in the Qt bug report.
In Qt 5.3.1 source, the patch should be applied to qtbase\src\plugins\platforms\windows\qwindowsfontengine.cpp at lines 808 and following (and chaging "cmap" in the patch to "ttf").

Luckily, I had kept the noSSE compilation folder, so it simply recompiled one single file (plugins\platforms\qwindows.dll). I then recompiled MuseScore with this "noSSE-pdfpatched" version (if I wanted an SSE version I had to wait for an 8-hours compilation).
The good news is that the patch actually seems to properly solve the bug. Attached are the export results with the 3 different fonts (I also changed fonttext) for this patched version of the BeetAnGeSample.xml of the xml test case. Windows 8.1, commit 3338af92
In Adobe Reader these are displayed correctly.

What should be do now?
Note that recompiling Qt is painful, but actually doable.

Attachment Size
BeetAnGeSample_Bravura.pdf 45.61 KB
BeetAnGeSample_Emmentaler.pdf 39.92 KB
BeetAnGeSample_Gonville.pdf 36.84 KB

Reply

• Sep 16, 2014 - 13:32

We should submit the fix to Qt. Following their code submission guidelines.
They are currently doing a sprint on #qt-bugs. ABL, it's up to you. I can take it from here if you want or you can submit it yourself.

Reply

• Sep 16, 2014 - 13:58

If you add a convert from OTF to TTF format Gonville and Gonville Text on GitHub - I withdraw from the project and you'll have to delete Gonville and Gonville Text from GitHub and MuseScore.

Reply

• Sep 16, 2014 - 14:05

@lasconic: Nicolas, I would be very grateful if you could proceed with the submission of the patch. I don't know even where to start for pushing a pull request to Qt git.
As I said, the file is qtbase\src\plugins\platforms\windows\qwindowsfontengine.cpp
Attached are the original version (Qt 5.3.1 source) and the patched version (I had to add .txt extension for the files to be uploaded).
We should also give credits to the original author of the patch: James Larcombe.
I remember tried to look at the minimal sample in that Qt bug report some time ago when I was trying to investigate this bug, but I couldn't see the strange behavior so I thought it was an unrelated Qt bug. Do we need a new minimal sample?

Attachment Size
qwindowsfontengine_originalQt5.3.1.cpp_.txt 45.25 KB
qwindowsfontengine.cpp_.txt 46.19 KB

Reply

• Sep 16, 2014 - 14:06

Why would you take that attitude? The TTF submission would only be until Qt fixes this bug, and that doesn't seem difficult. I for one want to see Gonville in MS, but if it takes a few hacks and necessary steps until Qt is fixed, so be it.

Reply

• Sep 16, 2014 - 14:07

Isn't the patch already there? Someone just needs to "bump" the bug report so it's noted for 5.x as well, which it isn't right now and so seems overlooked.

Reply

• Sep 16, 2014 - 22:46
Status (old) active ⇒ patch (code needs review)

ABL: I know that open and convert the font file is very easy for you. But... this is not a convert from .doc to .odt! "Recompiling Qt is painful, but actually doable." - Yeah... Converting font is more, more, more and MORE painful - believe me...
TTF fonts - ok, but You and Jojo will be fixed all bugs in each glyph (("only" 3000 glyphs in Bravura and about 200-300 in Gonville) x2 - because each font contains 2 files).

Attachment Size
your_font.png 13.84 KB

Reply

• Sep 17, 2014 - 08:38

@Gootector: Dear Grzegorz, in #31 I didn't mean to push the patch to MuseScore, but to push the pdf-font patch (from the Qt bug report, but corrected for Qt 5.3.1) upstream to Qt.
I also think that it is better to solve the problem at its root, especially when we know where it originates and we know a way to solve it, rather than using work-arounds.
And, by the way, the PR with the ttf fonts is not mine :-)

Please, let's all of us calm down. :-)

I think there are two problems for solving the problem at its roots:
1- Qt 5.3.2 was released yesterday, so we should hope that a 5.3.3 version will be released with the pdf fix, or we could wait and use the 5.4 version (if with the pdf-fix; note: expected release date: November), but this will require necessary corrections to MuseScore code and will introduce possible regressions/new bugs, as the one we are facing now.
2- the patch proposed in the Qt bug report does not seem very clean to me, but I know almost nothing of Qt code; I saw that when a GGO_METRICS appears in the code, it is inside a "#ifndef Q_OS_WINCE" condition, so maybe this patch could break something for Windows CE.

We could maybe investigate other possibilities for saving pdf files (what about Cairo, which, if I am not wrong, it is used also by Inkscape?)
Or, as I somehow was trying to suggest, we could recompile a patched Qt. If I managed to have a Qt compilation working (after a little of work), everybody can have it: I simply followed a pair of tutorials on-line!
We just need to compile a patched Qt once, and then use these binary files for MuseScore compilation, and only for the Windows one.

Reply

• Sep 17, 2014 - 08:42
Status (old) patch (code needs review) ⇒ active

Putting again to "active" state since the proposed PR has opened up a hornets' nest.
I say again: please let's all calm down.

Reply

• Sep 17, 2014 - 09:00

To ABL: Ok, Dear Antonio. I admit to having made a mistake with assigning those pdfs yours. I'm also thinking about this problem and I'm searching good open-source pdf-exporter.

Greetings,
Gootector

Reply

• Sep 17, 2014 - 13:04

If we are talking about Cairo, it's far more than just changing the PDF export code but the complete 2D drawing engine in MuseScore. That's quite a big jump but could be interesting in the long term. But it would have a lot of different impacts and open up a lot of potential new bugs...

Another possible candidate would be Skia 2D too https://code.google.com/p/skia/.

Currently we use QPainter and it enables us to draw the score on the screen on Windows, Mac, Linux (intel and arm), *BSD, Android, iOS (and probably on Windows Mobile but not tested). It also enables the export to PDF, PNG, SVG and the printing support. It lets us draw lines, rect, circle, polygon. It also let us draw texts (ok with some bugs and platform differences).
If we want to replace it, we need at least the same support.

Regarding PDF export from Qt, it's another discussion. Some answers here http://qt-project.org/wiki/Handling_PDF We are currently using the approach referred as "manual QPainter painting".

Now, regarding this tiny bug, because yes it's tiny... I'm in the process of building Qt on Windows and I will try to submit a patch as soon as possible. Probably on Qt5.4 and if possible with a backport to 5.3.3.

Reply

• Sep 17, 2014 - 13:44

@lasconic: if this can be useful, here is the configure I used for the "noSSE" compilation:
configure -prefix C:\qtcomp\5.3noSSE -opensource -confirm-license -release -platform win32-g++ -c++11 -opengl desktop -largefile -accessibility -no-sse2 -no-sse3 -no-ssse3 -no-sse4.1 -no-sse4.2 -no-compile-examples -nomake examples -nomake tests -icu -openssl -I C:\qtcomp\icu\include -I C:\qtcomp\openssl\include -L C:\qtcomp\icu\lib -L C:\qtcomp\openssl\lib
In order to have QtWebkit I had to compile icu in msys+MinGW, and I also compiled openssl the same way.

Reply

• Sep 17, 2014 - 15:22

Yeah, scores look very nice, but in pdfs are bugs - something is wrong with kerning of letters in dynamic and combined mordents are displaying incorrectly. Bugs are in both fonts - Bravura and Gonville.

Reply

• Sep 17, 2014 - 15:33

Interesting... so it is Adobe Reader XI and Adobe Acrobat Pro XI on Windows and their plugins for IE showing the problem (Adobe Reader on Android does not, nor does Android's Pdf To Go)

Reply

• Sep 17, 2014 - 15:55

Sibelius 7 uses otf fonts and qt to export pdfs.
Qt used by MuseScore auto-generate from otf to ttf fonts. See Properties each of pdf - all fonts are ttf...

Reply

• Sep 17, 2014 - 17:37

Sibelius 7.5.1 build 209 uses Qt 4.8.0 (C) 2011 Nokia Corporation and/or its subsidiary(-ies) and pdf format 1.4.
Fonts are converted from otf to ttf...

Reply

• Sep 17, 2014 - 21:20

@Jojo-Schmitz - Yes, everything seems to be ok on Windows using Firefox. I attached screen with all 3 files side by side.

Interesting is that when I "print" those files in Firefox using virtual PDF printer, new files look fine no matter what browser I use (Adobe Reader, Foxit, etc...).

EDIT: I also attachet files from the 1st post "printed" to PDF in Firefox.

Attachment Size
Firefox.jpg 710.21 KB
Firefox_Bravura.pdf 84.01 KB
Firefox_Emmentaler.pdf 72.6 KB
Firefox_Gonville.pdf 72.74 KB

Reply

• Sep 17, 2014 - 21:31

You're right. So that has to be something related with embedding.
And Firefox may show PDFs using fonts installed in the Windows, not embedded in the file. That's why PDFs in Firefox look fine.
I will delete all musescore fonts to confirm that.

Reply

• Sep 17, 2014 - 21:34

SirPL: See Properties your exported pdfs and Fonts. If you see TrueType instead OpenType - the pdf file was wrong generated and fonts aren't embedded. Qt doesn't embed otf fonts, but (qt) converts otf to ttf. Do you understand?

Polish:
Zobacz Właściwości eksportowanych pdfów i zakładkę Czcionki. Jeśli widzisz TrueType zamiast OpenType, to plik został źle wygenerowany i czcionki nie zostały osadzone. Qt nie osadza czcionek otf, tylko przekształca je w ttf. Rozumiesz?

Reply

• Sep 17, 2014 - 21:48

That makes no sense because I deleted all musescore files and fonts from my computer, and PDFs still look fine. I rebooted Windows to be sure that fonts aren't stored in temp files.
There are no fonts listed in the Properties. So if they are not embbeded in files, where are they...?

@Gootector - How can I determine if those fonts are in TTF or OTF format?

Reply

• Sep 17, 2014 - 22:32
  1. Open PDF Viewer, for example PDF-XChange Viewer.
  2. Open pdf.
  3. Click File, Document properties..., Fonts.
  4. TrueType - TTF, OpenType - OTF.

In your pdf files fonts aren't embedded and this bookmark is empty! Those aren't fonts! Those are monsters! :D The most terrible I've ever seen!

Reply

• Sep 18, 2014 - 09:01

I have to apologize to Gootector: I had not understood his comment about pdf, I thought he was thinking I was using the ttf version for the pdf, but I was using the otf version and the fault was only of Qt.

In summary, we seem to have two Qt bugs.
Or, saying it better, one Qt bug and one ugly Qt shortcoming:

1- Ugly shortcoming: since Qt has problem in embedding OpenType PS fonts to pdfs, these are transformed into ttf fonts when printing to pdf, corrupting the shapes of the glyphs, as shown in comment 36. I was not aware of this shortcoming, but, as Gootector said, if you look at the pdf properties only ttf fonts are embedded and if you zoom in you can see that the shapes are corrupted.

2- Qt bug: the horizontal position of these glyph is not correct. However, in the minimal example attached to the Qt bug report I cannot reproduce this behavior. Moreover, in the original Qt bug report there is a proposed patch that solves this bug. But ONLY this bug, not the ttf-transformation shortcoming (and related shape corruption).

Firefox is passing the pdf through a JavaScript to visualize it: it is transforming the OpenType PS fonts to paths (and it seems it is introducing shape corruption, as in Qt ttf-transformation). In other words, these are no more font characters, but (vectorial) "drawings".
This very same trick is the one which was previously used by Qt. For example, if you use an OpenType PS font in MuseScore 1.3, when exporting to pdf the characters are transformed to paths (and you can't see them in the pdf properties). Note that this trick generates larger pdf files, in some cases MUCH larger files.

If a virtual printer is used to print to pdf it seems that OpenType PS fonts are embedded properly. I tested with CutePDF Writer (beware of the adwares if you want to install it!), which is saving pdfs through GhostScript (but I still do not know the passage from printer instructions to GhostScript).

Are there any open-source virtual pdf printers we could rely upon?
As Gootector is suggesting, how are the people at LibreOffice doing?

Sorry if it is difficult to understand what I am writing, but English is not my first language. And I think that the language barrier has generated some misunderstandings in this discussion.

Reply

• Sep 18, 2014 - 13:08

ABL:
:D
Re 1-: Exactly, otf fonts are converted to ttf, corrupted and aren't embedded as otf fonts.
Re 2-: Exactly :D

"Firefox is passing (...) but (vectorial) "drawings"." - or bitmaps - I don't know what is it; something similar to font, but not the font.

About OpenOffice and LibreOffice - old versions didn't support otf fonts. Now otf fonts are supported.

No problem, english isn't my first language also.

SirPL:
*OTF - OpenType or Type 1

Reply

• Sep 18, 2014 - 14:54

Really?
I "composed" this exemplary "score".

Properties of pdf file:
- Ghostscript 9.14
- PDF version 1.4
- ttf and otf fonts - embedded
- resolution: 4000 dpi - max
- generated by PDF24 Creator

This pdf file is better quality than generated by LilyPond, Sibelius, etc.

I used the newest nightly of MuseScore 2.0.

Attachment Size
Title_test.pdf 57.52 KB
Title_test.mscz 3.86 KB

Reply

• Sep 18, 2014 - 15:01

I don't claim to know much about PDF, but the statement "OTF font embedding will lead to violation of PDA/A-1 [specs]" to me means you can do it, but it's not guaranteed to work, So trying to embed OTF fonts in pre-1.6 PDF's is non-compliant unless they are stripped to appear like TTF.

Is there a way to tell Qt to export using a higher PDF spec, like 1.6?

Reply

• Sep 18, 2014 - 15:52

lasconic: Affero General Public License - AGPL - License of Ghostscript 9.14... is compatible with GNU GPL (MuseScore)? Wikipedia: Linking from code with a different license - No (except for GNU GPLv3). MuseScore is licensed under version 2.0 of GNU GPL. I have right?

Reply

• Sep 18, 2014 - 17:13

When I use Acrobat Reader to look at any PDF you've mentioned and check the font embedding, it only reports the fonts as either "Type 1" or "TrueType". Given that these are 1.4 or 1.5 PDF's, how can you prove that these are truly embedded OTF's, and not stripped OTF's that the Adobe posting claims are required?

And many, many tools still produce 1.3-1.5 PDF's as they are suitable for most needs. Only with the requirement to embed OTF is there now a need for MS to export using PDF/A-2.

Reply

• Sep 18, 2014 - 17:27

Read the article. Judging from that, they are not "true" OTF anymore whereas 1.6 allows for OTF embedding without any conversion. Like I said earlier, I'm not a PDF or font expert, just doing a lot of reading about the PDF format requirements pre 1.6. If Qt is adhering to the standard for <1.6 PDF's, they cannot embed OTF.

Reply

• Sep 18, 2014 - 17:40

I opened my pdf - Title_test.pdf - in FontForge - and... schepers - you are right in 90%:
1. Type 1 - we see Type 1 in pdf viewer - Type 1 is font format similar to Type 2/CFF (my mistake). Gonville font and Gonville Text are in Type 2 (CFF) - http://en.wikipedia.org/wiki/PostScript_fonts#Type_1.
2. My pdf has embedded 3 fonts only:
- FreeSerif,Bold
- FreeSerif
- GonvilleText
3. Gonville isn't embedded, but is converted to cubic curves.
4. GonvilleText was converted from Type 2 to Type 1?
If...
5. Wikpedia says:
"Type 2 is a character string format that offers a compact representation of the character description procedures in an outline font file. The format is designed to be used with the Compact Font Format (CFF). The CFF/Type2 format is the basis for Type 1 OpenType fonts, and is used for embedding fonts in Acrobat 3.0 PDF files (PDF format version 1.2)."

Questions-suggestions:
1. Where is the Gonville.otf font?
2. Why the Gonville.otf was converted?

Reply

• Sep 18, 2014 - 17:46

Jojo-Schmitz: PostScript glyph data can be embedded in OpenType font files, but OpenType fonts are not limited to using PostScript outlines. PostScript outlines in OpenType fonts are encoded in the Type2 Compact Font Format (CFF).

Reply

• Sep 18, 2014 - 18:02

Simpler: Type 1, Type 2... generations/revisions of PostScript.

Type 1 - Type 1 OpenType
Type 2 - OpenType CFF (Gonville.otf, GonvilleText.otf)
Type 3...
...Type 42

Our goal - embed Type 2 in pdf/embed cubic curves without defects.

Reply

• Sep 18, 2014 - 18:16

Just for info: Adobe Acrobat Pro XI's PDF printer does not work, it complains not just about Bravura and BravuraText, but also about FreeSerif, which is a TTF (I think) and wants to replace them all with Arial, which then fails completly

Reply

• Sep 18, 2014 - 18:19

Wow, digging into the whole font formats... what a confusing mess! Educational but confusing. I remember Type 1 fonts from my days in DTP when the "Macintosh Office" first came out. At least back then they were called Type 1, they were not OTF. I'm thinking there's multiple types now called Type 1 since OTF is an extension of TTF.

Reply

• Sep 19, 2014 - 07:58

The proposed change https://codereview.qt-project.org/#/c/95188/ has been merged into Qt and so it will be in Qt 5.4.
Qt 5.3.X only accept critical fixes, so this fix will not be in.

As I said earlier the whole matter of embedding OTF font, CFF, Type 2 in PDF is better suited in another thread. Please... Also it would be better to have this in Qt. I'm not a fan to add another dependency to MuseScore just for this, whatever the license is (and yes, MuseScore is GPLv2, so AGPLv3 is not working). Also it would be good to know if it's just a windows problem, like the one in this thread or a more general one. But please, in another issue.

Reply

• Sep 19, 2014 - 14:10

Ok. This problem will be fixed... - we'll see... It's hard for me to believe because Type 2 is very popular font format. I'm surprised that in version 5.4(!) will be available.

Reply

• Sep 20, 2014 - 10:54

@Jojo-Schmitz
So we wait for Qt 5.4 and include that with 2.0 Beta 2 or 2.0 release? Considering that 5.4 is currently planned for 18th November and all the possible regressions it may bring us?
And all the other benefits, yes, we wait. We might use a beta version on windows, in the nightlies.
Only other solution would be to patch 5.3.2 and build nightlies with it. It would mean self built would not have the fix or we document it... It's too much overhead for me.


No intermediate workaround?

Converting the fonts to TTF is not a viable workaround. Only good one I can see is patching. But the bug is so minor, it's easy enough to use a PDF printer.

@Gootector, consciously or not, you drifted this thread from a simple bug about shifted glyphs in PDF export on Windows when using OTF fonts to MuseScore should export PDF embedding OTF fonts. This bug report is about the former not the latter. The former will be fixed as soon as MuseScore is shipped with Qt 5.4 since it has been fixed in Qt. The latter is a non related matter as far as I'm concerned. The fix applied to Qt 5.4 will not fix it, and if you want to discuss it, in a constructive and respectful way, your knowledge is welcome here #33701: PDF export should embed OTF fonts.

@All, please only discuss the original bug and its ramifications in this bug report.

Reply