harfbuzz
Interest in exposing bitmaps (EBDT) similarly to png (CBDT)?
It doesn't take much more code (but potentially a lot of renaming) to support EBDT so I wondered if there was interest in supporting it, and an api like hb_ot_color_glyph_reference_png for it. There are at least some comments about adding support for some of the other formats common in EBDT tables.
An ad-hoc implementation can be seen in https://github.com/kkartaltepe/harfbuzz/commit/c42c79313d22f6a1b482bde3223560aab749381c (pardon my poor naming sense). Which works well enough for pulling bitmaps from the few fonts I needed it for.
I would probably have some time over the next few months to try and make this upstreamable, add testing, etc if there is interest (and perhaps someone to answer some questions).
The problem with the non-PNG / non-color bitmaps is that 1. the way they are encoded is a pain, and exposing their encoding is also is a pain. Can you fully spec out the API first, in a way that would be able to fit the full table?
the way they are encoded is a pain, and exposing their encoding is also is a pain.
Right I only implemented the case of byte aligned bitmaps, looking back at the spec to cover everything it seems there are only 3 formats. Bit aligned, byte aligned, composite (format 1,2,8 ignoring metrics differences). And composite glyphs have metrics but reference other glyph ids for their bitmap data. Because EBLC allows for variable metrics it may be the case that these composite glyphs have different metrics (is it legal for a component glyph to have a higher bitdepth than the metrics of its parent?). So gathering the components in two steps seems simple, first attempt to handle component glyphs (potentially recursively since this is allowed), then gather references for the resulting glyph ids.
My referenced example implementation above doesnt handle bit/byte alignment differentiation because I had removed it for a simpler interface but we can add this by returning the stride in bits for the caller. Strides that are not multiples of 8 are bit aligned.
hb_blob_t *hb_XXX_glyph_reference_bitmap (hb_font_t *font, hb_codepoint_t glyph, uint32_t *bitdepth, uint32_t *width, uint32_t *height, uint32_t stride_bits)
hb_codepoint_t *hb_XXX_glyph_bitmap_components(hb_font_t *font, hb_codepoint_t glyph, uint32_t component_num, uint32_t *width, uint32_t *height) Here its unclear if we need to return additional metrics such as bitdepth (can this be different between the parent and child glyph metrics?). In the case of non-component glyphs probably returning nullptr and component_num=0.
Let me know if there are additional formats for the table im mostly working off of freetype's sbit renderer and https://docs.microsoft.com/en-us/typography/opentype/spec/ebdt
Happy to work this out with you and get into the library. Good timing as we are also adding hb-draw API. Would be great for a HarfBuzz 4.0 release soon. I'll reply soon with deeper thoughts.
I was playing with this again last week. At least for testinggulim.ttc from windows appears to provide component-ized glyphs in format 8. And at least the code for decomposing glyphs into their components in harfbuzz is very simple to add.
However a good API for harfbuzz is another story. This particular font seems tricky as there are outline and bitmap versions of glyphs for a test phrase 웬 초콜릿? 제가 원했던 건 뻥튀기 쬐 끔과 의류예요.얘야, 왜 또 불평. So how/should harfbuzz expose this information (previously I simply assumed EBDT containing fonts were bitmap fonts).
I ended up with a decompose function like HB_EXTERN uint32_t hb_ot_color_glyph_decompose_bitmap (hb_font_t *font, hb_codepoint_t glyph, uint32_t in_size, hb_codepoint_t *out_glyphs, hb_position_t *out_offsets) returning the size of the written elements of new glyphid's and offsets. Mostly to force the caller to allocate memory, I think this might be reasonable as docs mention there is a maximum stack size that limits the max number of components.