[minor] Top of treble clef cut when printing

• Feb 4, 2020 - 10:38

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

• Feb 4, 2020 - 10:53

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.

Reply

• Feb 4, 2020 - 11:52

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.

Reply

• May 3, 2020 - 09:31

Just discovered that this PDF looks fine in Browser. So my findings:

  • Print to real printer directly from Musescore works fine
  • Print/Export to PDF from Musescore produces a PDF, which looks fine in Browser (Chrome in this case, did not check other Software yet), but shows cut clefs opened in Ubuntu's standard PDF viewer (evince)
  • Printing this file from PDF Viewer results in cut clefs on paper, too.

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.

Reply

• May 3, 2020 - 10:20

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.

Reply

• Jul 31, 2020 - 19:20

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).

Reply

• Jul 31, 2020 - 19:23

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).

Reply

• Jul 31, 2020 - 19:40

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.

Reply

• Jul 31, 2020 - 20:24

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.

Reply

• Aug 1, 2020 - 17:16

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.

Attachment Size
MuseScore-PDF-Bug-Chart+.pdf 18.43 KB

Reply

• Aug 1, 2020 - 17:48

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.

Reply

• Aug 2, 2020 - 11:49

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.)

Reply

• Aug 2, 2020 - 17:21

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.

Reply

• Sep 2, 2020 - 20:20

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"

Reply

• Sep 2, 2020 - 21:24

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?

Reply

• Sep 2, 2020 - 22:48

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…

Reply

• Sep 2, 2020 - 23:22

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.

Reply

• Sep 3, 2020 - 07:35

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.)

Reply

• Apr 13, 2024 - 23:54

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:
Xreader4.0.2.png

Evince:
Evince4.2.3.png

Manifestation of "headless" problem:
headless.png

In passing...
barrettwtf.png

Screen capture of exporting from MuseScore 4.2.1 using Emmentaler:

exporting.gif

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:

metrics.png

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. . .

Reply

• Apr 15, 2024 - 12:18

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.

Reply

• Apr 15, 2024 - 17:36

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:
b4b1f2b1aca3.png

Reply

• Apr 15, 2024 - 21:25

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:
2.3.2metrics.png

3.0 shows:
3.0metrics.png

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 :)

Reply

• Apr 15, 2024 - 22:23

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…)

Reply

• Apr 15, 2024 - 22:41

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.

Untitled.png

So this is going to lead to quite a bit of debugging.

Reply

• Apr 15, 2024 - 22:48

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:

githistory.png

Reply

• Apr 15, 2024 - 22:50

and here's another where the SMuFL conversion took place:

2git.png

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"

Reply

• Apr 15, 2024 - 23:10

in 2.3.2(!), the following fonts have that checkbox enabled in the shipped sources:

fonts/MuseJazz.sfd:OS2_UseTypoMetrics: 1
fonts/mscore-BC.sfd:OS2_UseTypoMetrics: 1
fonts/mscore/MScoreText.sfd:OS2_UseTypoMetrics: 1
fonts/mscore/mscore.sfd:OS2_UseTypoMetrics: 1
fonts/mscore_tab.sfd:OS2_UseTypoMetrics: 1

If someone committed binaries without corresponding source, I cannot be held responsible for my actions… 😹

Reply

• Apr 16, 2024 - 00:01

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:
lastok.png
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:
culprit.png

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.

Reply

• Apr 16, 2024 - 18:08

I’m git logging 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?

Reply

• Apr 16, 2024 - 18:13

The switch in the sources was here btw:

commit b62061eec85e0e265ccc38d4d98f656c3bfefeb9
Author: John Pirie 
Date:   Wed Jun 18 09:49:01 2014 +0100

    Support for the fade articulation in fonts, and import in GP4 and GP5 formats

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”.

Reply

• Apr 16, 2024 - 20:05

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.

Reply

Do you still have an unanswered question? Please log in first to post your question.