Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cantarell glyphs with mark-to-mark anchor are made zero-width #228

Closed
madig opened this issue Feb 21, 2016 · 9 comments
Closed

Cantarell glyphs with mark-to-mark anchor are made zero-width #228

madig opened this issue Feb 21, 2016 · 9 comments

Comments

@madig
Copy link
Contributor

madig commented Feb 21, 2016

A few users on 1.2.0 reported that Cantarell (https://git.gnome.org/browse/cantarell-fonts/tree/otf) is broken, glyphs that have a mkmk anchor like 'Ü', 'ü' and /aring are made zero-width. I saw #211 and tried to order mkmk after mark, but that didn't help... what do I have to do?
@madig madig changed the title Glyphs with mark-to-mark attachment are made zero-width Glyphs with mark-to-mark anchor are made zero-width Feb 21, 2016
@madig madig changed the title Glyphs with mark-to-mark anchor are made zero-width Cantarell glyphs with mark-to-mark anchor are made zero-width Feb 21, 2016
@behdad
Copy link
Member

behdad commented Feb 21, 2016

I got this report as well but have not got to look into it yet. The change we made was to zero mark advances by GDEF rather than Unicode properties. So, if those glyphs have GDEF glyph class 3, then it's definitely a font bug.

@behdad
Copy link
Member

behdad commented Feb 21, 2016

Just checked. Definitely faulty Cantarell.
https://bugs.freedesktop.org/show_bug.cgi?id=94228
What versions of the font are affected?

cc @davelab6

@behdad
Copy link
Member

behdad commented Feb 21, 2016

Upstreamed: https://bugzilla.gnome.org/enter_bug.cgi?product=cantarell-fonts

@behdad behdad closed this as completed Feb 21, 2016
@madig
Copy link
Contributor Author

madig commented Feb 21, 2016

Okay, I think I found the problem. FontForge tries to determine the glyph class automatically by default, and I copied some mark-to-mark base anchors to glyphs like 'Ü' because FF isn't clever enough to search base glyphs/marks for anchors when using the compose-glyph-function. My intent was that e.g. 'Ǖ' can be composed from 'Ü' and macron with correct diacritics placement. Apparently that makes FF think 'Ü' is a mark.

Should mkmk anchors only ever be used on marks? Fira Sans and Source Sans Pro don't seem to put any mkmk anchors on non-marks. But then how would a shaping engine compose 'Ǖ' from 'Ü' and macron? Or from dieresis and macron?

@jfkthame
Copy link
Collaborator

On 21/2/16 16:07, Nikolaus Waxweiler wrote:

Okay, I think I found the problem. FontForge tries to determine the
glyph class automatically by default, and I copied some mark-to-mark
base anchors to glyphs like 'Ü' because FF isn't clever enough to search
base glyphs/marks for anchors when using the compose-glyph-function. My
intent was that e.g. 'Ǖ' can be composed from 'Ü' and macron with
correct diacritics placement. Apparently that makes FF think 'Ü' is a mark.

Should mkmk anchors /only ever/ be used on marks? Fira Sans and Source
Sans Pro don't seem to put any mkmk anchors on non-marks. But then how
would a shaping engine compose 'Ǖ' from 'Ü' and macron?

Where Ü is a single (precomposed) glyph, placing macron over it would be
a job for 'mark', not 'mkmk'; in this scenario, Ü is serving as the base.

Ǖ only involves 'mkmk' if you're composing it from the base glyph U +
the dieresis (using 'mark') and then macron (using 'mkmk').

JK

@madig
Copy link
Contributor Author

madig commented Feb 21, 2016

Ah, so I'm simply going to replace the mkmk anchors in the precomposed base glyphs with mark :) Thanks!

@khaledhosny khaledhosny mentioned this issue Feb 21, 2016
Closed
@khaledhosny
Copy link
Collaborator

Also in FontForge you can explicitly set glyph classes, which is what I always do, you never know what surprising results a heuristic can give.

@adrientetar adrientetar mentioned this issue Apr 26, 2016
Closed
@rhertzog
Copy link

@madig What was the first version of cantarell that had this bug?

@madig
Copy link
Contributor Author

madig commented Apr 27, 2016 via email

gpgreen pushed a commit to gpgreen/harfbuzz that referenced this issue Jan 10, 2024
@waywardmonkeys
ci: Build shared linux against system lib. (harfbuzz#228)
f9850f8 
This stops building harfbuzz separately and tries just using
the system install to make sure that works.

This means that we build against an older version depending on
what's available on Ubuntu (since our macOS build uses homebrew
which tends to be fairly current).

Currently, that's version 2.7.4, the same as we're currently
building and packaging. Going forward, as we update what's in
use here, that should help us make sure that we're working with
older versions that can be found in the field, but we'll have to
take care to feature-gate newer APIs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@khaledhosny @behdad @madig @rhertzog @jfkthame