[Fontconfig] A question about font styles

Owen Taylor otaylor at redhat.com
Tue Mar 8 10:11:10 EST 2005


On Mon, 2005-03-07 at 18:03 -0500, Ambrose Li wrote:
> On Mon, Mar 07, 2005 at 05:26:58PM -0500, Owen Taylor wrote:
> > > 	4)	Attempt to merge face name and style/weight values
> > > 		(so a face name of 'black' and a style of 'italic' would
> > > 		yield a black italic font).
> > > 
> > > 4) seems likely to be fragile and cause weird effects when faced with 
> > > unusual fonts.  of 1) and 2), I suggest that 1) is a better choice as your 
> > > abstractions may never capture all of the possible variations (outline 
> > > anyone?) present in the 'face name'.  So, that leaves 3).  I think it's a 
> > > poor choice as it makes the face_name="italic", weight="bold" case very 
> > > confusing, and leaves us with an imperative spec rather than a declarative 
> > > one.
> > 
> > Well, I still haven't changed my opinion away from:
> > 
> >  5) Don't add "face name", do whatever munging on fontconfig output
> >     is necessary to create artificial family names.
> 
> Actually I am not sure what the difference between (4) and (5) really is.
> 
> Option (4) tries to come up with a combined font name that describes
> all its attributes. Then use this artificial font name (which includes
> the original attributes) to do font selection.

The difference between 4 and 5 is that with 5 I don't have to add a
confusing, duplicative, extra entry to PangoFontDescription.

(And also consequently, if we implemented things that way, current
Pango/GTK+ programs would be fixed, rather than it taking effect
in the future as programs are updated to use a new API.)

> Option (5) tries to subtract things from the face name until it comes
> up with a probable family name, and if that fails do further munging.
> We then create artificial attributes from any leftover from the original
> name. Then we use the artificial family name, together with the original
> plus artificial attributes, to do font selection.
> 
> Is the above understanding correct? If it is, (5) sounds even more
> fragile than (4); if not, I don't understand how the two differ...

There are multiple ways that 5 could be implemented. I don't think it
would be particularly fragile. Without fontconfig support, it might
be particularly slow.

Regards,
						Owen





More information about the Fontconfig mailing list