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.

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

FontForge cannot display 'calt' or 'ccmp' features correctly in metrics window #1310

Closed
sungsit opened this issue Apr 7, 2014 · 11 comments

Comments

Projects
None yet
5 participants
@sungsit
Copy link

commented Apr 7, 2014

Hi,

I have a problem that FontForge 2014 on Mac OS cannot display Contextual Sub nor Contextual Chaining Sub properly, especially for 'calt' & 'ccmp' features. It works fine on Linux though (ArchLinux package)

I'm using FontForge 201404-07_0434 on Mac OS 10.8.5 but I got the same problem with earlier versions too. To reproduce this, you can use my sfd file then input ญุญูญฺฐุฐูฐฺ, it'll display overlapped glyphs like picture below (The red square hilighted incorrect result but the last 2 pairs are display correctly. That's strange because it is the same lookup.)

f0ntuni-a-bug2

The desired result should be like this one below (By default, Thai script requires descent-less forms for uni0E0D & uni0E10 when followed by low vowels/diacritics so I have to use 'ccmp', 'ss01' is just an option).

f0ntuni-a-ssxx

The Latin script has the same problem with 'calt' & 'ccmp' too. But other features work fine, like 'locl', 'salt', 'ssXX' for example. The generated fonts work properly though so I think it's just a problem in metrics window.

Regards,
Sungsit

@mskala

This comment has been minimized.

Copy link
Member

commented Apr 7, 2014

On my Linux installation, I get the incorrect behaviour if I manually switch the script to "Thai{Pali}" or "Thai{Sanskrit}"; correct on the default "Thai{default}". That might be some sort of clue to what's going wrong. Do you have a feature file for this feature?

@sungsit

This comment has been minimized.

Copy link
Author

commented Apr 7, 2014

Thai{Pali} & Thai{Sanskrit} are for using with 'locl' feature only, descent-less forms are required by Pali & Sanskrit languages written with Thai script though (no matter with or without low vowels).

I just pushed another branch included .sfdir & .ufo with feature files

Thank you,

@sungsit sungsit changed the title Mac FontForge cannot display 'calt' or 'ccmp' features correctly in Metrics Windows Mac FontForge cannot display 'calt' or 'ccmp' features correctly in metrics window Apr 7, 2014

@sungsit

This comment has been minimized.

Copy link
Author

commented Apr 7, 2014

I just opened FontForge on Linux then I see what you mean with Pali/Sanskrit. I forget to add THA,PAL,SAN to 'ccmp' TH Descless feature. Thank you for that but the problem is still the same on Mac.

@mskala

This comment has been minimized.

Copy link
Member

commented Apr 7, 2014

Then the question is what's different between the Mac and Linux versions. Might this have to do with a difference in the "shaper" library that's being used? I don't know how Thai interacts with OpenType, but I encountered some unexpected behaviour involving Korean and the ccmp feature, discussed in this thread on the HarfBuzz mailing list: http://lists.freedesktop.org/archives/harfbuzz/2014-January/004069.html

I had thought that ccmp was simply applied to the glyph stream before any other features, and subsequent features (i.e. the Korean-specific substitutions) would straightforwardly see the output of ccmp. Without taking a position on whether they are right or not, it appears that the developers of HarfBuzz think it should be applied in a more complicated way, interacting with "shaper" logic that is not built into the font. The shaper tags the glyphs with out-of-band information and then the Korean-specific features run in a conditional way, not all running on all the glyphs in the stream. As a result, proposed changes to how HarfBuzz works would cause my ccmp features to break, and in order to get the behaviour I wanted I had to rewrite my features to basically circumvent the shaper entirely and do all the logic in my substitution tables.

I imagine that Thai is probably also subject to "shaping" and so a similar issue might apply to it. If the Linux and Mac versions of FontForge are using different libraries for "shaping," then it could be that one of them interprets ccmp the way you want it to and the other doesn't. I don't think FontForge itself has any glyph substitution code different between Mac and Linux, except for probably calling different libraries.

@sungsit

This comment has been minimized.

Copy link
Author

commented Apr 7, 2014

That sounds possible, HarfBuzz may have some presumptions about Thai script. This may be the most relevant issue to me http://lists.freedesktop.org/archives/harfbuzz/2014-January/004041.html

But I'm still curious why the older FontForge (20120731) & the newer (2014) show different results for 'ccmp' on the same Mac (I installed 2 versions of FontForge without HarfBuzz)

This is FontForge 2012 (expected behaviour)
screen shot 2557-04-07 at 11 16 41 pm

This is FontForge 2014 (unexpected behaviour)
screen shot 2557-04-07 at 11 23 44 pm

The simple Latin substitution test file is https://github.com/BoonUni/f0ntuni/blob/dev/ccmp-test.sfd

@michal-n

This comment has been minimized.

Copy link
Member

commented Jul 12, 2014

I think I've found the culprit.

Look at lookups.c:2615. There was once just a pt = class; and the first comparison of lookups.c:2619 relied on that. Now it doesn't work, because these pointers are never equal. In effect, matching by classes or coverage is broken.

@sungsit

This comment has been minimized.

Copy link
Author

commented Nov 12, 2014

I've installed new FontForge from Ubuntu PPA but this old problem still remains. So I tried master branch and changed pt = copy(class); to pt = class; in lookups.c#L2630 before start compiling. I have no idea what the hell pt is but change that line as @michal-n suggested seem to the fix the problem.

@sungsit sungsit changed the title Mac FontForge cannot display 'calt' or 'ccmp' features correctly in metrics window FontForge cannot display 'calt' or 'ccmp' features correctly in metrics window Nov 12, 2014

@adrientetar

This comment has been minimized.

Copy link
Member

commented Nov 12, 2014

Points back to 3cb817b. @rrthomas Why did you add the copying there?

@adrientetar

This comment has been minimized.

Copy link
Member

commented Nov 12, 2014

@sungsit That’s because the pt==class check afterwards compares two pointers adresses, however when you copy a pointer it gets another address (and another place in the memory).

If the goal is to not mutate the caller’s ptr, we should assign the copy to two ptrs, one being the reference. But the check is essentially "is this the first loop turn" so maybe there’s a simpler way to do it.

@rrthomas

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2014

Apologies @adrientetar, you're right that I was trying to avoid mutating class, but it wasn't mutated anyway.

In sane language, GlyphNameInClass is actually a general-purpose routine, trying to find whether class is in name.split(' '). I suggest you rewrite it using g_strsplit, thereby making it shorter, simpler and more robust.

Or if you prefer, just revert the changes to this function.

Either way, I'd make the second argument const so that it really can't be changed without getting a warning.

@rrthomas

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2014

I supply the second option, but with some simplification, as PR #1917.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.