[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks
From: |
Alexei Podtelezhnikov |
Subject: |
Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks |
Date: |
Sat, 6 Jul 2019 16:12:56 -0400 |
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
- [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Moazin Khatri, 2019/07/05
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Behdad Esfahbod, 2019/07/05
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Moazin Khatri, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Alexei Podtelezhnikov, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Moazin Khatri, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Alexei Podtelezhnikov, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Moazin Khatri, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks,
Alexei Podtelezhnikov <=
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Werner LEMBERG, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Moazin Khatri, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Alexei Podtelezhnikov, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Werner LEMBERG, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Werner LEMBERG, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Alexei Podtelezhnikov, 2019/07/06
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Moazin Khatri, 2019/07/07
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Alexei Podtelezhnikov, 2019/07/07
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Moazin Khatri, 2019/07/07
- Re: [ft-devel] Accessing `ft_mem_*' from OT-SVG hooks, Alexei Podtelezhnikov, 2019/07/07