Hey, I've been working on the tilde correction over the last few days. During this time, I realized that knowing the bounding box of the tilde contour would help a lot. In fact, the logic for the other vertical separation adjustments assumes that it can get the bounding box by taking the minimum/maximum coordinates of all the points, but this doesn't work because of off-points, which I didn't consider at the time. How do you find this bounding box?
Also, thanks for clarifying what your intended solution is for the GSUB handling. I should note that, in your example, check #3 is too restrictive. The logic allows for the bottom shape that needs to be separated to be made up of any number of contours, which allows it to work for characters with more complex shapes. I want to clarify: are you adding glyph names in the database as a requirement for the project? On Fri, Jul 21, 2023 at 4:52 AM Werner LEMBERG <w...@gnu.org> wrote: > > >> Many-to-one: accent marks, e.g. umlauts > >> One-glyph-to-many-unicode-characters: ligatures, e.g. "ff", "fi". > > > > I don’t see how these two cases are different. An accented glyph like > > ⟨ɑ̃⟩ is made up of two Unicode characters, ɑ+◌̃ (U+0251 U+0303); > > similarly a ligated glyph like ⟨fi⟩ is made up of the two Unicode > > characters f+i (U+0066 U+0069). > > The first case is usually handled in the GPOS table; the auto-hinter > can only ignore this because the rendering of the components doesn't > happen together but in succession. See my other mail that gives both > a many-to-one and a one-to many example that might be part of GSUB. > > > Werner >
