[cairo] User font feature

Keith Packard keithp at keithp.com
Sun Apr 9 22:08:27 PDT 2006


On Sun, 2006-04-09 at 17:51 -0400, Behdad Esfahbod wrote:

> ARGB glyphs are pretty interesting, for example you can create a
> Valentine's font that draw little red hearts instead of dots for
> i and j :).

Yeah, yeah. I guess we should support them, but it won't be any more
efficient than colored Type3 glyphs.

> If you need anything other than a toy api, you need this, for
> kerning, for ligatures, for non-Latin shaping, and a lot more.

No, cairo doesn't do shaping. Shaping is done by higher-level libraries.
We might even insist that these fonts not have a unicode->glyph
conversion function, but that may be going too far.

> > - The render_glyph callback needs to take a cairo_t instead as
> > suggested by Behdad.  This way we can render alpha masks for the
> > glyphs we do now, but it will also be possible to render a user font
> > glyph into an SVG glyph or Type3 glyph.  The glyph path isn't
> > sufficient for outputting SVG or Type3 fonts as the source user glyphs
> > may be bitmap or ARGB glyphs.  Passing a cairo_t to the render_glyph
> > callback also let's us set the font matrix as the ctm for that cairo_t
> > and we can specify that the callback must render the glyph in a unit
> > sqare.  Not sure this works so well, though, if the application wants
> > to do hinting or pixel grid snapping.

I just wrote some Type3 glyph generation code for the PS backend. In
that case, I created glyphs in 'device space' and set all of the
matrices to identity. It's nice to have this choice.

If we're creating a cairo_scaled_font_t, then we've fixed the
user->device transformation already, so we can talk in device space in
the font code, or we can talk in user space and expect that the user
code will know what the transform is. In either case, different
coordinate systems will require different cairo_scaled_font_t objects,
leaving the hinting and snapping up to the rasterizer.

The cairo_scaled_glyph_t code also allows glyphs to contain *only* a
surface and not an outline. I'd suggest exposing an API similar to the
existing glyph generation API which includes a mask of
metrics/path/surface directing the generation of information.

I suggest that the basic API should talk in cairo_scaled_font_t objects
exclusively, and provide a function which computes the
metrics/path/surface for a specified glyph. That will be easy to hook
into the existing font mechanism.

something like:

cairo_scaled_font_t *
cairo_user_font_create ( const cairo_matrix_t *font_matrix, 
                         const cairo_matrix_t *ctm,
                         ... )


-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060409/c0caf3d6/attachment.pgp


More information about the cairo mailing list