[minor] Top of treble clef cut when printing
First of all, thanks to everybody who contributed to musescore. It's an invaluable tool.
My minor nit is the following: when printing scores in treble clef, the top of the clef symbol is cut (see attached picture). I first thought it was caused by the measure number, but it also happens for the first line, where I have numbers disabled.
It happens with the default empty score that is loaded when musescore starts (attached as Untitled.mscz) and exported to PDF as Untitled.pdf. Depending on the PDF viewer software, it might be visible or not, but when printing it's always cut.
Any idea what might be causing that?
Attachment | Size |
---|---|
treble_top_cut.png | 230.03 KB |
Untitled.pdf | 11.45 KB |
Untitled.mscz | 6.44 KB |
Comments
I do not get the effect you see in treble top cut.png when I view your attached .pdf in Adobe Reader or when I print from your .mscz to my Epson ET 7750.
I note that MS version shown in score properties for Untitled.mscz is 3.3.4 and that the platform was Unix. I am using MS 3.4.1 and Windows 10. Perhaps an update to the latest MS version will rectify matters.
In reply to I do not get the effect you… by SteveBlower
Thanks for your response.
I tried upgrading my version on Linux to 3.4.1 but the problem persists.
The attached .mscz and .pdf files were generated on Linux. However, the pdf in the photo has been generated on Windows but printed from Linux. I don't know if it might be platform-related, but maybe it's printer-related.
I'll try a different printer tonight.
In reply to Thanks for your response. I… by LePouet
I confirm that the problem is not happening on the other printer i have access to.
So, it seems printer-related.
I have the same problem, even when printing to PDF (under Linux, too, with 3.4.2):
In reply to I have the same problem,… by paulwellnerbou
Can you attach the actual score? Also, which specific distribution & version of Linux? And are you using the AppImage or one of the various versions built by third parties? Those are often known not to work well.
In reply to Can you attach the actual… by Marc Sabatella
Good morning!
Yes sure! I am using the latest Ubuntu and the official 3.4.2 AppImage of Musescore.
Attached the score (happens with all scores).
Test_Score.mscz
In reply to Good morning! Yes sure! I am… by paulwellnerbou
You mention "printing" to PDF, I take it using a third party pseudo-PDF driver? Those also generally don't work well. What about just plain PDF export from File / Export?
In reply to You mention "printing" to… by Marc Sabatella
I tried both ways with the same result:
Attached the PDF as well, not sure if it helps.
In reply to I tried both ways with the… by paulwellnerbou
Just discovered that this PDF looks fine in Browser. So my findings:
So the issue is solved now for me, as I can work around using evince. Not sure if the actual cause is Musescore or a bug in evince.
In reply to Just discovered that this… by paulwellnerbou
From my previous experience, I think the problem is not in the PDF itself, but in the pinter/viewer used.
The same PDF file has given me different results on different printers and on different viewers.
So it might be a corner-case of the PDF spec, maybe a "bounding-box" specification that is inconsistently understood as "cropping-box" but not always. It could even be an issue with the font.
In reply to From my previous experience,… by LePouet
@LePouet, a few days ago I downloaded CUPS updates on Mint.
In reply to I tried both ways with the… by paulwellnerbou
There is no such thing as Musescore's print to file method
In reply to There is no such thing as… by Jojo-Schmitz
Sorry to be unprecise here, what I meant is:
This seems to be new, in the previous versions this just exported a PDF without being able to select the printer.
In reply to Sorry to be unprecise here,… by paulwellnerbou
Indeed, not provided by MuseScore. And not recommended either. Export to Pdf generally works better
In reply to Indeed, not provided by… by Jojo-Schmitz
I have the same problem.
Ubuntu 20.04
Musescore 3.2.3 (from the official Ubuntu repositories)
I used the Musescore PDF export functionality. It results in cut off treble clefs when I open the pdf with Ubuntu's document viewer.
When I transferred this PDF to an iPad it displayed the treble clefs without the cut off top.
When I transferred the PDF to another Ubuntu computer (with Ubuntu 16.04) and opened it there with document viewer -> cut off treble clef.
But then this:
I then transferred the mscz file in question to the other computer who runs still Ubuntu 16.04 and opened it there with Musescore 3.4.1 (Appimage) and exported it as PDF: No problems with the treble clef.
So, it seems to be a bug that is present in Musescore 3.2.3+dfsg1-4build1 from ubuntu-focal-universe but is not present in Appimage Musescore 3.4.1 running on Ubuntu 16.04.
It only occurs when using Ubuntu's document viewer (evince).
In reply to There is no such thing as… by Jojo-Schmitz
I have the same problem.
Ubuntu 20.04
Musescore 3.2.3 (from the official Ubuntu repositories)
I used the Musescore PDF export functionality. It results in cut off treble clefs when I open the pdf with Ubuntu's document viewer.
When I transferred this PDF to an iPad it displayed the treble clefs without the cut off top.
When I transferred the PDF to another Ubuntu computer (with Ubuntu 16.04) and opened it there with document viewer -> cut off treble clef.
But then this:
I then transferred the mscz file in question to the other computer who runs still Ubuntu 16.04 and opened it there with Musescore 3.4.1 (Appimage) and exported it as PDF: No problems with the treble clef.
So, it seems to be a bug that is present in Musescore 3.2.3+dfsg1-4build1 from ubuntu-focal-universe but is not present in Appimage Musescore 3.4.1 running on Ubuntu 16.04.
It only occurs when using Ubuntu's document viewer (evince).
In reply to I have the same problem… by sprock
Then I exported a PDF from this mscz file on the Ubuntu 20.04 computer with the latest Appimage 3.4.2 version: Bug is present.
then I even tried it with the Appimage 3.4.1 (which didn't produce the bug on Ubuntu 16.04) in Uuntu 20.04 and it showed this bug as well.
This is really annoying since I use Musescore also professionally. And I didn't plan on keeping the old Ubuntu 16.04 install on the older computer.
In reply to Then I exported PDF form… by sprock
It gets even more interesting: I transferred the bug-free PDFs from the 16.04 machine to the new 20.04 computer and opened it there: Treble clef is cut off.
In reply to It gets even more… by sprock
When I open the buggy PDF in Ubuntu 20.04 with Firefox browser instead of the default document viewer (Evince) the treble clefs look alright.
But still: Evince only shows this behaviour with MuseScore export PDFs that I made in Ubuntu 20.04. Older PDFs that I exported in Ubuntu 16.04 look correctly.
So I did some more detailed testing today.
I used two computers: One with Ubuntu 16.04, one with Ubuntu 20.04.
The 16.04-machine uses Musescore 2.3.2 (PPA) and 3.4.1 (Appimage) and as PDF viewer Evince 3.18.2
The 20.04-machine uses Musescore 3.2.3 (universe) and 3.4.1 (Appimage) and as PDF viewer Evince 3.36.7
I've made a chart (PDF attached below), but to make it short:
On the 16.04 machine every PDF version appears alright (=no bug) except for the PDF made with the official repositories Musecore version in 20.04 (Musescore 3.2.3)
On the 20.04 machine every PDF version showed the bug except for the Musescore 2.3.2 one which appeared without the bug.
I'll attach the chart t this post.
In reply to So I did some more detailed… by sprock
Thanks for the research!
So far my own assumptions are this:
1) the bug is actually in the specific PDF reader you are using, since all other PDF readers display the file normally, as do all printers
2) that said, there is probably something about the PDF file (perhaps something inherent to the font metrics) that triggers this bug for PDF's created on some systems but not others
3) to the extent it's possible to change something about how we generate PDF's to avoid the evince bug - without breaking things for other PDF viewers - we should certainly consider it
4) most details of PDF generation are handled for us by the Qt libraries we rely on, so most likely, any differences you see from system to system have to do with the specific version of Qt that MuseScore is seeing
5) the AppImage we provide is almost always the better choice for MuseScore than any version built by some unknown third party (e.g., whoever builds it for the repository you are installing from), in part because then we can control which version of Qt gets used
So the bottom line for me is, if evince has a bug that causes a problem when viewing PDF's generated by the official AppImage we provide and support, that's a problem we should try to find a good workaround for within our code.
If on the other hand the bug in your PDF reader is triggered only when using a third party build of MuseScore that relies on unverified versions of Qt libraries, it's going to be hard for us to support that.
From your analysis, it seems that the latter is indeed what we are facing - the evince bug is only triggered when using third party builds of MuseScore that rely on unknown versions of Qt.
Meaning, I think, that bottom line for users is, either use a different PDF reader, or use the AppImage.
In reply to Thanks for the research! So… by Marc Sabatella
Hello Marc,
thanks for your response.
You wrote (by the way: is there a quotation functionality in this forum software?):
........................................................................................................................................................
"So the bottom line for me is, if evince has a bug that causes a problem when viewing PDF's generated by the official AppImage we provide and support, that's a problem we should try to find a good workaround for within our code.
[...]
From your analysis, it seems that the latter is indeed what we are facing - the evince bug is only triggered when using third party builds of MuseScore that rely on unknown versions of Qt.
Meaning, I think, that bottom line for users is, either use a different PDF reader, or use the AppImage."
........................................................................................................................................................
Unfortunately – if you look at my chart – even the Appimages of Musescore 3 show this bug in Ubuntu 20.04 which is the recent long term support version of Ubuntu.
The Appimage-generated PDFs only showed correctly in Ubuntu 16.04 which is quite old (and I won't use in the future anymore). 20.04 is the distribution to concentrate on since it's the recent LTS Ubuntu that will be around for the next 5 years.
Evince comes as the preinstalled document viewer in Ubuntu and is the default application to open PDFs. It would be good if it displayed Musescore generated PDFs correctly as it always did in the past.
(I know we Linux users are just a small minority but I would definitely be very thankful if this bug could be fixed on the Musescore side.)
In reply to Hello Marc, thanks for your… by sprock
Ah, you're right, I misread.
So, in order to figure out how to workaround the problem, we would need to understand more exactly what evince is doing differently. Have you tried reporting the problem to them? First, maybe they'll just fix it to work like everyone else. but at least, they should be able to provide advice on how to produce PDF's that they won't choke on.
As a workaround, i have found that if you pass the pdf through ghostscript, evince then displays it just fine:
gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -sOutputFile="out.pdf" "input.pdf"
In reply to As a workaround, i have… by pbrenna
Wow, indeed. (It's quite cumbersome, though, for everyday use.)
By the way: The pdf file I just tried it on got reduced in size by this. The original (generated by MS 3.5.0 AppImage) is 41.4kb, the ghostscript processed one is only 27.6kb. Do you know what information is stripped from the file that causes this reduction?
In reply to Wow, indeed. (It's quite… by sprock
I also get a 75% smaller file. It looks like pdf version 1.7 might achieve better compression than version 1.4 as exported by mscore (but this is speculation).
In reply to I also get a 75% smaller… by pbrenna
Yes, 1.5+ compress more. But 1.4 is better for compatibility.
Hmm, and what if this is a bug in evince, and the method the users used to print is to open the PDF in evince and print from there (as opposed to print directly via CUPS using the
lp
command-line tool)?Also, feeling pretty slighted wrt. the official packages and Marc’s comment…
In reply to Yes, 1.5+ compress more. But… by mirabilos
You definitely have more insight into building MuseScore than most, so any comments on the reliability of repository builds were certainly not directed at you. And yet, presumably you also have the perspective to realize that the track record of official packages overall for the past several years has not been good. Many do include incorrect dependencies or bad build flags that produce versions that do not work correctly. And many are out of date and thus missing crucial bug fixes. So I really feel it is prudent to always recommend the AppImage over any repository build. Even on debian, which is indeed one of the better ones - but is still over a year out of date, and thus missing probably around a thousand or so bug fixes.
In reply to Yes, 1.5+ compress more. But… by mirabilos
Of course, it might be a bug in Evince.
I've given a bug report on GitLab already, no reaction so far:
https://gitlab.gnome.org/GNOME/evince/-/issues/1484
(Maybe someone from here who is able to help wants to chime in there)
By the way:
"PDF Arranger" on Ubuntu 20.04 shows the same bug!
So it seems to use the same backend as Evince, I guess? Maybe that's a trace?
(I've tried "qpdf" as well: It doesn't show the bug, treble clef is correctly displayed. But I much prefer Evince over qpdf as a PDF viewer; and it is the Ubuntu default, so it should better work.)
In reply to Of course, it might be a bug… by sprock
I've had this problem over the years (2.3.2 and before didn't have the issue, but branching off into 3.0 did. It seems that something went "wrong" when they converted Emmentaler to SMuFL). Still exists in 4.2.1 and 3.6.2. It only occurs with Emmentaler, and now that the default font is Leland with more font options like Bravura, it is likely not to affect many people. Of those who choose Emmentaler it still would affect only those using these linux default PDF viewers, so far as I'm aware. Adobe document viewers, and modern browsers don't seem to manifest the problem
The default PDF viewers for some distributions manifest this. For example:
XReader:
Evince:
Manifestation of "headless" problem:
In passing...
Screen capture of exporting from MuseScore 4.2.1 using Emmentaler:
I doubt most would find this interesting, but I think I figured out how to fix the issue.... I went through MuseJazz because that damned treble clef is huge and yet has no problems... and after a while saw the font metrics in FontForge, mimiked them in the "0S/2" tab and seem to be getting good export results now...
These are the values I tested:
Edit: Pretty sure it's the typo ascent and descent changed to +/- 2012 that fixes it. I think it might be worth a pull request in 4.x and even the "3.7 Evolution" for testing. Again, I doubt many would care about this, but I like simple PDF viewers and I like Emmentaler occasionally, and would prefer it to be fixed. Maybe this will find interest with someone out there! Wish I had've taken a look at this back in 2018 or so, but alas. . .
In reply to I've had this problem over… by worldwideweary
P.S. Ever so slightly interesting post about why this is called OS/2 even though it's not a Mac only thing:
https://typedrawers.com/discussion/501/can-someone-explain-the-origin-o…
In reply to I've had this problem over… by worldwideweary
Yes, please PR it for Mu3.7
In reply to Yes, please PR it for Mu3.7 by Jojo-Schmitz
Ok: https://github.com/Jojo-Schmitz/MuseScore/pull/417
In reply to Ok: https://github.com/Jojo… by worldwideweary
And merged
In reply to I've had this problem over… by worldwideweary
OK, with that information I was able to reproduce it in PDFs generated by the 2.3 and 3.2 in the Debian/Ubuntu repositories, so it does not have to do with the SMuFL conversion. Having to install evince was the bit I had been missing so far.
I’ll look at the OS/2 table in a bit, though I won’t just copy insanely high values from a totally unrelated font.
In reply to OK, with that information I… by mirabilos
Interesting - Jojo mentioned he wasn't able to manifest the problem in a Windows version of evince or using a newer evince in Arch (Evince 46.0, Arch Linux) as opposed to what I've got here @ 42.3. Only occurs in MS 3.0.0 and onward (can't manifest the problem here in official 2.3.2 app image or before)
No need to attempt copying my testing phase of unrelated values, but you could try what I mentioned earlier in the PR (link above): Check the screen captures between Emmentaler 2.3.2 Metrics and 3.0/3.6.2 Metrics. Reverting back to the 2.3.2 options fixed it for me (x height and disabling "Really use typo metrics"
Hell, I'll just copy the capture here:
In reply to Interesting - Jojo said he… by worldwideweary
Another copy over: The Typo Ascent + Descent add up as you'll see to the em of 1024, yet the treble clef exceeds this by a long shot
In reply to Interesting - Jojo said he… by worldwideweary
hmmhmm, https://fontforge.org/docs/faq.html#faq-linespace documents-ish that field, but only for the Windows case.
I’ll investigate whether it’s best to just fix the clipping region instead.
In reply to OK, with that information I… by mirabilos
I can also confirm that the late 2.3 changes to MScore have touched neither the gClef glyph nor the metrics metadata, so the bug was pre-existing.
In reply to I can also confirm that the… by mirabilos
Using the official repositories to get [mscore.ttf] is when I get the problem only on 3.0 and afterwards. It's not about the GClef being touched but the OS/2 metrics within the ttf itself for me:
Fontforge metrics of 2.0 ttf and 2.3.2 show:
3.0 shows:
There's clearly a change in 3.0 not in the 2.x branches related to the metrics in the ttf file, namely the x-height is 0 in 3.0 and the "really use Typo metrics" is enabled in 3.0
Changing it back to how it was in official 2.3.2 repository (above s-shot) resolves the issue for me on my system running evince and also xreader.
P.S. Thanks for the faq link. Interesting that they threw in "...and luck" for what it's contingent upon :)
In reply to Didn't exist for me. Only 3… by worldwideweary
Hmmhmmhmm. All kinds of pages suggest that “Really use typo metrics” needs to be enabled for all fonts. But then, changing the metrics now is a big no-no as well. https://silnrsi.github.io/FDBP/en-US/Line_Metrics.html is another useful read.
I’ll investigate. I’ve got a few ideas, also for quicker tests, and anyway we’ll want the versions to match, good as.
(Investigating includes looking at what contemporary Emmentaler does, and seeing if that’s appropriate for MScore, which is mistakenly called Emmentaler by many mu͒ devs.)
(And it very well may be that unchecking that box is the correct thing to do, but I’d like to do it as informed decision…)
In reply to Hmmhmmhmm. All kinds of… by mirabilos
Hrm. For what it's worth, the irony here is that every single font packaged in MuseScore 3.6.2 doesn't have "Really use typo metrics" enabled except for Emmentaler, the one that has this problem!
In reply to Hrm. For what it's worth,… by worldwideweary
Interesting.
I also want to check the git history for when and how this change was introduced. I recall there being some “display on Mac” fixes, too…
Meanwhile (despite really needing to go to bed…) I found another thing: Evince also cuts off the top of my copyright line in some scores, which is an Inconsolata variant.
So this is going to lead to quite a bit of debugging.
In reply to Interesting. I also want to… by mirabilos
Weird. It's kind of difficult to check git history for a binary file... and what also makes it difficult was that 3.0 branched off from 2.x like 2 years prior to finalizing version 2: 2.3.2 finished around like July 2018 but 3.0 branched off back in 2016 ... and I tested building 3.0 as far back as I could (couldnt' go further because it was using the QWebKit from 5.4 or below and I didn't have access to it anymore) but however far back i made it... i still got the headless result, point is that it seemed to be introduced in the early branching off times... somewhere between like mid 2016 to early 2017 would be my quick guess. If it's of any assistance, here's an image:
In reply to Weird. It's kind of… by worldwideweary
and here's another where the SMuFL conversion took place:
Update: for what it's worth, the initial SMuFL conversion I checked, if I checked correctly, did NOT have the checkbox for "really using" enabled... so it would've been after that(after 2015). This probably all looks like "Much ado about nothing"
In reply to Hrm. For what it's worth,… by worldwideweary
in 2.3.2(!), the following fonts have that checkbox enabled in the shipped sources:
If someone committed binaries without corresponding source, I cannot be held responsible for my actions… 😹
In reply to in 2.3.2(!), the following… by mirabilos
in fact, I guess I’ll have to regenerate every font file (that’s not verifyable externally like FreeFont) and diff the TTF dumps, or something… 🤬
In reply to in fact, I guess I’ll have… by mirabilos
I did some research and found the culprit PR, if I didn't screw up in the process in opening the files (it's always possible).
Edit:
This @ Jul 2015: update mscore font to use SMuFL glyph order still had the checkbox disabled in the font itself (ttf) as the last one.
In other words, the next PR that touched mscore.ttf switched the previously mentioned attributes, and that was Oct. 2015:
This PR didn't update any sources. . . so either the sources already had the check some how or it was added later, it would seem. Don't know if this helps or not. For now my temporary personal fix and one i PRed for "3.7" was just a change in the TTF file to be like previously mentioned.
In reply to I did some research and… by worldwideweary
I’m
git log
ging and diffing around a bit as well and additionally am diffing between the shipped sources and.ttf
(and in the 2.x case.otf
) files as well.(The post-3.2 vpezerev changes are underdocumented and highly suspect, too, btw…)
From that, I tentatively agree that the bit should be unchecked in all our fonts, and fsType should also be set (it seems to become automatically set to 0 if the
.sfd
file is loaded by a newer FontForge if the file did not contain the value prior, older versions seemed to default to 8).I’ll investigate more and deal with the Debian/Ubuntu packages myself. Jojo, I assume you’ll want a PR against 3.7 based on the
.sfd
files you currently have in your 3.7 tree at the end, correct?In reply to I’m git logging and diffing… by mirabilos
Yes, please
In reply to I’m git logging and diffing… by mirabilos
Just from regenerating from the sources, I see that kerning info was never shipped, too…
Oh well.
In reply to I did some research and… by worldwideweary
The switch in the sources was here btw:
I’ve no idea how people will have kept this out of the
.ttf
files in the intervening releases, though… I suspect shenanigans and/or a bug in the recommended 2012 version of FontForge from the docs that state the 2014 version to be “buggy somehow”.In reply to The switch in the sources… by mirabilos
To be fair, it does seem quite easy to just alter the font in FontForge and press "Generate Font", not messing with the sources... but who knows.
In reply to To be fair, it does seem… by worldwideweary
yes, too easy ☹
I spent my spoons for today though, I’ll continue looking at this and preparing a set of patches tomorrow. First I’ll look through the ttx diff (between “regenerated from source” and shipped TTF/OTF) a bit more for each font though, I also found at least one more area of improvement.
In reply to yes, too easy ☹ I spent my… by mirabilos
More added fun:
> Recent bug reports have revealed present and historical problems with FontForge’s handling of underline position. The next release will fix the software problem, but users may need to fix their existing files.
source