[cairo] [patch] caching, glyph, font, and glyphset patch

[Owen Taylor]

 bOK, started looking through your patch a bit. I ran out of steam/time
partway through, but some high level comments:

* For Pango, I'd really like the ability to be able to get metrics
   from a font without having a cairo_t around. This basically means
   moving some of the private cairo_font_t API public; in particular
   cairo_font_device_size_t, cairo_font_font_extents, 
   cairo_font_glyph_extents.

* I'm distinctly concerned about performance from repeatedly doing
   cache lookups. Unless I add another layer of caching, in order
   to layout a 1 meg text file, Pango is going to have to call
   _cairo_font_glyph_extents() 1 million times.

   Making the glyph cache hold sized-font references rather than glyph 
   references and exposing the sized-font object seems like it 
   would be a significant win.

   (no actual timing here, of course)

* I don't think it exactly works to have fonts reporting metrics
   in device space when transformations that aren't pure scales
   are in effect. This is because ascent/descent/advance/etc.
   are defined relative to the fonts coordinate system.

   There's also a problem, for shears in particular, of separating
   out two components - shears used to artificially oblique a font
   as compared to shears of the coordinate system in which layout
   is being done.

 * cairo_ft_font_create() is calling 
   FcConfigSubstitute/FcDefaultSubstitute/FcFontMatch. I need
   a version that works from a fully resolved pattern, or 
   alternatively a more managed version of the FT_Face interface.
  
 * The pixelsize of the font has two effects on fontconfig
   font resolution:

   - When selecting bitmap fonts, the pixelsize affects *which*
     font file will be selected in some cases.
   - The pixelsize can also affect rendering options after the
     font is selected.

   I'm not sure how these effects are handled in your framework.
   If I pass in fully resolved patterns, I can simply create a
   different cairo_font_t for each pixel size, but that seems
   to be fighting the infrastructure.

 * How do you see rendering options like antialiasing, hinting,
   and so forth being handled? again I could just create a 
   different cairo_font_t, but if a cairo_font_t roughly
   corresponds to a filename/font_index pair, then this is 
   perhaps a bit awkward.

Random details:

* The _cairo_glyph_cache_primary/secondary_cache() implementations   
   look suspicious with the cast to (unsigned long)... won't
   the matrix elements generally be smallish doubles?

* There are a couple of places like _image_glyph_cache_create_value()
   where you do:

    A) Perform operation that might allocate memory, and might fail
    B) On failure check for allocated memory and if so, free it

   I think it makes things a lot more readable if the convention that
   failing operations cannot return allocated memory is followed
   everywhere.

* The DPI values you are passing to FreeType are rather debatable.
  Two interpretations could be taken:

    - Pixels to physical units ratio
    - Point size to pixels ratio

  I think it's actually the latter not the former. But as it turns
  out, the char size and dpi are *only* used in the combination
  char_size * dpi in the current FreeType sources, so it's pretty
  moot.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040929/fece0f5e/attachment.pgp