yeslogic / allsorts-tools Goto Github PK

Subset Command:

$ ./allsorts subset --text "abcdefg" SourceSerif4Variable-Roman.otf d1.otf

Output:

Number of glyphs in new font: 8
Error: subset: parse error: an expected data value was missing

SourceSerif4Variable-Roman.zip

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.

I have successfully built allsorts-tools and can run a sample shaping test ./target/debug/allsorts shape -f /path/to/font.ttf -s mlm2 -l MAL "ആരും പേടിക്കണ്ട…പക്ഷേ എല്ലാരും ഓടിക്കോ" | less and can see the JSON-like output.

It is not easy to verify shaping from this output; is there a possibility to see the actual 'shaped text'? For e.g., the hb-view command from harfbuzz can output the shaped text in PNG/PDF etc. formats including other forms.

Thanks for any pointers.

Distinct from #27, there are some additional features that I believe it would be useful to embed into the SVG elements produced by view.

Currently, it looks like each glyph gets an id corresponding to its PostScript glyphName from the font.

It could be useful to also embed some other select information as well, so that the resulting SVG could be styled with CSS (or in Inkscape, possibly elsewhere). The basic use case would be to highlight glyphs by changing their fill-color, visibility, or other such attributes based on some factor you are trying to debug or investigate.

For example, highlighting whether a glyph in the final output was original or was the result of a substitution.

The blanket approach could be to embed that info as tokens with a class for the glyph. Looking at the output of the shape tool, for example, that level of info would be fairly straightforward with fields that are unambiguous, such as the glyph_origin, glyph_index, and the booleans.

E.g., you could add an is_mark to the "class= ..." list when it's True and omit it when it's False without much chance of confusion.

Slightly more complex would be something like glyph_origin_Direct where the "Direct" value gets appended. I'm not sure how complex those values could become; presumably they're all strings so concatenating them after an underscore would be predictable.

Still more complex than that would be numeric values, like liga_component_pos. There is, supposedly, a data: namespace in SVG attributes that could store whatever gets thrown at it (looking at kerning, for instance), but concatenating the value as with the strings might be all that it takes in practice.

Adding a few bits of info to a class element shouldn't impact the size of the output SVG in a significant way, and would be ignored by renderers that are not trying to distinguish things with CSS or other style-rule tooling.

Any chance there's a new release on the horizon with the post-0.8 updates rolled in?

I am trying to subset "OpenSans-Regular.ttf" and "Yellowtail-Regular.ttf". After sub-setting. I tried to use in browser and get following error: OTS parsing error: OS/2: missing required table.

The dump --encodings and --glyph-names options are applied to TTF/TTC fonts but not WOFF or WOFF2 fonts, it would be good to refactor the dump code a little to make it more consistent across font types.