[Question] Avoiding FreeType?

[JCash]

Hi!
Is there a way to avoid using FreeType?
I'd like to keep dependencies to a minimal list, and also it's not exactly small.

As I understand it, HarfBuzz already has its own face+font handling functions.
From the hb docs:

hb_face_t *face = hb_face_create(blob, 0);
hb_font_t *font = hb_font_create(face);

Would it be possible to use those instead?
E.g. having something like raqm_set_hb_font()?

[khaledhosny]

It should be possible. When this code was written, the target was small clients that already use FreeType, but we otherwise don’t use FreeType API. It will need a bit of internal refactoring, but shouldn’t be that hard.

[JCash]

Thanks for the info!
Looking at the code, there shouldn't be too much of a refactor.
Adding some define to opt in or out of freetype and as you say, some internal stuff.

As I'm in the process of my due diligence of different libraries, I need to do this to continue evaluating.
I'm happy to try to make a PR with such a change, unless you feel you want to do it in the near future?

[khaledhosny]

A PR would be welcome, I don’t think I’ll be able to work on this anytime soon.

[JCash]

Great!
My first quick test seem to work.
But as I opted for a quick #ifdef approach, it all turns a little bit messy.
Perhaps that's ok..

But it also got me thinking, as it feels like FreeType isn't really needed at all inside this library?

• Freetype is used to create a hb_font_t
• Increases/decreases ref counts for the first FT_Face instance.
• FreeType is used to apply a transform onto all the glyphs during shaping.

These details makes makes me lean toward:

• Font creation be kept outside of libramq`, even the FreeType faces?
  • FreeType users can still use hb_ft_font_create_referenced(face) if they want to
• Any ref counting should be handled outside of libraqm
  • it's part of resource management imho
• The FT_Vector_Transform could be applied as a post process step, when iterating over the final glyphs.

As a newcomer to this library, proposing such a big change feels a bit awkward, but I do think the changes have merit.
The library doesn't really lose functionality, but can drop the hard requirement of an external library.

What do you think about this?

[khaledhosny]

Sorry for not answering this earlier, but we want to maintain the existing API, since existing clients use it. We also want to maintain ABI if possible, otherwise we will also need to raise the major version and all the complications that accompany it (do we want to allow the two versions to coexist, etc.).