[Windows] Exported PDF displays small symbols on Qt 5.4.0
Several of us tried Qt 5.4RC in the hope to see the fix for this issue #25759: pdf export gives strange results under Windows for font different from Emmentaler and discovered that the musical symbols are now all exported very small (4.33 times smaller on my windows 8.1)
I filed a bug to Qt : https://bugreports.qt-project.org/browse/QTBUG-43082
Comments
I'm not sure if the 4.333 factor is system dependent, if it's not, we could make a workaround by multiplying the font size in ScoreFont::draw.
Another possible (but even uglier) workaround is to not embed the font and use http://doc-snapshot.qt-project.org/qt5-5.4/qprinter.html#setFontEmbeddi…
True with Qt 5.4.0 too
@lasconic: mind to explain where/how to "multiplying the font size in ScoreFont::draw"?
I tried it like below, and the PDF looks OK with that, but on screen it became way too large then.
{syntaxhighlighter }
@@ -5190,6 +5192,9 @@ QPixmap ScoreFont::sym2pixmap(SymId id, qreal mag)
void ScoreFont::draw(const QString& s, QPainter* painter, qreal mag, const QPointF& pos) const
{
+#if defined(Q_OS_WIN) && (QT_VERSION >= QT_VERSION_CHECK(5,4,0))
+ mag *= 4.333;
+#endif
qreal imag = 1.0 / mag;
painter->scale(mag, mag);
painter->setFont(font());
{/syntaxhighlighter}
I don't really understand how all this works, but I do see that we use QFont::setPixelSize() a lot, where the Qt documentation suggests we'd be better off using setPointSize() for "device independence". No idea if that has anything to do with this.
I think I found how to get this to work, only do that scaling for Pdf:
if (painter->device()->paintEngine()->type() == QPaintEngine::Pdf)
There has been some movements on the Qt bug https://bugreports.qt-project.org/browse/QTBUG-43082 and they came up with a fix. It will probably be in Qt 5.4.1. In the meantime, we might use the scaling workaround if it works for all fonts and glyphs. (Not sure why it would though, but I would love to be proved wrong...)
Looks all quite OK, except for wiggly lines (trills, arpeggios) in Bravura and Gonville.
See PR #1548
Marking it fixed, as the PR got merged, even if there are a few remaining issues with wiggly lines.
But the issue with the too small symbols is fixed and the rest will probably be fixed when Qt-5.4.1 shows up.
See http://musescore.org/en/node/41691, still an issue with the nighly builds, but apparently not with self build ones
Confirmed.
Change of status to Major given the serious implications for exporting to PDF.
EDIT: Same wrong result with Emmentaler or Bravura
Very true, a must fix before 2.0 beta 2.
The reason for this behavoir is completly beyond me... (I'll try to investigate anyway)
It is not DEBUG vs RELEASE mode, it still is nightly build vs. self built.
Let's mark this one fixed, as it is fixed in Qt-5.4.0, and the builds for Windows have switch to using that.
Also we can't do anything else about it anyway ;-)
sorry, wrong, it'll be fixed in Qt-5.4.1, the workaround for 5.4.0 doesn't seem to work always and everywhere (some yet unexplored difference between self build vs. nightly build).
Another workaround is to 'print' to a PDF printer like PDFCreator (Adobe Acrobat Pro does not work).
On the last Nightly (80a58a9), I notice that export PDF (under Windows7) is done correctly again :)
Is there a particular reason for that?
Because it is not really a nightly build, but built by schepers, isn't it? If I build it myself, it works too.
This is another indication that there is something wrong with the setup of the server doing the nightlies...
Or am I wrong and the nightly build server has been fixed? If so we can mark this issue as fixed...
No, it is not the a custom nightly build by schepers (which I had downloaded previously). I downloaded there is few minutes on the usual page of musescore.org. as you can see.
The versions are different (well, I think and hope), for example, by the presence of the "special" file. None "special" file (or I do not see it?) in the version of schepers.
Version by schepers:
![schepers version.jpg]( "schepers version.jpg")
![musescore org version.jpg]( "musescore org version.jpg")
Version on musescore.org:
Another example (with the version on musescore.org, I verified...!)
Wonderful! Let's mark it fixed then.
Wonderful, sure! But which is the reason of this "fix" ? We must absolutely know it, right?
There is a fix in the code, specialy for Qt 5.4.0 and that only. For some reason it didn't work in the nightlies, but does now, so the problem apparently is gone and can no longer be reproduced. So unless it crops up again, this issue is fixed...
Well, if you say so. But I think you really get rid of this case quickly. This leaves me cirsconspect when you say, "For some reason it did not work in the nightlies, but does now" .
Personally, I would be really curious to find out what happened? History to have the extra peace of mind ...
EDIT: it works also under Windows8 and whether with Emmentaler or Bravura.
Christmas before the time...?!
Of course I'd like to know what the fix for that build server was exactly, but curiosity doesn't keep me from marking it fixed :-)
But see also #41981: All spanners with wavy lines and dynamics marks are failing when exported in PDF format
OK, mystery solved: due to a config problem this was the first version that really used Qt-5.4.0 on the nightly build server, so the first to really execute tie workaround code.
Automatically closed -- issue fixed for 2 weeks with no activity.