Conversation
027fc4e to
e0acc99
Compare
| corner_path: Path, | ||
| other_paths: Vec<Path>, | ||
| // the 'left' anchor of the component, (0,0) by default | ||
| #[expect(dead_code)] // used for alignment, not handled yet |
There was a problem hiding this comment.
not handled yet
does glyphsLib support these left/right anchors for aligning corner components?
https://handbook.glyphsapp.com/components/corner/ says these are relevant for diagonal stems
in general, would be nice if we can document which corner component features are NOT yet supported and maybe file a follow-up issue
There was a problem hiding this comment.
these are not supported in glyphsLib, which is why I left them out here; this is strongly based on the glyphsLib impl, and so I don't fully know what other features aren't implemented?
There was a problem hiding this comment.
glyphsLib apparently parses these left/right anchors (as effective_start and effective_end) even though it logs "not currently supported"
... then when doing the translation it only uses the x coordinate from effective_start, ignoring the y coordinate; and the effective_end (from right anchor) is not even used anywhere.
There was a problem hiding this comment.
these are not supported in glyphsLib
ok. The test is even marked xfail
I'm ok to leave this for later, if it ever becomes necessary
| .first() | ||
| .map(|hit| seg.eval(hit.segment_t)) | ||
| } | ||
| _ => None, |
There was a problem hiding this comment.
curve-curve intersection would silently return None, is that how it's supposed to work? just asking
There was a problem hiding this comment.
so good question: that had been my reading of https://github.com/googlefonts/glyphsLib/blob/f90e4060bafbb62ea76d269e77ef2823cb57190a/Lib/glyphsLib/filters/cornerComponents.py#L142-L148, but it looks like the python would actually crash in that case. In practice curved corner segments meeting curved glyph segments is uncommon, but it is supported in the glyphs sources.
There was a problem hiding this comment.
Is it actually uncommon? In a normal sans serif, all these glyphs would have curved corner components meeting curved glyph segments:
(If all corners are rounded using a quarter-circle corner component or similar)
There was a problem hiding this comment.
glyphsLib doesn't support them either. We have this issue tracking this
this is a squash of 8 commits: [glyphs] Fix a bug in corner components We were not actually finding the unbounded intersection. [glyphs] Fix stroke fixup logic (corner comps) Specifically we have to treat instroke and outstroke differently in terms of what points are used. [glyphs] fixup logic for handling start point (corners) [glyphs] Add extra corner paths [glyphs] Clean up corner component error handling [glyphs] Just skip missing corner components (this matches glyphsLib) [glyphs] Fixup point types when corner comp gets reversed [glyphs] Corner components in variable glyphs As well as glyphs with bracket layers
It looks like the original test file was tweaked a little bit to make the expectations match what the code was producing. This makes the expectation match what we see glyphs doing in this case, which matches what the rust is producing.
e0acc99 to
2c6b807
Compare
did you track it down eventually? |
|
maybe you could also file separate issue(s) after merging this about the other two things I raised in my review: support for special anchors for conner component alignment, and curve-curve intersection undefined |
no, got stuck into another diff.
done :) |
This implements (partial) handling of glyphs corner components, based on the implementation in glyphsLib.
This passes the test cases from glyphsLib, with the exception of an off-by-one related to slightly different bezier math; in that case we seem to be matching the outline actually expected by glyphs.app, and I've modified our version of the test data so that we pass.
This doesn't really move the needle much on crater, unfortunately; there is one font that should now be matching but there's a lingering issue I need to track down.