On Mon, 2003-08-11 at 12:24, Keith Packard wrote:
> Around 10 o'clock on Jul 30, Owen Taylor wrote:
>
> > And for the real API, you need:
> >
> > - Scale/Apply a transformation matrix to a font
> > - Render a glyph to a bitmap
> > - Add a glyph to a cairo path
>
> There are two other important operations:
>
> - convert a glyph to a path
That was my third item, see above :-)
> - embed glyphs in a postscript file
>
> Can I use Windows (or OS X) apis to get the outline of each glyph?
Both of these are certainly possible with the Windows API; you
can get the outlines and you can get the contents of individual
TrueType tables. On the other hand, it's really hard (possibly
impossible?) to get the filename for font located through the
the Win32 APIs.
We really have a number of somewhat orthogonal issues:
A) Do we use native font objects and rasterization APIs when
possible?
B) Do we require using fontconfig for all font operations,
or you can create a Cairo font object from a system
font directly using system-specific API?
C) Do we export fontconfig-based APIs as a standard way
of naming fonts.
I think A) has to be "yes" if we want fontconfig to be useful
for real toolkits on multiple platforms.
If you set up things to allow A), B) comes naturally. If you
have a CairoFontWin32 implementation of CairoFont, you can have
cairo_font_win32_from_logfont().
C) is a little more of a tricky question - it would be nice to have a
consistent font listing and naming API, but I think it would be
premature to say that fontconfig can work as that API until
we have a working implementation on Windows that:
- Doesn't rely on direct file access
- Integrates with the native rasterizer rather than FreeType
- Has minimal overhead when not used (E.g. - I don't see
fontconfig as useful in a GTK+/Pango/Cairo/Win32 situation,
so I don't want to pay 200k per process and 100ms of startup
time)
Regards,
Owen
