This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: More on font matching
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
After my experience with Matching under X11, I was ready to find a better solution. Michael Lucas Smith had told me he liked the CSS one, so I thought I'd take a look. It was an OK read if you find the quagmire known as fonts and our continuous thrashing to get something that works entertaining. I had hoped to find a slam dunk solution, something that we could implement in Smalltalk and suplant the existing stuff.
I was both encouraged and dissapointed. It was not the silver bullet I was hoping to find. But there was some interesting things. Here were my thoughts.
XPlatform
Supposedly, the CSS spec is XPlatform. Just like VisualWorks. Like VisualWorks, I was impressed that it was more of "it's own platform". There's this magic thing referred to over and over again as the "font database". The spec doesn't help you there. Its where you have to come up with all of this information that the spec wants. The problem (IMO) is that some of this is difficult information to infer from a real platform's font database. Things like SmallCaps. And some of the size information.
Serif-edness
VisualWorks attempts to establish a font's serif-edness, so that you can specifiy serif as something you want. In truth, this is probably better done as a 0.0-1.0 weight, rather than a boolean. But it is there. The CSS spec does nothing for this. I was surprised. This kind of attribute seems kind of important. But then, I look at the dumb solution VW has to supplying this information, and I'm torn. Maybe it's better just left as an secondary attribute, embodied only at the whim of whoever actually names the font.
Fixed Width
The CSS spec does not establish fixed vs proportional width as an attribute. I consider this a shortcoming. It's right there in the X font description (don't know what other platforms do). But there are applications where you want to specify a fixed width font instead of a proportional one. In a VW scheme rewrite, I'd want to add this over and above the CSS stuff. The CSS spec is similiar to VW in being able to specifiy the proportionality of proportional fonts (e.g. condensed, narrow, wide, etc).
SmallCaps
This was interesting. You can specify an attribute which means that the lowercase character cells, are still uppercase, but of smaller size. And it then talks about synthesizing these and so on. Interesting. But IMO, kind of out of place. I could come up with all kinds of cute attribtues and put them alongside the more canonical.
Sizes
This is where the CSS spec has a lot of specification. You can specify/match not only the size of your fonts, but the aspect ratio of lowercase-to-uppercase. And the baseline. And everyother vertical font metric ever dreamed up. I kind of liked this stuff, though I think in practice most application programmers would not bother with it. This information is not found in the X11 14 part font name, but with a font loaded, it is available. For VW to do this, it would have to augment the descriptions after the font was loaded.
Unicode Range
This part I really liked. The jst was basically, that the font renderer matches each character against the current matches range. And if the range is exceeded, it rematches. This is not how VW is done today, but it would be really cool if the Character/DisplayScanner DID do this. Then you could specify the blue book assignment arrow (16r2091 I think), and when it hit this character cell, it would rematch a font that could display that code point. This is something that would be really cool at the VW level.
Style
VW does the italic thing. CSS goes one up, and provides an oblique attribute as well. I'm not sure I saw the real value of it, even though I think I understood the technical distinction between italic and oblique.
Matching
The CSS spec is not super spelled out. It's just a vague outline of procedure at the bottom of the spec. But I do like it better. Rather than a weighted voting mechanism, it seems to favor a pecking order of attributes. IOW, you look for a match on the attribute X first. Within that domain, you try to match the next most important attribute. If this was what was used in VisualWorks... I'd not have had the problems I did with matching my FreeSans font. The mechanism is simpler to understand, debug, and extend.
Previous Topic
