Keith Packard a �crit : > > Around 9 o'clock on Feb 21, David Turner wrote: > > > - in order to create an abstract "glyph array" whose role is to: > > > > * provide an array of font/glyph indices > > > > * provide for each glyph its position in _device-independent_ > > coordinates > > > > * provide a way to map glyph <->characters with the "glyph array" > > I'm surprised the underlying layout engine generates device-independent > positions; the metrics of the glyphs are sometimes greatly affected by > hinting; it seems likely that these relative glyph positions will have > visible errors on low-resolution devices. >
For the _abstract_ glyph array, using device-independent coordinates is the _only_ way to get coherent results between several displays or even prints with distinct resolutions. Think about justification algorithms in WYSIWIG text editors/processors. The OpenType Layout table 'JSFT' also requires device-independent coordinates to work properly.. Of course, the tricky part is that the OpenType specification also specifies device-specific adjustments (for example, raw pixel offsets during certain glyph positioning operations, or even shifts based on the distance between two hinted control points in a pair of glyphs !!). What this means is that the _abstract_ glyph array, while providing device-independent coordinates, will also embed (hide) some relatively complex information about the device-specific operations that may apply to the laid-out text as well. This information may be used to create the "display glyph list" and the "print glyph list", etc.. Typically, the "display processor" will not only adjust the glyph images but their pixel positions too (eventually using the info hidden in the abstract glyph list). A simple algorithm is to lay out glyphs in a word according to their hinted/adjusted advances, then modify the inter-word spacing in order to match the correct total line width in pixels. If this isn't enough (i.e. when they aren't enough spaces or words), you can also start changing the inter-letter spacing or even "scale" the character pixel width. I believe that Acrobat Reader does that with multi-master fonts sometimes.. In all cases, scaling and rounding the device-independent position of each glyph is out of the question, since this creates truly bad results if you don't use sub-pixel positioning (read: un-hinted glyphs like Nautilus or Mac OS X). As I said, that's a pretty complex algorithm if you want to do things correctly.. There is no doubt that many kinds of approximation will work as well in 80% cases, it's the last 20% that are tricky.. > > As an example, the latest version of "libXft" does work with any X server, > > but only provides anti-aliased text if the "Render" extension is provided. > > This should help migrate legacy applications to the new model rather > > easily (and transparently to users..) > > Actually, can provide equivalent rendering capabilities on any server with > a 'TrueColor' visual; it's just a *lot* slower than using the Render > extension, especially when running over a network. Of course it's > configurable so that you can use non-AA text when desired for better > performance. > I didn't know that this version did also implement AA-text. I imagined that it only provided monochrome text. Congratulations :o) - David Turner _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
