At 14:29 11.08.03 -0400, Owen Taylor wrote: >On Mon, 2003-08-11 at 12:24, Keith Packard wrote: >> 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. > Cause it is possible to embed font data in process resources you are probably right that there is no sane way to always get on the font file. >We really have a number of somewhat orthogonal issues: I have a much more basic question: How is Cairo spupposed to be used in the Gtk+ context and where are the benefits (not only on win32). The only place I currently could imagine benfit from an advanced rendering engine is between Gtk and Gdk (or between Gdk 'generic' and the platform specific backends) which would allow to do fancy things like antialiased lines in widgets, rotated text (for e.g. verical notebook tabs), etc. [ The (only a little outdated) dependency stack is show at http://hans.breuer.org/dia/dia-devel.htm It would be nice how Cairo would fit into the picture of a high level vector application which tries to provide much of the functionality I assume to be the core of Cairo. ] If the place where Cairo should live in Gtk+ is as described above [probably replacing part of the current X11 backend code], wouldn't it be possible to simply have Cairo dependending on Pango for all its font issues. What's the use of inviting a new font abstraction when there already is one (with well known and solvable limitations) ? > > 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. > So the fontconfig api needs to be used for differnt backends, right ? I.e. for win32 it would be a wrapper over the EnumFontFamilies APIs. >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(). > See above. Wouldn't it be better to improve Pango (also for Cairo needs) ? >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 Currently it appears to me that it has to be integretable with both : FreeType and the native rasterizer. > - 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) > Could my 233 Mhz notebook please be the machine to test the overhead ;-) But serious : wouldn't it be always used if the Pango/win32 backends works with a specialized fontconfig, too? Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
