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

2019-07-07 Thread Alexei Podtelezhnikov
> However, please do tell me, how do you think the SVG rendering > library should be connected with the SVG rendering module? Moazin, This is how it is supposed to work FT_Render_Glyph_Internal loops though all renderers that support slot->format and calls renderer->render that does 3 things:

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

2019-07-07 Thread Moazin Khatri
> > Please do not touch FT_Render_Glyph_Internal. There is a loop there > that is supposed to find your renderer and match it with the glyph > format, once your renderer is set up correctly. > Yea, my current implementation adds some code to `FT_Render_Glyph_Internal' which maybe isn't really

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

2019-07-07 Thread Moazin Khatri
> > I haven't read the entire thread carefully. However I want to point out > that how the SVG library allocates and frees memory is its own business and > should NOT be tied to FreeType memory routines. > > You still need to negotiate the bitmap allocation though. > Good point. I agree here.

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

2019-07-07 Thread Behdad Esfahbod
I haven't read the entire thread carefully. However I want to point out that how the SVG library allocates and frees memory is its own business and should NOT be tied to FreeType memory routines. You still need to negotiate the bitmap allocation though. On Sat, Jul 6, 2019 at 5:55 AM Moazin

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

2019-07-07 Thread Alexei Podtelezhnikov
On Sun, Jul 7, 2019 at 2:14 PM Moazin Khatri wrote: > > Alexei, that can work only if the rendering module > was designed with the approach that you discussed > yesterday, not with the current approach. All I am asking is to consider *existing* FreeType interfaces rather than inventing a new

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

2019-07-07 Thread Moazin Khatri
Alexei, that can work only if the rendering module was designed with the approach that you discussed yesterday, not with the current approach. As I mentioned before, at the moment, the hooks get set long after the module has been initialized, thus none of this works. Also, my `svg_lib_init' hook

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

2019-07-07 Thread Alexei Podtelezhnikov
On Sun, Jul 7, 2019 at 12:23 AM Moazin Khatri wrote: > > >> > `SVG_RendererRec' is a module that inherits from `FT_RendererRec'. This >> > was done so that I can add a new field for storing the `hooks'. >> >> Some hooks in SVG_RendererRec should be hosted in parent FT_ModuleRec. It >> seems