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
