[cairo] Freetype to Cairo - newb needs help
behdad at behdad.org
Tue Oct 23 14:00:23 PDT 2007
On Tue, 2007-10-23 at 22:58 +0200, Donn wrote:
> > > Would I have a good argument (or not?) when I say:
> > > 1. Part of Cairo wraps Freetype (to a certain extent) already.
> > No, this is not correct.
> Excuse my use of terms, I'm an amateur. I meant "wrap" to mean "it has
> functions that do stuff with" Freetype.
> I specifically mean these:
> > > 2. Cairo faces can be made directly from FT faces in c/c++
> > > 3. PyCairo wraps Cairo.
> > > Therefore:
> > > 4. Pycairo should also offer Python versions of the FT->Cairo functions.
> > > ?
> > It should, but there's no PyFreeType, that's why PyCairo doesn't do
> > that.
> I can see that in one way, but in another: Pycairo *could* be a one-for-one
> conversion of each Cairo function and therefore those Freetype functions
> could also be exposed. Sure, there would be no FT_New_Face until a pyFreetype
> is written, but at least the Cairo end of the Freetype deal would be there.
The need for dependency is: what type of argument does
cairo.ft.font_face_create_for_ft_face() take? It should take
freetype.Face() which is not there... all I can see is to make it take
ctypes.c_void_p for now. Also make all pycairo constructors take
c_void_p too, and just wrap it... When freetype bindings show up later,
pycairo can accept the new freetype.Face() too.
Damon, can we do that?
> Then, with a little voodoo, we could use the ctypes trick to get an FT_Face
> and pass that directly into the (now imaginary)
> cairo.freetype.cairo_ft_font_face_create_for_ft_face() function.
> Unless that's already the case, but I did give it a stab and had no joy
> finding that function.
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
More information about the cairo