fix #296190: Campania not rendering correctly on some macOS systems #5426
Conversation
|
If Campania has sources ( |
MarcSabatella
added
the
work in progress
|
I have verified this works on macOS, but based on testing and discussion on Telegram, the consensus it will be best to regenerate the font again with the "Old-style kern" option enabled. So I will do this and update the PR. |
|
And yes, https://github.com/MarcSabatella/Campania is the official source for the font. I want the font to be available outside of MuseScore, and I want people not associated with the MuseScore project (and who have thus not signed the CLA) to be able to contribute to it. I also prefer not to have the source duplicated if at all possible - that is just asking for trouble with things getting out of sync. I'm open to other arrangements but this was the consensus when I first embarked on this project several months ago. |
The version of Campania we just updated to (2.008) works fine on Windows but apparently fails on macOS, at least on some systems in some cases. The version of Campania incldued here is still built from the same basic sources, but it turns off the "Apple" option within FontForge and turns on "Old-style kern". This appears to fix the problem.
MarcSabatella
force-pushed
the
campania-mac
branch
from
793388a
to
809a68f
Compare
MarcSabatella
removed
the
work in progress
|
Updated, font version 2.009, still same source (changed name of a glyph to eliminate a warning) but with Apple disabled, Old-style kern enabled. The consensus is, this is the right way to do it. Will still be good for someone to test an actual release build with this - ideally, we'd merge to master and check the nightlies on each OS before merging to 3.3 |
|
On Mon, 28 Oct 2019, Marc Sabatella wrote:
And yes, https://github.com/MarcSabatella/Campania is the official
source for the font.
OK.
I also prefer not to have the source duplicated if at all possible -
I will, however, need to have the source in Debian if the source
exists. For this, I have the following two scenarios:
• install Campania system-wide and not bundle it in the musescore
executable, allowing independent updates
• bundle Campania from your github as “second source tarball”
In both cases, you should do releases of Campania, so that the
git tree is tagged with the version number.
I’d prefer the former *because* you want people to use it outside
of MuseScore. It causes no small amount of trouble if the application
bundles a different version of the font from what is installed
system-wide. But what do you think?
|
|
What does it mean to "do releases of Campania"? I guess you mean the release tagging facility on GitHub itself? I see a "Create new release" button, I suppose that would be my starting point? As for the question of installing the font system-wide versus bundling it, from what I understand it's a damned-if-you-do-damned-if-you-don't situation. In the past people have managed to shoot themselves in the foot on Linux by getting their mscore fonts out of sync with their MuseScore releases, which is bad. Also when people have a version of FreeSerif that doesn't support whatever it is we've added to it, which I think has happened too. So it's no small amount of trouble if the application doesn't get some control over the version of a font it uses, at least for fonts where the application itself relies on particular font features. But it's also bad when you can't just install an updated version of a font to use it with MuseScore, and right now this seems to be the case on Windows. Anyhow, I don't know the technical or legal tradeoffs, so if you're happy with the problems that result from not bundling the font, that's fine with me. I just need to know what "do releases" means. Oh, and feel free to tell me what you meant elsewhere about copyright and italics.. |
|
Marc Sabatella dixit:
What does it mean to "do releases of Campania"? I guess you mean the
release tagging facility on GitHub itself? I see a "Create new release"
button, I suppose that would be my starting point?
I guess, I don’t work with github personally, but at least 'git tag v2.009'
and 'git push --tags'.
As for the question of installing the font system-wide versus bundling
it, from what I understand it's a damned-if-you-do-damned-if-you-don't
Yes, it is.
situation. In the past people have managed to shoot themselves in the
foot on Linux by getting their mscore fonts out of sync with their
MuseScore releases, which is bad.
That’s why application-specific fonts should not be installed system-wide.
Also when people have a version of FreeSerif that doesn't support
whatever it is we've added to it, which I think has happened too.
I just looked, MuseScore ships original, unpatched 20120503 version
(which is the latest) of GNU freefont.
But, funnily enough, the reverse happened: in 2018, a Debian patch
to fix rendering of some glyphs was added.
So it's no small amount of trouble if the application doesn't get some
control over the version of a font it uses, at least for fonts where
the application itself relies on particular font features. But it's
I guess this is only possible to do if the fonts embedded into the
application are *ALWAYS* renamed from their external versions.
also bad when you can't just install an updated version of a font to
use it with MuseScore, and right now this seems to be the case on
Windows.
When two versions are present, I don’t even know how the correct one
is chosen. I guess it’s ordering-dependent or even random whether the
(older?) version from the application or the external one is chosen.
On Unix and Windows 10, it gets worse, because users can install fonts
into their home directories / user accounts as well, so then you have
THREE copies around.
I solve this in the script I use to convert .mscx to .pdf by creating
a temporary directory which contains only the fonts I allow into the
score PDFs (with licence review), then set the fontconfig configuration
to consider only that directory. It was tricky, and very hard to get
right, and is probably a Unix-only solution, probably not on MacOSX and
definitely not on Windows.
If I were asked to resolve this, I’d recommend to users to never install
the MuseScore fonts system-wide and rename the embedded fonts (that have
use outside of MuseScore, so Campania… Bravura is going to be tricky…
freefont maybe, but given its last release was in 2012 it’s not all that
big a problem except if you need more-than-consistent rendering). But
then font names are a problem.
Also, as a user, if my operating system fixes rendering of ď in FreeSans,
and it is fixed everywhere except in MuseScore, I’d be surprised.
I guess “damned if you do, damned if you don’t” is the right thing to say…
because if you fix it so it’s right on the user’s computer, it’s going to
be wrong on musescore.com… which, given its smallish amount of available
fonts, is probably the lesser evil.
Which fonts does “at least for fonts where the application itself relies
on particular font features” apply to? I get this is the musical fonts,
i.e. mscore (but not MScoreText), mscoreTab, mscore-BC, Bravura (but not
BravuraText), Gootville (but not GootvilleText), MuseJazz (but not
MuseJazzText), right?
As I understand it, at least Bravura is used with that name by other
programs. If that other program installs the font system-wide on Windows
(which is something e.g. MS Office also does, so it’s possible) then
MuseScore will have “shit, out of luck”. So, rename and map between the
old and new name (like Gonville/Gootville and Emmentaler/MScore)?
As for the other fonts, I’m leaning towards not embedding them but
depending on their presence. That is, Free*, but perhaps others. On
Unix, this is easy; I have no idea how fonts work on Mac OSX, but on
Windows, it’d probably be best to install them system-wide… except
this doesn’t work with portable apps. On Windows it used to be that,
when you have a font preview window open, it can be used by other
applications during that time, but this is no longer possible with
the latest versions either, so… damned if you do, damned if you don’t.
Perhaps there is no one-size-fits-all solution.
Let’s look at Campania now. You explicitly desire it can be used
outside of MuseScore. It’s (as far as I can tell) not a font where
MuseScore depends on its internals, or even its presence. So, on
Unix, perhaps packaging it separately would be good.
Otherwise, renaming the bundled-with-MuseScore version, so that
when you have two installed, they differ in name. This would allow
users to use either in scores though, and when they then upload
to musescore.com which would have only the bundled one…
… I guess it’s an extremely complicated set of weighed decisions.
Anyhow, I don't know the technical or legal tradeoffs, so if you're
happy with the problems that result from *not* bundling the font,
that's fine with me. I just need to know what "do releases" means.
I’m happy with not bundling the font (and can do that as a Debian-
local patch if needed) as long as this doesn’t introduce any bugs.
The musical fonts have version-specific data in metadata.json, so
they basically must be bundled, and the version has to match. As
long as a font isn’t like that it can be not bundled.
----
Oh, and feel free to tell me what you meant elsewhere about copyright
and italics..
I’d have to check the current state of your repo. I worked from the
OTF font in the musescore repo and fontforge showed me weird strings.
Basically, you had more than one “copyright” string, where only one
was expected or could work, and the other strings were something about
italics in multiple languages. Let’s discuss this elsewhere once I
have more info (and time).
|
|
Thanks for the info! Here's what I take from all that:
|
|
Marc Sabatella dixit:
- I get that you need to distribute the source for any binaries, and
that ideally there would be an automated way to generate the binary
Yeah, but I’m trying to skip on the “ideally” for now; fontconfig is
notoriously hard to script.
clear on which settings in the GUI "0x800" corresponds to, just that
“old-style kern” (all other settings we use are 0-bits in that
function) and I will update the PR to explain this.
- Packaging-wise, it sounds like we should do this like FreeSerif etc -
don't compile in but instead install system-wide, for Debian anyhow,
Interestingly enough, I’ve not yet separated out FreeSerif et al. even
in Debian yet. I probably should.
macOS has its own system so does Windows, and while someday we could
revisit those I see no reason for this to be that day or for me to be
True. Installing the fonts system-wide would be useful, but I don’t
know about the Macintosh, nor how/if it would work with portable apps…
- I need to make a "release" on GitHub so you can reliably grab from
there. I'm on that, will let you know when I think I have something.
It works and I’ve uploaded Campania to Debian now, pending ftpmaster
review.
- To be honest, I'm not totally up on how the split between MsueJazz
and MuseJazz Text is managed, but chord symbols in the "Jazz" style
(as per Format / Style / Chord Symbols) do rely on the specifics of
what used to be MuseJazz and is now MuseJazz Text in that it won't
Oh… but…
look at all reaosnable with any other font. Not so much because of
… yeah, but that’s the user’s fault then.
actual "code" (although there may be some small dependencies) but
because of chords_jazz.xml.
That lists codepoints and render strings, but not things like precise
widths of individual characters and anchor points for putting them to‐
gether, so I assume it would work equally well with any later version
of the same font (as long as the font designer takes care to retain
backwards compatibility… a given, since old scores are invalidated as
well, I think).
My point here is more about the system-wide font being updated relative
to the one (normally?) embedded into the application.
- I see the error from FontForge about copyright strings if I open the
OTF file. I blame FontForge itself, because I don't see those errors
when I open the SFD. The copyright strings in the SFD look perfectly
normal to me, no idea how FontForge screwed that up when writing or
reading the OTF.
Writing, they are present in the OTF (the ttx program from fonttools is
useful in inspecting them). Eh, another fontforge mystery that can be
solved another day…
Thanks for the quick responses and working together to get at least
the most important issues solved, and in the sense of the users at that.
|
fix #296190: Campania not rendering correctly on some macOS systems
Resolves: https://musescore.org/en/node/296190
The version of Campania we just updated to (2.008) works fine on Windows
but apparently fails on macOS, at least on some systems in some cases.
The version of Campania incldued here is still built from the same 2.008 sources,
but it turns off the "Apple" option within FontForge.
This causes tables to be written in Adobe format,
which appears to fix the problem.
If this cannot be verified to work, and I don't figure anything else out quickly enough, I will submit a new PR reverting Campania to the same binary as used in RC2. The code changes in #5390 should still be good to keep.