[draw] Finish and release draw API

[behdad]

Okay I'm determined to finish and release draw API in the next three weeks of hacking. @ebraminio are you available to help? @khaledhosny can I get some help from you?

I know what I like done, and I'll enumerate that in the next comments. Before that, I like to know how @ebraminio was testing this. I guess with JS? UPDATE: Using src/main tool.

[behdad]

So far what I like to change:

• Use float instead of hb_position_t in the API. If nothing else, saves a roundf() per position.
• The callbacks should also get the hb_draw_funcs_t pointer themselves. It was a lazy move to not do that to begin with.
• Expose the hb_draw_helper_t object as a public struct, called hb_draw_state_t or similar; pass them to callbacks as well.
• Add public API called hb_draw_move_to, hb_draw_line_t, etc, that operate on a hb_draw_funcs_t and a hb_draw_state_t; might need to add a hb_draw_new_path() or similar to initialize the state.
• (hardest probably) make hb-view use these and plug into cairo user-font API to render without cairo-ft.
• Remove return value of hb_font_draw_glyph.
• Make hb_font_draw_glyph a callback of hb_font_funcs_t.
• Implement above in hb-ft.
• Figure out interaction with synthetic_slant.
• Document draw callbacks.
• Write tests for the hb_draw_move_to/etc.

[ebraminio]

Okay I'm determined to finish and release draw API in the next three weeks of hacking.

Great to hear!

Guess now needs coordination with the brand new _synthetic_slant also.

[behdad]

Guess now needs coordination with the brand new _synthetic_slant also.

Interesting question!

[khaledhosny]

@khaledhosny can I get some help from you?

Sure, what do you need me to do.

[behdad]

• Implement above in hb-ft.

@khaledhosny How about this?

[ebraminio]

Implement above in hb-ft.

How about this?

Guess these will be useful,

• FreeType: https://github.com/harfbuzz/harfbuzz/pull/2185/files#diff-5f9da06928ddb39791ce9bf3ccf6f7840b4fa310d7c45bb03a636a6ca7e16af2
  or this one: https://github.com/harfbuzz/harfbuzz/pull/2183/files#diff-5f9da06928ddb39791ce9bf3ccf6f7840b4fa310d7c45bb03a636a6ca7e16af2R983
• GDI: https://github.com/harfbuzz/harfbuzz/pull/2183/files#diff-68914fbcf819bd13f4411baab71b1d71b530bb520bb13ef2f9074622b0221825R1038
• CoreText: https://github.com/harfbuzz/harfbuzz/pull/2183/files#diff-762f8007a49dafcbe4ff5a2f7077b4576edd6047c7a75686a6ab06ae868e47f5R1166
• DirectWrite: https://github.com/harfbuzz/harfbuzz/pull/2183/files#diff-0ed175486367eab57a67582c28e91f0f01412c0b1686f717427c940aa18ac560R979

[behdad]

• Write tests for the hb_draw_move_to/etc.

@ebraminio Can I get help from you on this one?

[behdad]

First rendering from hb-draw in hb-view. Not perfect, but not nothing. I believe the shortcomings are cairo-user-font shortcomings, not ours...

[behdad]

I believe the shortcomings are cairo-user-font shortcomings, not ours...

And as I suspected, fixed in cairo main... Just not in a release yet :(.

[behdad]

In its full glory with cairo main branch.

[behdad]

To summarize, what's left:

• hb-ft implementation
• chaining up to parent font in hb-font's default implementation
• Figure out interaction with synthetic_slant.
• Document draw callbacks and other new API.
• Write tests for the hb_draw_move_to/etc.

I think this can go in then, with the hb-view implementation as well, but will depend on very recent cairo. So initially I suggest we push in everything but that last bit.

[behdad]

I think this can go in then, with the hb-view implementation as well, but will depend on very recent cairo. So initially I suggest we push in everything but that last bit.

Okay, rewrote the logic to keep the cairo-ft implementation as well, but enable the hb-draw logic if cairo is recent-enough (1.17.5 version-check) AND font-funcs are NOT ft. The latter check can be removed when we implement the callbacks for hb-ft.

[behdad]

Question: Should I add back the return value of the hb_font_get_glyph_shape() call? Such that callers can know whether implementation exists?

[behdad]

Question: Should I add back the return value of the hb_font_get_glyph_shape() call? Such that callers can know whether implementation exists?

I personally don't see the point of that. You are writing the code, you know what's on the other side...

[ebraminio]

Also added a test for ft callback 0429921 feel free to just remove the commit from history if you don't see fit.

Also any interest on having binding to coretext/gdi/directwrite #3411 (comment) somewhere somehow? Just though it could be nice for the sake of debugging and so later.

[behdad]

Also any interest on having binding to coretext/gdi/directwrite #3411 (comment) somewhere somehow? Just though it could be nice for the sake of debugging and so later.

If you are willing to implement the rest of the font-funcs callbacks for them... In 10+ years no one bothered / cared / requested.

[behdad]

@ebraminio why did the linux-ci bot fail?

[ebraminio]

why did the linux-ci bot fail?

My local freetype version is 24 and the CI one is 21 and that apparently means different results (or maybe because the debug bit leftover I just spotted now)

I swapped the test case with a simpler one case just to test line_to/quadratic_to commands of ft callbacks are emitted correctly.

[behdad]

Would be nice to add a hb-draw commandline tool also, that spews SVG-like draw commands given glyphnames...

[ebraminio]

Would be nice to add a hb-draw commandline tool also, that spews SVG-like draw commands given glyphnames...

I wish it could create a SVG from input text without Cairo, say like https://harfbuzz.github.io/harfbuzzjs/ demo which creates SVG from input text, I needed accurate rendering of some text in SVG to upload to Wikipedia and shaped the tool for the purpose which creates relative SVG path also to have more optimized yet accurate result.

Just to note main.cc also creates SVG for individual glyphs of a font when hb-draw is enabled and supports COLRv0/SVG/png dumping also.

[behdad]

Would be nice to add a hb-draw commandline tool also, that spews SVG-like draw commands given glyphnames...

I wish it could create a SVG from input text without Cairo, say like https://harfbuzz.github.io/harfbuzzjs/ demo which creates SVG from input text, I needed accurate rendering of some text in SVG to upload to Wikipedia and shaped the tool for the purpose which creates relative SVG path also to have more optimized yet accurate result.

Maybe we can spec and develop that separately then. I like to merge this soon.

[behdad]

behdad/glyphy#39

I ported GLyphy to use hb-draw:

[yisibl]

I wish it could create a SVG from input text without Cairo, say like https://harfbuzz.github.io/harfbuzzjs/ demo which creates SVG from input text, I needed accurate rendering of some text in SVG to upload to Wikipedia and shaped the tool for the purpose which creates relative SVG path also to have more optimized yet accurate result.

Maybe we can spec and develop that separately then. I like to merge this soon.

@behdad Any progress since then?

[behdad]

@behdad Any progress since then?

No. Can you use the hb-view SVG output and massage it through svgopt or other tools?