At 09:24 11.08.03 -0700, 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 pathThe function to use on win32 is GetGlyphOutline. I''m discussing how it could be used to make gtk-win32 apps more independent of direct Freetype usage in http://bugzilla.gnome.org/show_bug.cgi?id=107668> - embed glyphs in a postscript fileThe funtion to use is GetFontData, but I''m not sure if this (producing PS files) is really that useful on win32. Remember there is already an almost working Device Context abstraction in the platform for a long time. With it you are not forced to use (expensive) Postscript printers or an external program like Ghostcript, but can simply use almost the same code to render to display or _any_ printer (with a windoze driver) even those ugly GDI only printers which put the burden completely on the PC side. There is some code of mine which does use it in dia/plug-ins/wmf/wm.cpp and dia/app/paginate_gdiprint.cpp both in GNOME cvs.> >Can I use Windows (or OS X) apis to get the outline of each glyph? If >not, then I''m not sure how we can make cairo work in those environments >without replacing the OS-specific font libraries with FreeType. >I''m expecting these kind of APIs to be available for OS X as well where there is ''display pdf'' but currently don''t have access to my iBook.>I think we should consider os-specific font selection mechanisms though, >with fontconfig used where appropriate. >My main problem with fontconfig on win32 is perfectly described by Owen in the previous mail. The only thing I like to add is that I still doubt it''s useful to have two independent font rendering machineries in one process - but if there is : they need to interact sane, have the same names and properties for the same fonts, etc. Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I''ll tell you how to get along without it. -- Dilbert
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 FreeTypeCurrently 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
On Mon, 2003-08-11 at 20:04, Keith Packard wrote:> Around 18 o''clock on Aug 11, Owen Taylor wrote: > > > I don''t think even linking to FreeType on, say, Windows is right; for > > various reasons: > > Hmm. I''m thinking of applications that want to generate identical results > on every system; using different font mechanisms makes that very difficult. > > One obvious such application is a cairo test suite...If you haven''t noticed, no two consecutive versions of FreeType produce the same output :-). You also won''t get the same output unless you have control-point-per-control-point, hint-for-hint identical fonts. If you really want an automated test suite, then that''s where having the ability to drop in a new font backend is really useful. You drop in a back-end where you control the exact pixels of the glyphs; they don''t have to be anything fancy, just some boxes and circles drawn with the Cairo API.> > - Having cairo_font_t be polymorphic on a single system is going > > to be confusing and lead to problems where people assume that > > a font *must* be a cairo_font_win32_t. > > Hmm. Perhaps we don''t need a ''cairo_font_win32_t''; all we really need is > the ability to convert from an FcPattern to a windows font handle (HFONT?) > or FT_Face.I guess I''m pretty set on an OO mindset these days. :-) I definitely see "a few extra win32 methods" as being inheritance rather than just some extra code we compile in on Windows. I''d tend to say that if we are going to have multiple font implementations, especially on the same platform, but even if not on the same platform, virtualization makes a lot more sense than a bunch of #ifdef''s and switches.> > It isn''t a bad idea to allow people to plug in a new font > > system on the fly if they are doing something really custom, but > > having two font systems always there is rather peculiar. > > Hmm. That means that cairo applications will only be portable if they use > the trivial interface; those using lower level interfaces will need system > specific code. I think this means we should build an intermediate > interface that provides enough flexibility for "reasonable" applications > to succeed without needing operating-system specific code. I think it > should be possible to have an application like Mozilla run on top of the > cairo API.Well, depends what you mean by "an application like Mozilla". If you mean a application that does semi-sophisticated text layout and wants to print it", sure. If you mean "an application that can handle Arabic and Hindi and Thai and all the other languages of the world that anybody wants to display", then there are two routes: A) Give Cairo text processing skills at the level of Pango or Uniscribe; possibly driving away people who already have layout engines. Note that it also has to be able to run *on top of* Uniscribe and Apple''s text layout engines. B) Accept that Cairo is a piece in the solution not the whole thing, and that: - People who want a full layout engine need to to add that to their shopping cart. Luckily we''re talking free software here. - People writing a full layout engine need to go down and use platform specific pieces, and that if there is a platform X that has a special way of doing layout, then you I don''t think there is anything wrong with having an API at the approximate level of Xft in Cairo, but Mozilla has all sorts of ad-hoc FreeType and TrueType table access in it where it goes beyond Xft.> > This is an appealing choice, as long as the goals mentioned in my last > > mail are possible: consistent list of fonts with the system, and minimal > > overhead when not used. > > I believe we can map fontconfig patterns to windows font selection > structures. Some functionality may be lost; I don''t believe Windows has > any notion of language support in the font infrastructure.I''m not quite sure what the underlying mechanism is but the XP font selector knows the scripts supported for each font. You probably could also compute language coverage information and cache it much as we do with font files.> > Does this intermediate state of caring make sense? You shouldn''t get one > > rasterization if you "don''t care" or "really care", and a different > > rasterization if you "kind of care". > > Instead of ''kinda care''/''really care'', I should have said ''prefer portability''/ > ''prefer native fonts'' -- it''s a question of whether applications should be > forced to support win32 fonts when freetype could just as easily be > provided.I think there is room in the world for applications that use FreeType on Windows in certain niches. After all, Adobe doesn''t use the Microsoft rasterizers in their products. But it strikes me as something that users won''t want, in general, and application writers won''t want, in general. So, that, to me, means that sticking a choice in the application developer''s face is wrong. If someone really wants to get down and play with FreeType, I''m sure that the FreeType Cairo font support will compile for Win32 as well. And if Cairo allows replacing the font system at runtime, it will be easy to hook it up. But I think designing things so we are forced to make native Win32 fonts work well make sense. We don''t want to have a half-working set of Win32 stuff and then say "yeah, it''s not that good, you can use FreeType if you want, that works better, though it will look a bit different than the system fonts".... (Yes, Hans, you could with some justification say that''s how Pango works currently)> > What do you mean by an "abstract interface"? Do you mean a generic > > interface that goes beyond being useful for don''t-care applications? > > Yes. I don''t want to provide a complete interface that masks the > differences between FreeType and Win32. That seems like a bad plan...And quite possibly also an impossible plan. But I don''t think it''s necessary. Regards, Owen
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 pathThere are two other important operations: - convert a glyph to a path - embed glyphs in a postscript file Can I use Windows (or OS X) apis to get the outline of each glyph? If not, then I''m not sure how we can make cairo work in those environments without replacing the OS-specific font libraries with FreeType. I think we should consider os-specific font selection mechanisms though, with fontconfig used where appropriate. -keith
On Tue, Aug 12, 2003 at 01:13:25AM +0200, Hans Breuer wrote:> > - embed glyphs in a postscript file > > The funtion to use is GetFontData, but I''m not sure if this > (producing PS files) is really that useful on win32. Remember > there is already an almost working Device Context abstraction > in the platform for a long time.FWIW, having the option to produce PS files from a standard (i.e., "open source") driver is always nice. I find Windows printer drivers often buggy in subtle ways, and sometimes the only way to get around such problems is to produce a PS file and run it through Ghostscript. So the option for the user to bypass GDI printing actually looks useful to me. -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org> http://ada.dhs.org/~acli/
Around 14 o''clock on Aug 11, Owen Taylor wrote:> 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().One option is to always provide FreeType APIs (for portability) and then to add native APIs at some level to let people plug things in at this level. cairo_font_freetype_t cairo_font_freetype_create (FT_Font font); FT_Font cairo_font_freetype_ft_font (cairo_font_freetype_t cff); cairo_font_t cairo_font_from_freetype (cairo_font_freetype_t cff); cairo_font_win32_t cairo_font_win32_create (...); cairo_font_t cairo_font_from_win32 (cairo_font_win32_t cfw); then people could choose which they prefer. That leaves in question how to deal with fontconfig and the ''trivial'' APIs. One option is to map fontconfig patterns to native fonts inside cairo so that (by default) you''d get native fonts on every platform: cairo_font_freetypet cairo_font_freetype_create_from_pattern (FcPattern *pattern) cairo_font_win32_t cairo_font_win32_create_from_pattern (FcPattern *pattern) cairo_font_t cairo_font_create_from_pattern (FcPattern *pattern) Make cairo_font_create_from_pattern call one of the other two and return the casted result. Apps that "don''t care" can use the generic functions, apps that "kind of care" can use just the freetype functions while apps that "really care" can have conditional code that selects the correct code depending on the underlying operating system. What I want to avoid is attempting to provide an abstract interface on top of the underlying font system; that will just frustrate people and cause cairo to forever lag behind. -keith
Around 1 o''clock on Aug 12, Hans Breuer wrote:> The funtion to use is GetFontData, but I''m not sure if this (producing > PS files) is really that useful on win32. Remember there is already an > almost working Device Context abstraction in the platform for a > long time.True; I don''t know what kind of printing infrastructure cairo should use on Win32. I know we''ll still need to get font outlines to use internally, and that is essentially the same functionality that is required to embed glyphs in a PostScript file.> My main problem with fontconfig on win32 is perfectly described by > Owen in the previous mail. The only thing I like to add is that > I still doubt it''s useful to have two independent font rendering > machineries in one process - but if there is : they need to interact > sane, have the same names and properties for the same fonts, etc.If we can get the outlines from the native API, then we don''t need to use fontconfig/FreeType. But, we do need to figure out how to provide enough of an abstract interface for some level of application portability between the various operating systems. I don''t know how much we need here, but it would be nice to support layout-free applications like Mozilla at least. -keith
On Tue, 2003-07-29 at 23:36, Carl Worth wrote: [ I''ve cc''ed a couple of our Windows developers on this mail; Tor/Hans if you want to see the rest of this thread see http://cairographics.org/pipermail/cairo/2003-July/000273.html The issue here is font support for Cairo; which is likely to be the primary rendering API in future versions of GTK+. I''ve also Cc''ed fontconfig@fontconfig.org since this mail is largely about fontconfig; sorry for the wide distribution. ] [...]> So, I have two questions: > > fontconfig > ---------- > Does anyone have a problem with Cairo exporting fontconfig as > proposed? fontconfig is quite portable and I, (speaking as a user), > would love to have a standard cross-platform means for naming fonts, > etc.I don''t necessarily have a problem with using fontconfig on non-Unix systems, though I do have some concerns. - The set of fonts listed has to follow the system set of fonts pretty much exactly and automatically; any approach that requires separate user configuration of fontconfig isn''t going to work. - The end result of fontconfig pattern resolution is currently a filename. This doesn''t work on Windows, since you can''t use the system font API''s with a filename. So, that would need to more flexible. - It''s important to be able to go from: system representation of a font [LOGFONT on windows] => fontconfig pattern matching => fontconfig pattern result => rendering And get a result that is consistent with the rendering going through the system directly. Otherwise, things like matching the default system font won''t work. - There may be some concerns with interaction with interaction with system rendering API''s like Uniscribe and ATSUI - Thorsten may know better there. I think it probably does work out for Uniscribe; in Pango, we already put Pango font matching ahead of Uniscribe. But my understanding of ATSUI is that it is higher level; more "paragraph" based, and it may want to do font matching itself. You could say that you are only using fontconfig for the "toy api"'' and leave the low level API open, but the idea of requiring fontconfig for GTK+ on win32, then not using it, isn''t all that attractive...> Freetype > -------- > Does anyone have concrete suggestions for what API to push down into > Cairo in order to abstract away Freetype? If someone smart can > convince me to do that, and tell me how, I might be able to overcome > my laziness.My suggestion is that you don''t try to "abstract away FreeType" but rather you allow a font-system specific implementation of the Cairo toy API, which is going to be a much, much smaller API. The list of operations that I gave in my previous mail was meant to be (approximately) complete. For the toy API, you need: - Load a font from a name - Convert Unicode text to glyphs 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 And that''s all Cairo needs to know about the font system.> Or, another option is to give in to my laziness, not invent a new > interface, but declare that the Freetype API is good as is. With that, > we would just require the abstraction to happen below Cairo. That is, > if someone wants to use a non-Freetype renderer below Cairo, they > would have to write a Freetype-style wrapper above it for Cairo to use > and export. Does that make sense? Do such wrappers perhaps exist > already?No, I don''t think that makes sense: - The FreeType API is really large - The FreeType API is quit fluid; there are additions in almost every dot-release of FreeType. - The FreeType API is in not compatible with the font API''s on other operating system.. it is far too detailed; the only way to implement the FreeType API on windows would be basically to dump out the contents of each font table and run FreeType on that. Regards, Owen
On Mon, 2003-08-11 at 16:31, Keith Packard wrote:> Around 14 o''clock on Aug 11, Owen Taylor wrote: > > > 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(). > > One option is to always provide FreeType APIs (for portability) and then to > add native APIs at some level to let people plug things in at this level. > > cairo_font_freetype_t cairo_font_freetype_create (FT_Font font); > FT_Font cairo_font_freetype_ft_font (cairo_font_freetype_t cff); > cairo_font_t cairo_font_from_freetype (cairo_font_freetype_t cff);> cairo_font_win32_t cairo_font_win32_create (...); > cairo_font_t cairo_font_from_win32 (cairo_font_win32_t cfw);I don''t think even linking to FreeType on, say, Windows is right; for various reasons: - One more dependency that won''t be there normally - Inconsistent rendering between different apps - Having cairo_font_t be polymorphic on a single system is going to be confusing and lead to problems where people assume that a font *must* be a cairo_font_win32_t. It isn''t a bad idea to allow people to plug in a new font system on the fly if they are doing something really custom, but having two font systems always there is rather peculiar.> then people could choose which they prefer. That leaves in question how to > deal with fontconfig and the ''trivial'' APIs. One option is to map > fontconfig patterns to native fonts inside cairo so that (by default) you''d > get native fonts on every platform:This is an appealing choice, as long as the goals mentioned in my last mail are possible: consistent list of fonts with the system, and minimal overhead when not used.> cairo_font_freetypet cairo_font_freetype_create_from_pattern (FcPattern *pattern) > cairo_font_win32_t cairo_font_win32_create_from_pattern (FcPattern > *pattern) > cairo_font_t cairo_font_create_from_pattern (FcPattern *pattern) > > Make cairo_font_create_from_pattern call one of the other two and return > the casted result.Pango uses a factory setup that would look like: cairo_font_map_create_font_from_pattern (fontmap, pattern); I think this works a bit better in general.> Apps that "don''t care" can use the generic functions, apps that "kind of > care" can use just the freetype functions while apps that "really care" > can have conditional code that selects the correct code depending on the > underlying operating system.Does this intermediate state of caring make sense? You shouldn''t get one rasterization if you "don''t care" or "really care", and a different rasterization if you "kind of care".> What I want to avoid is attempting to provide an abstract interface on top > of the underlying font system; that will just frustrate people and cause > cairo to forever lag behind.What do you mean by an "abstract interface"? Do you mean a generic interface that goes beyond being useful for don''t-care applications? Regards, Owen
On Mon, 2003-08-11 at 19:13, Hans Breuer wrote:> >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 goal is that Cairo completely replaces the GDK rendering API, so that all rendering goes through it. For standard widgets, there may not be that big need for a better rendering API, but: - When you do need more powerful capabilities you''ll have them - We''ll be able to use the same drawing API for printing as for display to the screen - We share our cross-platform displaay code with a much broader set of users. GDI+, OpenGL, Postscript, etc, backends are all possible.> [ > The (only a little outdated) dependency stack is show at > http://hans.breuer.org/dia/dia-devel.htm404> 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.The idea is that with Cairo dia won''t have to have all it''s own code for drawing antialiased lines, zooming, etc. You''ll have a powerful, flexible drawing API already there for you.> ] > > 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) ?The problem is that Cairo as a rendering API is targetted at a wider audience of programs than those using Pango... while I wish Pango was the single universal solution to the worlds text rendering problems, it isn''t. The domain of use of Pango is basically just GTK+ applications. Cairo, among other things, is intended to replace the Xft library that is used for text drawing for both Qt and GTK+ currently on Unixlike platforms. "Leth them use Pango" isn''t going to work: - Pango text APIs require substantial rewriting of applications and couldn''t be easily dropped underneath, say, the Qt text APIs. - Cross-platform constraints on the text APIs for things like OpenOffice and Mozilla. They won''t be using Pango/Cairo everywhere. - Use of GLib/GObject is not popular> > 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.Yes, that''s what I was thinking of.> >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) ?cairo_font_win32_from_logfont() would be something that the Win32 backend of Pango would use to avoid having to convert a LOGFONT into a FontConfig pattern and then convert that back into a 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 > Currently it appears to me that it has to be integretable with > both : FreeType and the native rasterizer.My goal here is to get rid of the need for FreeType and have a rendering API that can use either it or the native rasterizer in a way that is transparent to GTK+ and to applications.>From history, I can''t imagine you objecting to that goal :-)> > - 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?I don''t really see any reason to stick fontconfig between EnumFontFamiliesEx and PangoWin32. I''m sure your 233 mhz notebook appreciates that. Regards, Owen
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 pathThat 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
Around 18 o''clock on Aug 11, Owen Taylor wrote:> I don''t think even linking to FreeType on, say, Windows is right; for > various reasons:Hmm. I''m thinking of applications that want to generate identical results on every system; using different font mechanisms makes that very difficult. One obvious such application is a cairo test suite...> - Having cairo_font_t be polymorphic on a single system is going > to be confusing and lead to problems where people assume that > a font *must* be a cairo_font_win32_t.Hmm. Perhaps we don''t need a ''cairo_font_win32_t''; all we really need is the ability to convert from an FcPattern to a windows font handle (HFONT?) or FT_Face.> It isn''t a bad idea to allow people to plug in a new font > system on the fly if they are doing something really custom, but > having two font systems always there is rather peculiar.Hmm. That means that cairo applications will only be portable if they use the trivial interface; those using lower level interfaces will need system specific code. I think this means we should build an intermediate interface that provides enough flexibility for "reasonable" applications to succeed without needing operating-system specific code. I think it should be possible to have an application like Mozilla run on top of the cairo API.> This is an appealing choice, as long as the goals mentioned in my last > mail are possible: consistent list of fonts with the system, and minimal > overhead when not used.I believe we can map fontconfig patterns to windows font selection structures. Some functionality may be lost; I don''t believe Windows has any notion of language support in the font infrastructure.> Does this intermediate state of caring make sense? You shouldn''t get one > rasterization if you "don''t care" or "really care", and a different > rasterization if you "kind of care".Instead of ''kinda care''/''really care'', I should have said ''prefer portability''/ ''prefer native fonts'' -- it''s a question of whether applications should be forced to support win32 fonts when freetype could just as easily be provided.> What do you mean by an "abstract interface"? Do you mean a generic > interface that goes beyond being useful for don''t-care applications?Yes. I don''t want to provide a complete interface that masks the differences between FreeType and Win32. That seems like a bad plan... -keith
On Mon, 2003-08-11 at 19:13, Hans Breuer wrote:> At 09:24 11.08.03 -0700, 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 > The function to use on win32 is GetGlyphOutline. I''m discussing how > it could be used to make gtk-win32 apps more independent of direct > Freetype usage in http://bugzilla.gnome.org/show_bug.cgi?id=107668 > > > - embed glyphs in a postscript file > The funtion to use is GetFontData, but I''m not sure if this (producing > PS files) is really that useful on win32. Remember there is already an > almost working Device Context abstraction in the platform for a > long time. > > With it you are not forced to use (expensive) Postscript printers or > an external program like Ghostcript, but can simply use almost the > same code to render to display or _any_ printer (with a windoze > driver) even those ugly GDI only printers which put the burden > completely on the PC side. > > There is some code of mine which does use it in dia/plug-ins/wmf/wm.cpp > and dia/app/paginate_gdiprint.cpp both in GNOME cvs.It''s pretty clear to me that writing the printing backends for Cairo is going to be one of the most challenging part, whether it''s the PS background or using GDI to do printing. When rendering to the screen, we have a number of things going for us: - The number of pixels is pretty low and the bandwidth is high so if we have to fall back and do stuff as images, we can do so. - We know the exact output resolution. - We can get the pixels back if necessary. None of this works for a printer. Depending on the version of Postscript and GDI, one may have a few more features than the other, but neither is going to be able to handle the full capabilities of Cairo. (Even with GDI+, the details of Alpha compositing modes, etc, are different.) Probably Cairo will just have to fall back to sending low resolution bitmaps of the output to the printer in such cases. Regards, Owen P.S. - I don''t think that GS being a separate process really has anything to do with current deficiencies of printing on Linux; which are mostly a question of getting nice print setup dialogs. Spooling to metafiles to allow the printer to keep on printing after the app exits is, as I seem to recall, a pretty common thing to do on Windows.
Around 23 o''clock on Aug 11, Owen Taylor wrote:> I guess I''m pretty set on an OO mindset these days. :-) I definitely > see "a few extra win32 methods" as being inheritance rather than just > some extra code we compile in on Windows.Ok, so I guess the plan should be to always expose the native fonts as the "normal" API; you get cairo_font_win32 functions on the Win32 version of cairo and cairo_font_freetype functions in the Linux version of cairo. Code which can''t deal with that isn''t portable. I can live with that, especially if we can provide the FreeType functions in Win32 as a bag-on-the side separate library for weird apps that want it.> I''d tend to say that if we are going to have multiple font > implementations, especially on the same platform, but even if not > on the same platform, virtualization makes a lot more sense than a > bunch of #ifdef''s and switches.Certainly there should be abstract datatypes which are independent of the underlying font system; otherwise we''ll all go insane. The question is how much functionality should exist at that level. I''d like to make sure enough exists so that most of the output code can be system independent, even if the fancy font selection and layout code is heavily system dependent.> If you mean "an application that can handle Arabic and Hindi and Thai > and all the other languages of the world that anybody wants to display", > then there are two routes:No, I plan on leaving cairo at the glyph level; anything else is clearly a bad idea at this point. When layout libraries are better defined, we may be able to standardize on a single one on top of cairo, but that''s not the right thing to do at this point. I guess I''d like to see the actual rendering code able to use system-independent functions; once the fonts and glyphs are selected and positioned, it would be nice to have everything else use just cairo_font_t. It would also be nice to provide system independent functions to deal with font selection, but I''m not sure that''s a great plan given the differences between the various systems. Perhaps we really do just want a cairo_freetype and cairo_win32 library for all of that and force applications to choose which underlying font selection mechanism is to be used.> I don''t think there is anything wrong with having an API at the > approximate level of Xft in Cairo, but Mozilla has all sorts of > ad-hoc FreeType and TrueType table access in it where it goes beyond > XftYeah, Xft is about the highest level I''d consider doing; something that takes unicode and maps each codepoint to a single glyph and sticks them adjacent on the screen.> I''m not quite sure what the underlying mechanism is but the XP font > selector knows the scripts supported for each font.I wouldn''t be surprised if it was just using the OS/2 codepage range bits.> You probably could also compute language coverage information and cache it > much as we do with font files.I''d rather just bail on fontconfig for win32 and make you suffer there by providing cairo functions that took preselected win32 fonts instead. Having us design a Win32 API seems like a really bad idea...> And if Cairo allows replacing the font system at runtime, it will be easy > to hook it up.We''ll have to be careful in designing the internal interfaces that implement font stuff so that we can plug in separate datatypes and have them work, but I don''t think it''s impossible. Stick the FreeType stuff in a separate library and just make applications link against it explicitly. We could do the same with the Win32 font stuff; that way the core cairo library would be the same and the differences would be isolated to external libraries. I think we''re converging on a reasonable direction here; don''t pretend to be os-independent when applications are explicitly interested in os dependence. -keith
At 19:56 11.08.03 -0400, Owen Taylor wrote:>On Mon, 2003-08-11 at 19:13, Hans Breuer wrote: > >> >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 goal is that Cairo completely replaces the GDK rendering API, >so that all rendering goes through it. For standard widgets, >there may not be that big need for a better rendering API, >but: > > - When you do need more powerful capabilities you''ll have them > - We''ll be able to use the same drawing API for printing > as for display to the screen > - We share our cross-platform displaay code with a much broader > set of users. GDI+, OpenGL, Postscript, etc, backends are > all possible. >This would mean to write Cairo backends based on GDI+ (which IMO is only a half baked C++/C# wrapper around GDI), OpenGL etc. And almost throw away all the current Gdk backends ? Still the question arises what would be the benefit for cross platform application developers to use Cairo instead of the current implementations?>> [ >> The (only a little outdated) dependency stack is show at >> http://hans.breuer.org/dia/dia-devel.htm > >404 >Yeah, I shouldn''t assume my local tree is in sync with the public one. Now fixed.>> 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. > >The idea is that with Cairo dia won''t have to have all it''s >own code for drawing antialiased lines, zooming, etc. You''ll >have a powerful, flexible drawing API already there for >you.Given the number of current output facilities of Dia (gdk, libart, svg, wmf, hpgl, gdi to printer (via wmf), two PostScript - one with embedded outlines, xfig, cgm, dxf, wpg) this would either mean to write a bunch of new backends for Cairo or keep much of Dia''s rendering code around.>> ] >> >> 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) ? > >The problem is that Cairo as a rendering API is targetted at >a wider audience of programs than those using Pango... while >I wish Pango was the single universal solution to the worlds >text rendering problems, it isn''t. The domain of use of >Pango is basically just GTK+ applications. >I still fail to see how Pango and Cairo should play together. If both do their own independent name to font mapping things will get worse than now in respect to applications which try to have cross platform file interchangeability. One of the font related problems of Dia is that the diagram layout depends on the correct font sizes (string width is more important than height here). It was a mess in the pre Pango time - where the win32 fonts were mapped through gdk_font_list_new() which emulated xlfd font names to be compatible with XListFonts usage. Though IIRC the mess was bigger on X11 based Dia with Xft on display and trying to map that to PostScript names.>Cairo, among other things, is intended to replace the Xft library >that is used for text drawing for both Qt and GTK+ currently >on Unixlike platforms. > >"Leth them use Pango" isn''t going to work: > > - Pango text APIs require substantial rewriting of applications > and couldn''t be easily dropped underneath, say, the Qt > text APIs. > - Cross-platform constraints on the text APIs for things > like OpenOffice and Mozilla. They won''t be using > Pango/Cairo everywhere. > - Use of GLib/GObject is not popular >Yeah, it appears to be more popular to solve the same problems (here : X11 and other OS''s graphic subsystem design clashes) over and over again ... [...]>> >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 >> > - Integranjhmtes 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. > >My goal here is to get rid of the need for FreeType and have a >rendering API that can use either it or the native rasterizer >in a way that is transparent to GTK+ and to applications. > >>From history, I can''t imagine you objecting to that goal :-) >My goal is not to get rid of FreeType but to only use it if it really needs to be used. If there can be a generic api in Pango to abstract away the backend specifics (implement such simple things as rendering to a bitmap or getting the glyph outlines) I''d much prefer to implement such instead of having the same (or similar) platform specific code in all applications which need them - or worse : being forced to use two font rendering machines with huge overlap in capabilities but independent configurations in one application. But to me this looks like a small gap in the current Pango api which can and should be fixed to become historical ;-)>> > - 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? > >I don''t really see any reason to stick fontconfig between >EnumFontFamiliesEx and PangoWin32. I''m sure your 233 mhz notebook >appreciates that. >What I meant was : there should be only one master list of available fonts presented to the application. This one could be provided by a win32 specific fontconfig. If there is more than one such list the mapping between font description and real font will get out of sync sooner or later an impose the same problem as with two font rasterizers with independent configurations. Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I''ll tell you how to get along without it. -- Dilbert
Around 23 o''clock on Aug 11, Owen Taylor wrote:> None of this works for a printer. Depending on the version of Postscript > and GDI, one may have a few more features than the other, but neither > is going to be able to handle the full capabilities of Cairo. > (Even with GDI+, the details of Alpha compositing modes, etc, are > different.)As a first cut, my plan was to simultaneously generate postscript output and render to a page-sized image at printer resolution (mondo huge). Areas which PostScript could acurately render would be drawn with postscript, other areas would be sent as huge images. Optimizing that to avoid the huge buffer by saving data in some metafile format might be generally useful, both to avoid the giant pixmap unless necessary and also to permit striping of the output. Hmm. We could specify a metafile format and require a post-processing stage to convert that for the printer. In the best of all possible worlds, that format could be PDF... -ketih
On Sat, 2003-08-16 at 04:25, Hans Breuer wrote:> >> 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) ? > > > >The problem is that Cairo as a rendering API is targetted at > >a wider audience of programs than those using Pango... while > >I wish Pango was the single universal solution to the worlds > >text rendering problems, it isn''t. The domain of use of > >Pango is basically just GTK+ applications. > > > I still fail to see how Pango and Cairo should play together. > If both do their own independent name to font mapping things > will get worse than now in respect to applications which try > to have cross platform file interchangeability.How can that be? We''re not generally worried about compatibility between application A on platform X and application B on platform Y - and we could only solve *that* problem if all apps switched to using Cairo+Pango+fontconfig. What we are interested in is application A on platform X application A on platform Y Currently it is PangoWin32 vs. PangoXft/fontconfig. With what I was proprosing it will be PangoCairo/Win32 vs. PangoCairo/fontconfig. So, it will be pretty much the same as before. Really, font name => font mapping isn''t the problem. If you have a font called Arial Bold, it doesn''t take much work to find it. The problem is when you *don''t* have the same font.> One of the font related problems of Dia is that the diagram > layout depends on the correct font sizes (string width is more > important than height here). > It was a mess in the pre Pango time - where the win32 fonts were > mapped through gdk_font_list_new() which emulated xlfd font names > to be compatible with XListFonts usage. > Though IIRC the mess was bigger on X11 based Dia with Xft on > display and trying to map that to PostScript names.If you don''t have the same fonts, it''s inevitably going to be a mess. You can try to do CSS2-style font synthesis to match metrics, but I don''t think it''s a terribly good idea. If you do have the same fonts, I doubt there will be much of a problem. If you store the Pango names in the Dia file, you should be able to find the same font on any platform. [...]> >> >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 > >> > - Integranjhmtes 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. > > > >My goal here is to get rid of the need for FreeType and have a > >rendering API that can use either it or the native rasterizer > >in a way that is transparent to GTK+ and to applications. > > > >>From history, I can''t imagine you objecting to that goal :-) > > > My goal is not to get rid of FreeType but to only use it if it > really needs to be used. If there can be a generic api in Pango > to abstract away the backend specifics (implement such simple > things as rendering to a bitmap or getting the glyph outlines) > I''d much prefer to implement such instead of having the same > (or similar) platform specific code in all applications which > need them - or worse : being forced to use two font rendering > machines with huge overlap in capabilities but independent > configurations in one application. > > But to me this looks like a small gap in the current Pango api > which can and should be fixed to become historical ;-)Basically, what you are asking me for is to add a simple rendering API to Pango. I don''t think this is ever going to be as workable as having a more powerful rendering API (Cairo) that can be used cross-platform, and that supports operations like rendering to a local bitmap well.> >> > - 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? > > > >I don''t really see any reason to stick fontconfig between > >EnumFontFamiliesEx and PangoWin32. I''m sure your 233 mhz notebook > >appreciates that. > > > What I meant was : there should be only one master list of available > fonts presented to the application. This one could be provided by > a win32 specific fontconfig. > If there is more than one such list the mapping between font description > and real font will get out of sync sooner or later an impose the > same problem as with two font rasterizers with independent configurations.There would only one mapping ever used by Dia on Win32, the mapping used by the Cairo backend of Pango on Win32. Whether that mapping uses fontconfig/Win32 or a separate win32-specific codebase like the current PangoWin32 backend is, from Dia''s point of view, a detail. However, using a separate codebase that sticks as closely to the Windows API as possible seems to have advantages for: - Consistency of rendering between GTK+-based and non-GTK+ based applications - Getting the right fonts for the right scripts when calling Uniscribe. - Avoiding extra unnecessary overhead. Even with a great deal of optimization, fontconfig takes up 100k or so for the font database, per app. Regards, Owen