On Tue, Jan 25, 2022 at 9:48 AM Werner LEMBERG <
wl@gnu.org> wrote:
> While working on the new SVG support in FreeType three questions
> came to my mind.
After some working on the documentation I believe I can now answer two
questions by myself :-) The thing is that for serious handling of
`COLR` you must not use the `FT_LOAD_COLOR` flag at all (which only
provides a convenience rendering for `COLR`). Instead, the
application has to handle the color layers by itself.
Do you still need such a test font with SVG and COLR in it? I guess, we can make one if it's needed.
> (1) What table should have precedence? I wonder what other font
> engines do. [I think 'SVG' should have precedence, and Moazin
> implemented it that way.]
The question doesn't arise for serious `COLR` handling, as described
above. In case of the convenience `COLR` rendering, `SVG` takes
precendence.
I think the table preference decision should be made by the application, or in the FT_LoadGlyph then with flags that allow separate selection?
> (2) Does FreeType properly support this situation? In particular,
> what happens if SVG support is disabled (or no hooks set), but
> 'COLR' handling is present?
>
> [Don't know yet – I suspect there are issues.]
This must still be tested.
> (3) Should FreeType provide a means to select between 'SVG' and
> 'COLR'? Right now, both 'SVG' and 'COLR' support are activated
> with `FT_LOAD_COLOR`, which doesn't allow this. [I think this
> solution is OK.]
Yes, it is OK.
See above, I think the choice should be made by the application. That said, the way COLR is implemented, the application can still select that as preference, and FT's glyph loading is not critical for that.
FWIW, overall, I think if a font has COLRv1 and SVG, COLRv1 should have preference as it enables variable capabilities. But that may not be of such practical importance here given the differences how SVG (with callbacks for rasterisation behind FT API) and COLR (application side rendering) are handled.
Dominik