“ Issue seems to be if cluster includes reordered pre-base vowel sign, the next cluster inherits the same colour, so e.g. a word like द्विविधं ends up all being the same colour.”

Using Amiri-Regular.otf and the text ربها.

• start lookup 78: The serialization is the same as end lookup 11 above it, but the rendering is different (it shows what would happen a few lookups below).
• The 2nd end lookup 77, the serialization is different from the end lookup 77 above it, but the rendering is the same.
• start lookup 197 shows the same rendering as end lookup 198 though the serialization is different.

I cannot find anything about this this in the OpenType specification. Searching for "recursing" or "recursive" does not yield any results. I always assumed that features are processed sequencially, but this sounds as if one feature is called from another. Can you provide a link where this is explained?

These are some options that woukd be handy for debugging:

• direction (can’t be always guessed correctly)
• script (ditto, nothing fancy an input field should do)
• language
• preserve default ignorables
• features (also nothing fancy, an input field should do; it is important for me to be able to apply features to parts of the text)
• face index (for font collections, low priority)

I haven't tried it from source yet, so maybe it's just the demo that's not up to date... But when I go to https://www.corvelsoftware.co.uk/crowbar/ and upload a testfont, then type in som sample text like "ollo" and hover over the coloured glyph names "l (25)" or "l.highin (56)", a red outline is added to the corresponding coloured glyph to highlight in the preview, which causes the whole preview to grow a few pixels higher and all letters to move a few pixels down.

I also have a technical question: How did you manage to make the "calt" tables work? As far as I know, opentype.js doesn't support those yet (see opentypejs/opentype.js#443). Ok, that applies to writing functionality only.

For the string ⟨כֹ⟩ in Cascadia Code 2106.17, HarfBuzz puts the holam at the top left whereas it appears directly above in Crowbar’s colored glyph display. It’s probably another limitation of compiling with HB_TINY.

Both http://www.corvelsoftware.co.uk/crowbar/ and a local npm start (nodejs 16.x) show the error "wasm validation error: at offset 4: failed to match magic number" in the console, i.e. the software won't load :(

Everything seems to be reported as code points now:

hb-view -V will show all the lookups being applied, even of they don’t change the buffer, and this can become noisy. Crowbar smartly filters such no-op lookups out, which is good most of time. However, sometimes I’m trying to see why a certain lookup is not making an effect, so I need to see where it is being applied and what is the stat of the buffer at this point.

The website seems to be using HarfBuzz that had that regression, and it bit me than once already.

It would be informative for the Script and Language drop-downs to include an indicator showing which languages/scripts have features defined.

Uploading Unifont 13.0.02 makes the entire UI disappear.

HarfBuzz automatically applies 'frac' in the presence of U+2044 FRACTION SLASH, but Crowbar doesn’t.

I use Crowbar a lot to debug FRB American Cursive+Print…

This image of the nonsense string "Ö́̆ḧ" helped me track down what I need to do about stroke numbers being sucked in by the gravity of bases and not adhering to that of marks:

Ö́̆ḧ

The answer is—more careful use of mark filtering sets, for the curious. Not what this issue is about for sure. :)

The (textual) buffer contents change, but the rendered output does not change until I move the cursor to a different line and back.

I am a complete newbie to text rendering so forgive me if I use wrong terminology.

I tried to see the text नमस्कार using font Noto serif Devanagari.

I remember seeing about 2 weeks ago that at some of the shaping stage, if I moved my mouse on that stage the individual characters would show up in the render (in the top right corner) instead of the merged ligatures. But today (12 May) for all stages, the render remains unchanged.

i.e. -

previously : नमस्कार would show up something like - न म स ् क ा र at some stages.

now : नमस्कार shows up like नमस्कार at all stages.

The text size seems to be relative to the bounding box of the text (the bigger the bounding box the smaller the size), this can cause unnecessarily rescaling when moving from lookup to another or when entering new characters that would change the over all bounding box of the text.

Currently, you hover over each shaping stage in the table and the canvas in the upper right corner will update with its state. With complex scripts, it would be nice if there was a canvas for every step though:

It would be nice ot not only have the lookup type as text, but also the lookup type and subtype as number. This could be added behind the already displayed lookup type name (for example "single substitution 1.2").

With Tangut Yinchuan 13.001, the SVGs of the glyphs of many characters, e.g. ⟨𘟷⟩, are mangled.

Given this font and the input string “𛰁” (U+1BC01 DUPLOYAN LETTER X), Crowbar crashes: the page goes completely blank. That single-character input produces 253 glyphs.

Screenshot (likely GIF)

What is this project?

Why does it exist?

What is the end goal / vision ?

Needs implementation in harfbuzzjs/hbjs.c:do_trace

Not even getting into the color-deficient-vision question, it's not clear whether magenta or blue mean "on", so incorporating some additional UI hint on the features toolbar would clarify the state a lot. Seems like a small checkmark or x would do the job without adding significantly to the real estate required.

I’m trying to expose the version of HarfBuzz used, but the symbol I want is not seem to be exposed in harfbuzz.wasm, and there is not documentation how it was built and from what sources.