DD> Unless the old Type1 backend can unreservedly be replaced by the new
DD> FreeType2 backend, then it should be disabled, and maybe even a "fake"
DD> type1 font module created for the modular build so that existing
DD> configurations don't break. If there are still reasons for wanting the
DD> old backend, then it needs to be configurable, at least at build-time.
DD> If we want to provide more flexibility in allowing the user to control
DD> what font suffixes are handled by what backend, there would need to be
DD> some type of run-time configurability.
I was looking into that when other things came up; I may very well be
able to come back to this. Anyway, here's the plan I had.
The idea would be to have a new interface,
Bool FontFileRegisterRendererPriority(FontRendererPtr, int priority)
where the existing FontFileRegisterRenderer interface in renderer.c is
an alias for FFRRP with priority set to 0. Priority is an integer
(positive or negative), and renderers with higher priority override
renderers of lower priority.
The Type 1 renderer would register with negative priority for both PFA
and CID; in the absence of another CID renderer, it would render CID
fonts, but PFA fonts would be handled by FreeType. FreeType would
register with default priority for both PFA and TTF. X-TT would
register with positivie priority for TTF.
In a configuration in which all renderers are linked in, X-TT would
handle TTF, FreeType would handle PFA, and Type 1 would handle CID.
In a default configuration (no X-TT), both PFA and TTF are handled by
FreeType.
The advantage of that is that there are no new configuration
mechanisms -- we simply leverage off the existing module loader. It's
also easily extensible -- I expect to implement bitmap support in the
FreeType backend after 4.3.0, and then you'll want the existing bitmap
renderers to override FreeType if they're linked in.
The downside is that it's not completely flexible, not allowing for
example to have TTF support using FreeType while using Type 1 for PFA.
I don't think anyone cares.
DD> Also, I'd really like to see some resolution to the separate "FreeType"
DD> and "X-TT" backends for TrueType fonts. As it is now, if someone chooses
DD> "X-TT", they will still need the old Type1 backend for Type1 fonts
DD> regardless of other considerations. Is it still not possible to resolve
DD> the issues that led to two TrueType backends in the first place?
Here's my personal perception.
X-TT contains support for embedded bitmaps, which FreeType 1 didn't
have. The new FreeType backend fully supports embedded bitmaps.
X-TT also contains a number of features such as fake bolding and
automagic slanting, collectively known as TTCap. These should be
handled at the toolkit level in my opinion, and at any rate
implementing new features in the core fonts system at this point is
pretty much pointless. Still, users of X-TT have become accustomed to
these features being made available at the server level, and would
probably not accept them being taken away.
I shall not implement the said features in FreeType, which I want to
remain a small and clean piece of code. I shall also not integrate
myself the (existing) patches that implement TTCap in the FreeType
backend.
If there is a person interested in doing that, I'll be glad to help --
but only if said person commits to maintaining the code for the
indefinite future.
Juliusz
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
