[feature-request]: "view" options for common text illustrations

[n8willis]

Having worked with the view tool for a bit, this is a short wishlist for additional flags or switches that I would find specifically useful for generating "illustration" images of the type I use in the opentype-shaping-documents repo. For text-specific stuff; not considering emoji for the time being.

So I'm aware it's a narrow use case, and also aware that not all of them are strictly doable. But I figure I'd might as well keep them together, both for clarity and in case seeing them prompts comments about workarounds.

Obviously hb-view has developed quite a lot of options over the years. The ones I believe are most directly useful are:

• --margin=a,b,c,d - margin specification is broadly useful for aligning the output of individual images (especially between fonts, but also sometimes within one). It's also important for adjusting the image margin whenever the glyph extends beyond the bounding box, as it does for lots of Indic2 glyphs with headlines, zero-width nonspacing marks, etc. The full contours are all present in the SVG file generated by allsorts view, of course, so the margin can be adjusted in postprocessing, but it would be nice to avoid doing that manually.
• --preserve-default-ignorables is useful for showing ZWJ/ZWNJ/VS/CGJ etc glyphs when they font has them, which is a common want when trying to illustrate the shaping process in a step-by-step fashion. I think it would also be useful for other debugging operations, e.g. when running tests on a text rather than entering the codepoints explicitly.
• --text-before=foo/--text-after are useful for triggering specific lookups that require backtrack/lookahead context. Sometimes it's easy enough to switch the lookup on of off directly with the feature flags, but it's not always enough.

Of secondary importance are:

• --background=rrggbbaa/--foreground are quite similar to margin in the sense of simplifying post-processing. Not hard to change after the fact, so secondary, but could be useful (e.g., to highlight a specific sequence in a different color)
• --invisible-glyph - secondary to but related to preserve-default-ignorables; for showing "intermediate stages" in behavior illustration, it's occasionally useful
• --bot/--eot - akin to the backtrack/lookahead context; I don't recall if I ever found an instance where this was required because setting individual feature flags was insufficient (like init or fina), but there are times when wrangling the setting of multiple features just for a specific outcome is almost more trouble than it is worth.

...

Diverging from "steal the best switches from hb-view" somewhat, hb-view does have an --annotate flag that places a red spot on each glyph origin. That's helpful for debugging; for the "make informative illustrations" use case, I would prefer a different marker, such as a black-and-white crosshairs. Mostly due to the introduction of color, but also for size.

It is also possible to request old/deprecated shaping models in hb-view (i.e., Indic1), but the syntax for doing that is via private --script/--language tags, which is not ideal. Seeing (and showing) how deprecated OTL shaping models work is clearly low-priority, but not entirely zero.

...

Last, but not least, the biggest one is actually feature deactivation. And, more generally, some additional options for controlling feature behavior.

Deactivating a specific GSUB feature is the main use case, to show "before"" states; same with deactivating GPOS features (although those are easier to fake by setting codepoints in isolation, etc). IIRC, there are architectural reasons why this isn't in the current feature set, but I'm including it for completeness. The "faking it" approach isn't ideal, since the result doesn't show you what the default behavior/positioning of the font is, and sometimes seeing the default/feature-less result is the piece of information that you need.

[wezm]

--preserve-default-ignorables is useful for showing ZWJ/ZWNJ/VS/CGJ etc glyphs when they font has them, which is a common want when trying to illustrate the shaping process in a step-by-step fashion. I think it would also be useful for other debugging operations, e.g. when running tests on a text rather than entering the codepoints explicitly.

For this one, would shaping still be performed? Or is it mostly a way to generate an SVG from the input glyphs?

[n8willis]

For this one, would shaping still be performed? Or is it mostly a way to generate an SVG from the input glyphs?

So, generically, it would still be doing shaping. I think the HarfBuzz version is not doing any special treatment (but I could be wrong about that; I'll have a look).

My reasoning is that I believe the general case is that the input sequence would be "Codepoint, ZWJ, Codepoint2" and the sequence would match a GSUB ligation that removes the ZWJ and one or both of the default Codepoint glyphs. So, in correct shaping, it's actually getting removed. Therefore if you can see the ZWJ glyph in the output, it's told you that the GSUB lookup didn't happen (or didn't work as expected).

Using it for making illustrations is the less-common utility for sure. The font engineering debugging folks surely expect that the sequence gets processed identically to how it would without the --preserve switch ... I think. But I'll peek and see if any special casing happens.

[n8willis]

New thoughts on how color could be used.... If the following is too complicated and deserves its own issue, say the word!

It would be helpful in some cases to specify a sequence/vector of color values for foreground, where each color value in order is mapped to the corresponding glyph image in the output. The use case I'm envisioning is that each output glyph has its own color, so it's again easy to tell that (for example) a ligature did or did not form.

Instances where the difference is small and hard to detect in a solid-black image are fairly common. There might also be occasions where overlapping glyphs make it impossible to tell (like a small diacritic plonked onto the body of the base glyph).

I think that discrete color lists would suffice; gradients and other things that plotting libraries offer don't seem like they'd apply. But there are perhaps questions that would need answering, like whether spaces or invisible/ignorables count and whether cycling through the list if there are more glyphs than colors is the only option or some other strategy would be useful to someone.