[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

• Apr 29, 2024 - 03:51

It gets curiouser and curiouser. (Sorry for only getting back to this today, I had… issues and then to catch up.)

I did find that the fixed-width font I use for hyperlinks and copyrights in my scores has the same issue, reproducibly.

However, nothing I did to the metrics fixed it (it’s easier to swap the font, restart Mu͒seScore, export as PDF, check, than to swap MScore). Use type metrics or not. I even recalculated the metrics according to these recommendations and slightly increased them, which led to an ever so slight decrease of the box I let Mu͒seScore draw around the text!

I’m convinced that there’s a bug in Mu͒seScore and/or Qt5 somewhere regarding font metrics which the workaround of toggling that bit only hid for the MScore font and only by accident, so it could come back any time.

(There may also be a bug in atril and the other softwares you listed and possibly either my gf’s printer or the PDF to printer-language conversion thingy that’s part of the printer driver.)

I’ve asked the atril developers to have a look at the PDF to try and help tracking this down from the PDF and font rendering side in and will try to dig through the CFrustFrust rendering code in libmscore at a maybe more sane time of day next… (in addition to all those changes to fix underscore positions and bring back other improvements from the .ttf files (I already checked the .otf files that mu͒2 still had but they bring nothing new) to the .sfd files (which have other improvements such as several new glyphs that are not present in the shipped .ttf files, gah!) and regenerating them… later, when we have fixed the root cause.)

Test PDF attached (in a PKZIP container), in case people (with ISO A4 paper) want to print out page 2 and check their printers for the same issue…

Attachment Size
dd.zip 133.91 KB

Reply

• May 5, 2024 - 03:16

It’s a Qt bug. Rejoice, for who would’ve thought!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070406

OK, so, since chances that the bug gets fixed are… only an epsilon interval higher than chances of mu͒2 bugs getting fixed these days… I’ll probably have to figure out the bug myself, then hack the fonts and/or the Mu͒seScore Studio/Evolution softwares to work around it. Yay for more deep digging…

Reply

• May 5, 2024 - 14:55

Thanks! (It’s a variant of a variant of Inconsolata, and I’ll develop it further to fix a few annoying points when I have the time, incidentally because I put so much time into things around fonts for Mu͒seScore.)

It’s both MScore and this one (and possibly others), and I have no idea currently what it could be, the Qt code as far as I can see looks okay-ish. I wonder if someone can make something out of the PDF result or else I’ll have to go at it with the PDF spec and a lot of time trying to figure out where in the PDF it is wrong, hand-editing the PDF to test a fix, then going back from the PDF to the CFrustFrust source code generating it, to see where it comes from…

Worse then, because chances of getting this fixed in Qt are realistically nil, to figure out a workaround we can apply to Mu͒seScore… and/or the fonts…

Reply

• May 5, 2024 - 20:49

More debugging in this thread; turns out that Qt5, when embedding fonts, scales them to 2048 ppem (no matter what they were before), but only in the head, not in the OS/2 table, and the PDF /FontBBox is also constructed based on the original fonts.

Related, Qt cannot embed OTF/CFF fonts so it converts them to TTF anyway.

I have been toying with the idea of making Mu͒seScore Studio optionally not embed the fonts into the PDF. This is useful when generating multiple PDFs for multiple scores then combining them together into a songbook. For this, I would have to rename the fonts’ internal names so that you could distinguish v2, v3 and Evolution scores; then, you could install the MScore font system-wide (and the others as well, I suppose), combine the PDFs and then embed the subset fonts into the final PDF. This would be one possible workaround.

@Jojo-Schmitz: would you be interested in having that as an option in Evolution? I think I’ll add it to the 2.3.2/3.2.3 in Debian nevertheless.

The next one is to document that Qt applications only work with 2048 ppem fonts, and to convert all the internal ones to that. (This involves quite some amount of post-conversion tweaking in FontForge so the outlines are optimal, the control points on integer positions, etc. but I’ve done most of that for MScore once already (commit 2b3dbc9eb350761eae5615edf814be8dba05dfb0) and can do so again.) Gentium Plus, and other modern fonts, are 2048 ppem already, but most older TrueType fonts are 1024 ppem, and PostScript/CFF fonts have to be 1000 ppem (or they don’t work right, while TTF fonts need to be power-of-two or the antialiasing breaks). This means that people cannot use just any font in their scores and expect the PDF to look right.

And, of course, then there’s digging into Qt5 yet further to see whether we can fix this (disable the scaling or let it get it right).

(Other things I’m considering for Debian, and if Jojo wants them also for Evolution, is to run ttfautohint on the TTFs for better antialiasing, and (unrelated, but I found this while debugging) to fix up the superscript and subscript to be just a tad less small and slightly closer to the baseline.)

Reply

• May 5, 2024 - 21:08

ouch, this means I’ll have to bother doing it for master as well and then hoping they’ll even accept it… wish I could ask ahead of time whether they would take it, to save time, but with the russian-cypriot-USA takeover and personnell changes I have no idea whom to even ask (and .com does not work at all for me any more either sigh…)

Reply

• May 5, 2024 - 21:05

not sure if there’s all that much interest; I keep applying some of the patches I do to 2.4 as well, or develop for 2.4 first and forward-port then (instead of backporting from master like you do), but since about 2023Q1 I no longer consider it for anything but rendering and tweaking old scores

Reply

• May 6, 2024 - 16:00

One of the Debian Qt maintainers found it’s been in Qt4 since the beginning of the FOSS repo, at the very least.

I’ve got a preliminary patch for Qt5 that fixes two of three problems (the PDF bounding box and the hhea table but not the OS/2 table yet, this will need more work).

However.

Jojo, you build Evolution for multiple OSes with multiple different Qt versions of different age, IIUC. Are you in the position of (re‑)building the Qt versions you use yourself in order to apply such a bugfix patch to the Qt libs and then use the rebuilt/fixed ones when bundling?

Otherwise, unless I figure out a way to subclass and “monkey-patch” Qt’s routines from within mscore itself (which is going to be tricky as hell and probably heavily dependent on the Qt version in use) or postprocess somehow (which I’m even less sure of), the not embedding would be the only way to fix this for fonts in general. (I’ll still provide a PR with the MScore and other fonts shipped converted to 2048 ppem (which will involve quite a bit of tedious cleanup work afterwards, for it to meet the spec) and other bugs like the underscore position and some metadata fixed, of course, but that doesn’t fix, say, Inconsolata.)

Reply

• Jul 1, 2024 - 21:00

Not important, but for fun ... came across this in an older pdf.
Checked details and found it to be a Sibelius export... suffers from the same freakin' problem (apparently they too use Qt like Dorico?).

loppedOff.png

Edit: And yet an older Sibelius export that shows it used Qt 4.8 and the head was not cut-off...

4.8withhead.png

Reply

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