Re: Pango global font aliases

[Keith Packard <keithp keithp com>]

This is a multipart MIME message.

Around 15 o'clock on Sep 8, Alex Larsson wrote:

> Currently some pango backend has some own magic for doing aliases, and 
> some doesn't support any, and some of it is handled in the generic code.

Oddly, we're having the same discussion on fonts and i18n @xfree86.org -- 
right now Xft has an aliasing mechanism, but that leaves printing out of 
the loop.

I think xfree86 is a reasonable place to do this design; it's very 
important that all X applications share font configuration.  However, it's 
also important that printing backends play as well, which drags in a lot 
of other groups.  I'm hoping to attend the printing summit in a couple of 
weeks in CA, but don't know if I'll make it.

The current Xft matching mechanism works pretty well, but the 
configuration syntax is way too complicated, and yet still manages to be 
broken.  I've attached a message I sent to fonts xfree86 org with some
thoughts I had.

-keith

--- Begin Message ---

• From: Keith Packard <keithp keithp com>
• To: fonts xfree86 org
• Cc: keithp keithp com
• Subject: Redoing Xft internals
• Date: Sun, 02 Sep 2001 10:37:02 -0700

It's time to reconsider how Xft is structured to solve some of the 
problems we've uncovered so far.  The current (obvious) problems are:

	1)	Baroque configuration language
	2)	X specific font matching/configuration

Providing an output-device neutral font matching/configuration mechanism 
should allow fonts to be shared among the display and printer.  Here's the 
division of tasks I envision:

	Xft:		connect Freetype rasterizer with X render extension
			Also provides core X emulation if necessary
	Freetype:	Access font files and rasterize glyphs
			Provides complete API for advanced font features
new	fontmatch:	Font naming, matching and configuration
			Independent of underlying font rasterizer
	Pango:		Text layout and rendering

Pango would then use fontmatch to select fonts, Xft to draw glyphs on the 
screen and Freetype to directly access low-level font details.

I envision fontmatch using the existing XftPattern structure (with a new
name); Xft would provide wrappers that took those patterns and created
objects suitable for X rasterization.  Fontmatch would use a completely 
new configuration mechanism suitable for mechanical editing and GUI-based 
configuration tools.

The configuration language must have the ability to do two separate 
things.  First, it must provide for face aliases that precede matching.  
Second, it must allow changes to how fonts are displayed that are applied 
after a match is made.  Those changes include selecting anti-aliasing and
artificial obliquing.  I'm sure there are other things we'll need to do; 
suggestions are welcome.  

One thing from Xft that I think is useful is the ability to edit the face
list to prepend/append face names -- this allows the configuration to
prefer one face to another without eliminating the ability to use the other
face.

Are there other pre-match changes that anyone thinks useful?  Things like 
style-substitution should be handled already by the matching system.

keithp keithp com	 XFree86 Core Team		SuSE, Inc.

--- End Message ---