PDF export should embed OTF fonts

• Sep 19, 2014 - 08:33
Type
Functional
Severity
S5 - Suggestion
Status
closed
Regression
No
Workaround
No
Project

PDF export should embed OTF fonts rather than convert them into TTF ones

See discussion in #25759: pdf export gives strange results under Windows for font different from Emmentaler


Comments

I have no strong evidence (and no specific knowledge), but I suspect that, if such a conversion does happen, be done transparently by the Qt PDF layer.

In which case I believe there is little we can do about it, except dropping PDF export altogether and rely on third party tools. Which would be a *real* pity as, for instance, command line export to PDF would be no longer possible (at least with solutions like the "PDF print driver").

And all of this to support a bogus, proprietary OS...

M.

(P.S.: yes, I know, it is the most widely used OS, but it is both bogus and proprietary nevertheless...)

First, I have no evidence (yet) that the fonts are converted to TTF by Qt. As far as I understand, some information are just stripped.

Next, I don't see the point to embed OTF type 2 fonts if there is no graphical problems in the output. If they are difference, I believe we should first check them out, evaluate how bad they are and act in consequence.

So what's wrong with MuseScore PDF output currently regarding OTF fonts (considering #25759: pdf export gives strange results under Windows for font different from Emmentaler is fixed) ? Give examples, explain why it's wrong, and how it would be better if the font embedding would work differently.

Please, pretty please, don't start again with a flame war and so avoid low quality arguments about OS nature, format superiority etc... Just the facts...

They are converted by Qt QFontSubset::toTruetype() function, defined here:
https://qt.gitorious.org/qt/qtbase/source/a5df2e7120412dfdedb9f4951cdb0…

it is also explained in one comment here:
https://bugreports.qt-project.org/browse/QTBUG-10094?focusedCommentId=2…

that this function is called by QPdfEnginePrivate::embedFont.

If you look for example at the dots beside the bass clef when exporting a pdf with Gonville fonts at a very large magnification and compare them to the same dots you see on the screen, you will see that the shape is corrupted in the pdf.

Note that this does not happen under Mac (at least for me), since the OpenType PS fonts are converted to paths during pdf export, but the file is (much) larger.

EDIT: Here is where it is called in embedFont function:
https://qt.gitorious.org/qt/qtbase/source/a5df2e7120412dfdedb9f4951cdb0…

Ok. I see the problem with the dots in Bravura and Gonville when I zoom at the maximum. Anything else? It's quite minor if it's the only problem.

The fact that OTF files are not embedded at all on Mac is more important problem according to me. (I can reproduce).
https://bugreports.qt-project.org/browse/QTBUG-10094 is exactly about this problem and there is a work in progress on codereview https://codereview.qt-project.org/#/c/92837/ Apparently it's not ready for prime time yet.

Status active fixed
Regression No
Workaround No

Should be fixed ever since we went up to Qt 5.9, probably much earlier, Qt claims it fixed for 5.5.0