[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

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 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 by paulwellnerbou

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.

In reply to 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 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 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 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 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.

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

In reply to 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 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 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 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 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 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 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.)

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