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
