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

Overlapping components don't get merged in static ttf #813

Open
RosaWagner opened this issue Oct 8, 2021 · 4 comments
Open

Overlapping components don't get merged in static ttf #813

RosaWagner opened this issue Oct 8, 2021 · 4 comments

Comments

@RosaWagner
Copy link

We just noticed while dealing with League Spartan

In static ttf, overlapping components are decomposed but outline don't get merged (and so they overlap). If static ttf have merged contours by default, so decomposed components should too, right?

Building process uses gftools builder with direct source as argument. Before and after export:

Capture d’écran 2021-10-08 à 12 30 15

Capture d’écran 2021-10-08 à 12 30 00

cc @emmamarichal (who is currently working with me to onboard fonts in Google Fonts)

@anthrotype
Copy link
Member

anthrotype commented Oct 11, 2021

overlapping components are decomposed

decomposed how, by whom?
This is currently not done automatically by the compiler. fontmake (via ufo2ft's preProcessor) only automatically decomposes mixed glyphs containing both contour and components (of course because TrueType can only contain either simple contour glyphs or composite glyphs all made up of components, not both).
This automatic decomposition of component in mixed glyphs is performed before the overlap removal step, so that the contours get merged if they overlap.

Perhas you are inserting a ufo2ft filter to decompose specific composite glyphs that you know contain overlapping components (like this)?

If so, make sure to define the filter as a pre-filter, i.e. one that is performed before the default filters (which include overlap removal for statics). You do that by setting pre=True in the filter dict definition, e.g. {"name": "decomposeComponents", "pre": True, "include": [...]}, or (in plist xml format)

        <key>pre</key>
        <true/>

@anthrotype
Copy link
Member

Building process uses gftools builder

I'm not familiar with the tool, or whether/how it calls fontmake under the hood, whether it builds static fonts from the sources directly (e.g. fontmake -o ttf), or whether it first builds variable font and then creates static instances from them using fonttools.
In the latter case, the fonttools varLib.instancer does support decomposing overlapping components before removing any overlaps

https://github.com/fonttools/fonttools/blob/a5173b218a02e0e48d7fdc9a3cc917560d9f6118/Lib/fontTools/ttLib/removeOverlaps.py#L170

@RosaWagner
Copy link
Author

Ah ok thanks for the explanation, in that case I cc @m4rc1e cause it is probably be an issue from the builder then.

@simoncozens
Copy link
Contributor

overlapping components are decomposed

decomposed how, by whom?
This is currently not done automatically by the compiler.

I wondered about this this morning. I don't quite understand it. We remove overlaps from overlapping contours because certain environments have rendering issues with overlaps. But surely those environments would also have rendering issues with overlapping components too? So I'm not sure why it makes sense to remove overlaps from contours but not components.

(I was actually thinking about this the other way around: if overlapping components are actually supported in rendering environments, then we can "remove overlaps" from contours by simply turning them into components, avoiding all the fiddly pathops math.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants