> 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
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
