Deterministic resolving of mixed component/contour glyphs #1150
Conversation
This will be useful for debugging in fontir.
When converting components to contours we need to make sure we consider dependencies between glyphs.
Making sure we handle cycles is tracked as #1062 |
|
IIUC the root problem is:
This PR says:
Maybe I'm missing something, isn't this resolved by traversing components depth-first? - would make watching for cycles easier too. |
|
maybe just unclear PR text? I'm using the same approach to determining the ordering as in the anchor propogation (it is depth first). The reason this isn't useful as general-purpose cycle detection is that we're only operating on the subset of glyphs which have mixed contours/components. |
fontir/src/glyph.rs
Outdated
|
|
||
| for name in component_ordering_within_glyphs(items.values().map(|(_, g)| g.clone())) { | ||
| let (op, glyph) = items.get(&name).unwrap(); | ||
| match op { |
There was a problem hiding this comment.
Nit: I feel like op.execute(context, glyph) might be nicer than matching on op to call a fn?
Exploratory fix for non-deterministic processing of mixed contours and paths
If a glyph has mixed components & contours, we need to convert it to use all of one or the other.
If such a glyph has a component that also has mixed components & contours, we need to make sure we handle the child component first.
We handles this by first collecting the set of such glyphs, and then determining an appropriate ordering.
I tried to keep this as simple as possible; in particular I'm defensive against cycles but am not reporting those errors here, since I assume we catch them elsewhere.