Re: [ft-devel] FT_Renderer for SVGs

[Werner LEMBERG]

> 1. I see that all default modules (including the renderers) are
>    initialized in FT_Init_FreeType.  Whatever hooks we decide to
>    have, there is likely to be one for initiating the external
>    library.  The function this initialization hook points to, will
>    usually instantiate the rendering backend (for example, in case
>    of cairo, cairo surface and context) and maybe the library will
>    have some object of its own too which will be initialized.  If we
>    choose this initialization hook to be called by the `module_init'
>    function, the initialization will be done on every
>    FT_Init_FreeType call (as long as SVG feature is enabled),
>    regardless of whether the font contains an SVG table or not,
>    regardless of whether the user wishes to do any SVG rendering or
>    not.  Is this a problem from performance and memory point of
>    view?  If it is, how can we move this initialization to be done
>    in FT_New_Face depending on whether there exists an SVG table or
>    not.  That'll solve it a bit, I think.  If this is to be done, is
>    there a standard approach to this?

I suggest `lazy' evaluation.  This is, add a variable

  svg_loaded

which set to zero in the beginning.  As soon as it is needed (and not
earlier), the corresponding data stuff gets loaded, and the variable
is set to a non-zero value.

> 2. If the users of FreeType want to inject their own hooks (instead
>    of using the default ones we place for our out-of-the-box
>    renderer) where and how should they do it?  Some FreeType API
>    function they can call which will grab the rendering module and
>    replace the hooks?

Something like that, yes.

>    An FT_Renderer only exposes only one or two functions, `render'
>    and `raster_render', how do I call the one that will replace the
>    hooks?  Do I subclass FT_RendererRec or FT_Renderer_Class and
>    create a new structure having that function?  Or is there some
>    other way?

It basically doesn't matter.  For example, you might add a structure
somewhere in `FT_LibraryRec' that holds the hooks.  Please try a route
that you consider practical; it should be straightforward to adjust
the locations if necessary.

> 3. I have observed that in FT_Load_Glyph, glyph data is loaded,
>    which is further used by FT_Render_Glyph (except in case of
>    bitmap embedding when there's nothing to be done).  After
>    FT_Load_Glyph is called, in simple monochrome fonts, the Glyph
>    Slot contains vector data, for SBIX and CBDT, it contains
>    everything (the bitmap itself too) and for CPAL/COLR, it doesn't
>    contain much because of the recursion mechanism in which it is
>    called again multiple times where it behaves just as with
>    monochrome fonts.  However, what will it contain for an SVG
>    Glyph?

It will be quite similar to CPAL/COLR, I believe: For a given glyph
index we take the entry in `glyf' (or `cff'/`cff2').  This is the
primary source for everything in case the font gets handled within an
environment that does not understand the SVG extension.  If there is
also data in the `SVG' table for the given glyph index, it gets used
instead of the `glyf' stuff.

>    I think it could contain a pointer to a stream of the SVG
>    document in which that glyph is located along with a glyph ID
>    (multiple glyphs can live inside a single document).  If this is
>    true, will I need to modify the FT_GlyphSlot structure to add
>    these fields?

`FT_GlyphSlotRec' is a public structure and must not be changed.  You
probably mean `FT_Slot_Internal'.  Again, I suggest that you simply
start coding; with time you'll get a feeling where such data should be
stored :-)


    Werner