freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ft-devel] OT-SVG: Some issues I have run into with the previous design


From: Moazin Khatri
Subject: [ft-devel] OT-SVG: Some issues I have run into with the previous design decisions
Date: Thu, 20 Jun 2019 15:02:02 +0500

Hi,

As mentioned in my report for week 1, I took the decision to temporarily store a
pointer to the `svg_document' and the length `svg_document_length' inside
`TT_GlyphSlot'. I have encountered two issues with this route.

1. The clients of FreeType can't access both of these fields since they are in
`TT_GlyphSlot' which is an internal type. I am not sure if we should provide
the access to the user or not, I personally think it's a good idea to do so. :)
This probably isn't that hard to solve since we can create a new API function
`FT_Get_Svg_Doc' that can return the two fields to the user.

2. I realized that the FreeType Demo tools don't work with the SVG fonts
because I haven't written the support of OT-SVG fonts in the Glyph Management
API. While writing it, I ran into the following issues:


*  The way `FT_Glyph_To_Bitmap' works currently is that it creates a

dummy `FT_GlyphSlotRec', populates it with the necessary outline

data and passes its pointer to `FT_Render_Glyph_Internal' for rendering.
This will fail in the case of an SVG glyph because the current

implementation of SVG Renderer needs `svg_document' and its length
from a `TT_GlyphSlotRec' which simply doesn't exist here.


This can be solved by modifying the implementation of
`FT_Glyph_To_Bitmap' so that for SVG glyphs it creates a dummy
`TT_GlyphSlotRec' and `TT_GlyphSlot' and pass that in instead. Not sure
how good this approach would be. But one problem would still remain:

*  The current implementation of the SVG Renderer takes the size info
by doing `slot->face.size'. AFAIK, other renderers don't do this. Rather,
the sizing information is contained in the slot itself (the outlines are
themselves scaled). No face object is available inside
`FT_Glyph_To_Bitmap'. I could create a dummy one though just with
the sizing information.


A completely alternate route is to rather store `svg_document' and its length
in `FT_Slot_Internal' by adding these new fields along with the size object.
That'll probably solve all of the issues without the need of modifying
the function
`FT_Glyph_To_Bitmap'.

I am going to try one of these solutions for now. Please let me know your
thoughts about which solution could be better.

Thanks,

Moazin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]