freetype-devel
[Top][All Lists]
Advanced

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

ft2-demo ot-svg support ported to python feeetype-py/pycairo


From: Hin-Tak Leung
Subject: ft2-demo ot-svg support ported to python feeetype-py/pycairo
Date: Thu, 29 Jun 2023 14:37:46 +0000 (UTC)

Hi,

Having looked at the librsvg code recently I thought I'll see if I could re-write it in python, with freetype-py / pycairo and gobject introspection of librsvg. Here it is.

https://github.com/rougier/freetype-py/pull/174

There is currently a small flaw I hope to fix in another commit soon: it is a bit painful to allocate a python object/dictionary to keep the state of the rendererhook, and pass it back and forth to c-side of libfreetype, so it is currently a client side global.

On the way I found two little flaws with the original c code - cairo's RGBA32 format is host native, while freetype's RGBA bitmap is small-endian. It works at the moment, because the generation of color bitmap and drawing with the bitmap are both via cairo; this strictly-speaking means on some platforms the color bitmap stored in freetype isn't what it says on the tin... 

The other little thing is that there is a small redundancy - the svg layer rendering code in librsvg can take null to draw the whole svg document - so there is no need to use both document-render and layer-render. That would cut out a large if/then block with some 20 lines.

A third thing: the layer drawing code also doesn't check glyph id is between start and end - should it? It probably would have flagged the recent Google font bug there, where the glyph id is outside start/end, from bug in subsetting.

This, plus dropping older librsvg support (gobject actually emit deprecation warnings per run!), and python variables don't need to pre-declare / cast to and from double to int, means the equivalent python code is less than 1/2 the length of rsvg-port.c .

I'll hope to fix the state global issue soon. That rendererhook API with a pointer to pointer argument is a bit painful to use with non-C language - can we do something like the Contour_Compose() callbacks next time, with a single pointer which is carried around? 

Oh, this use gobject introspection so is probably not too portable (ie windows), and depends on a few gtk/gnome-ish things. Wonder if it works on windows with windows libgobject?

reply via email to

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