On Fri, 2003-09-05 at 00:32, David Chester wrote:> Hello, > > I have a submitted a patch to freetype which improves kerning in the > autohinter. Here are my posts on freetype''s devel list: > > http://www.freetype.org/pipermail/devel/2003-July/009545.html > http://www.freetype.org/pipermail/devel/2003-July/009559.html > > At this time the McGill site which hosts the example images seems to be > down, but I put up the second graphic at: > > http://chesterandvestal.ath.cx:8000/kern2.png > > Basically, errors from rounding the advance widths are remembered and > accounted for during layout, one level up (i.e. in Xft or ftstring, etc.). > In the > posts above, I attached a patch which makes ftstring (from the ft2demos > package) able to take these errors into account. However, I am unfamiliar > with > the Xft code, and I am wondering how this might be implemented in Xft. > > The patch has not yet been accepted, and it may eventually have a very > different implementation in the end, but it would be useful to know exactly > how > this would work with Xft.I''ve fooled around a bit with similar things for Pango recently - see the draft of a writeup at: http://people.redhat.com/otaylor/grid-fitting/ In particular the section called "Reducing the deviation: grid-fit kerning". I didn''t modify FreeType for the experiments I did there, but simply figured out the side-bearing errors by comparing the unhinted outline bounding box and metrics to the hinted outline bounding box and metrics. When you get an API into FreeType, making Pango support it will be pretty easy; Xft support wont be necessary, since Pango does all glyph positioning itself and just feeds Xft the positioned string. Regards, Owen
Around 6 o''clock on Sep 5, David Chester wrote:> Basically, errors from rounding the advance widths are remembered and > accounted for during layout, one level up (i.e. in Xft or ftstring, etc.).Xft is designed as a relatively primitive API for placing glyphs; the higher level text layout functions are the likely candidates for adjusting the position of glyphs based on their unscaled metrics. What Xft could do, however, is offer fixed-point widths computed from the unscaled metrics for applications to use in adjusting text as appropriate. It''s not really feasible for Xft to implement this internally as it isn''t necessarily given the whole string to draw; results which differ when drawing a sub-string will generate visible artifacts on the screen. The "right" place for this patch is in Qt, Pango, Mozilla, and other text layout systems. Perhaps someday we can standardize on one layout mechanism, but there are still a wide range of ideas about how such a system should work, so it would be premature to pick one. -keith
Hello, I have a submitted a patch to freetype which improves kerning in the autohinter. ?Here are my posts on freetype''s devel list: http://www.freetype.org/pipermail/devel/2003-July/009545.html http://www.freetype.org/pipermail/devel/2003-July/009559.html At this time the McGill site which hosts the example images seems to be down, but I put up the second graphic at: http://chesterandvestal.ath.cx:8000/kern2.png Basically, errors from rounding the advance widths are remembered and accounted for during layout, one level up (i.e. in Xft or ftstring, etc.). ?In the posts above, I attached a patch which makes ftstring (from the ft2demos package) able to take these errors into account. ?However, I am unfamiliar with the Xft code, and I am wondering how this might be implemented in Xft. ??? The patch has not yet been accepted, and it may eventually have a very different implementation in the end, but it would be useful to know exactly how this would work with Xft. Thanks very much. David Chester -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualit?tssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post