Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks

[Alexei Podtelezhnikov]

On Sat, Jul 6, 2019 at 2:16 PM Moazin Khatri <address@hidden> wrote:
>>
>> Do you plan runtime selection of SVG library? This is not very user
>> friendly. Perhaps it is better to have separate rendering modules for
>> each SVG library, selected at compile time. I will take a detailed
>> look at your code soon.
>
> Well, yes, at the moment it is selected at runtime. Once we decide
> on a default rendering library we could create default hooks, so the
> end user won't need to set them unless they want to plug a different
> library (other than the default one).

We should not decide this if both libraries work. We should have both
modules available so that user can FT_Add_Module or FT_Remove_Module
at runtime if user wishes. With both modules loaded, FT_Render_Glyph
will find the first one that works for FT_GLYPH_FORMAT_SVG. It is not
worth overdesigning the interface.

> All along, I have been under the impression that only
> ONE SVG rendering module will exist which will basically act as a
> bridge between FreeType and the SVG rendering library.

There is nothing wrong with two SVG modules.  From your emails it
sounds that this can actually be much simpler to implement.

> The problem of user-friendliness can be solved by putting in a
> default rendering library. Then the user won't need to do anything
> extra. However, are there more potential problems with the current
> approach?

I only want to avoid additional API calls. I do hold a grudge against
the current state of COLR/CPAL for this very reason. I wantted to have
a renderer do the job instead of the whole new complexities of glyph
color and glyph layer management.


> I am totally good with doing it with the approach that you mentioned.
> Whatever the community agrees on. :)



--
Alexei A. Podtelezhnikov, PhD