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

No width linking of brace layers #985

Merged
merged 3 commits into from
Apr 25, 2024
Merged

Conversation

schriftgestalt
Copy link
Collaborator

it was getting it form the master they are attached too and that is supposed to have a different width

@anthrotype
Copy link
Member

it's not clear to me what this is doing (or no longer doing), can you please clarify?

@schriftgestalt
Copy link
Collaborator Author

This is mostly a hot fix for a specific project. Brace layer almost always have a different width than the master layers they are attached too. Linking to that width will mess things up. There might be some extra layer that might benefit from linking, so this needs more testing. Until then, this is a draft.

@belluzj belluzj force-pushed the no-width-linking-of-bracelayers branch from f79047b to 3667c04 Compare April 22, 2024 14:50
@belluzj
Copy link
Collaborator

belluzj commented Apr 22, 2024

I rebased this branch on top of main and will add a test file that has a bad case and gets solved correctly by this branch. I think the required scenario is this (font with Weight and ROUND axes):

  • Glyph /a
    • Regular (400, 0): advance width = 100
      • Brace layer {500, 0}: advance width = 200
    • Bold (700, 0): advance width = 300
    • Regular ROUND (400, 1); advance width = 100
      • This master layer has a "metricsSource" pointing to Regular (400, 0) to ensure the widths are consistent
      • Brace layer {500, 1}: advance width = 200
        • This brace layer is under consideration for the test
    • Bold ROUND (700, 1): advance width = 300

Previously, the advance width of the brace layer {500, 1} would be forcibly taken from the metricsSource of the master layer Regular ROUND (400, 1) to which the brace layer {500, 1} was attached, and so it would get 100 instead of 200.

With this patch, the advance width of the layer {500, 1} will not be changed, because the the layer {500, 1} does not define itself a metricsSource.

@schriftgestalt is that an accurate description of what this patch does?

@schriftgestalt
Copy link
Collaborator Author

That is correct.

belluzj and others added 2 commits April 23, 2024 09:10
it was getting it form the master they are attached too and that is supposed to have a different width
@belluzj belluzj force-pushed the no-width-linking-of-bracelayers branch from 3667c04 to 0e58873 Compare April 23, 2024 08:11
@belluzj belluzj marked this pull request as ready for review April 23, 2024 08:12
@belluzj
Copy link
Collaborator

belluzj commented Apr 23, 2024

@anthrotype @simoncozens This is ready for review. I added a test, and I checked locally that the test was failing before the patch (the glyph had width == 100) and is green after (width == 200 as specified in the file).

else:
width = None
return width
master = font.masters[layer.layerId]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is the important change of the patch, it says to only consider the master of this layer (if any) for the metrics source, and never the "associated master". For intermediate layers it means that there's no metrics source, whereas previously they used the metrics source of their parent layer, which was wrong.

@simoncozens simoncozens merged commit cedaacd into main Apr 25, 2024
10 checks passed
schriftgestalt added a commit that referenced this pull request Oct 23, 2024
* Add test

* No width linking of brace layers

it was getting it form the master they are attached too and that is supposed to have a different width

* Fix lint

---------

Co-authored-by: Jany Belluz <[email protected]>
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

Successfully merging this pull request may close these issues.

4 participants