Hello Craig (and Ahmet),
sorry for the very late reply, but right now there is soon the end of the semester here in Austria, which means a lot of extra exams and meetings. > To implement this adjustment, I inserted a step after all other > alignment steps in af_latin_hints_apply, which corrects the results > of the previous steps to ensure proper separation. I think this is the right solution. > The function implementing that step looks up the glyph index to > determine what type of vertical separation is needed, or if it > doesn't apply. To do this, it uses a reverse character map that was > calculated by looking up every unicode code point referenced in the > adjustment database in the font's cmap and stored with the global > metrics. As mentioned earlier, if everything works fine, this must be eventually expanded to also cover glyphs only accessible via the 'GSUB' table. > I have also learned that fonts using multiple contours where a > single one would do isn't an unusual case, so a mode that does not > need to assume the bottom shape is 1 contour will be the next thing > I do. Yes, this can happen especially in Variation Fonts. > Here are some pictures demonstrating the changes: > https://imgur.com/a/HXGY2oJ Very nice! Please also post some images with text paragraphs at different sizes so we get a feeling for the whole thing (see below also). BTW, please attach images directly to your e-mails so that they get stored in the e-mail list archive, too. > Here are my main concerns about this approach: > > - Because vertical separation adjustments are a step after all other > steps, they have the potential to clash with assumptions made by > the previous steps, or to violate constraints. Does anyone know > of issues I should watch out for? I'm not aware of any. I consider the adjustments database as something similar to the family of DELTA instructions in TrueType bytecode, which are used for last-moment fixes to adjust certain glyph points at certain PPEM values to ensure good rendering. This is always done as the very last thing, right before rendering. > - To determine which contours are higher or lower, and to adjust > their position, the algorithm makes multiple passes through all > points in the glyph. Could this be a performance issue? Ahmet, this would be a nice cooperation – can you test Craig's branch with your code to check that? > - When the assumptions the algorithm makes are broken, it can do > extreme modifications to the glyph's shape. For example, this is > what happens when you tell it that the double quotes character > should be adjusted with the "one glyph stacked on another" mode: > > https://imgur.com/a/JrUTMrQ > > The algorithm arbitrarily chose one of the quotes as being higher, > and pushed it until it cleared the other one by a pixel. This > would happen in practice if someone mapped codepoint i to double > quotes in their font. How much of an issue is this? Do any fonts > do this? FreeType always assumes that fonts do not cheat. In other words, the mapping from the input character to the output character *must* be correct. It was common practice in the days of very old Windows versions (more than 20 years ago) that some fonts abuse the ASCII range for, say, Hebrew glyphs because correct support was lacking. Today, this is no longer an issue. So: no, this isn't an issue at all. > I could prevent it by limiting the distance it can push something up > by a pixel or two. This might be a good idea in general since sometimes glyphs are designed in weird ways: For example, the two vertical strokes of the doublequote character might have different vertical positions, and such 'inaccuracies' (in the broadest sense) must not lead to bad results. > - Werner previously suggested that a gap of less than one pixel, > instead of one full pixel as I'm currently doing, might be better > in some cases. Does anyone know of such a case? 'Waterfall images' of short paragraphs can answer this, I think, so please post them for some selected fonts. BTW, I can also imagine the opposite, namely that a separation of one pixel might not be sufficiently large for some PPEM values to produce good-looking output. Werner
