Maybe you've beat me to it. I compared the output of ttedit on windows to pfaedit on linux linked against freetype-2.1.2. The first attached image is of the embedded bitmap letter k for pfaedit, the latter for pfa-edit.
The pfa-edit version has the right cutoff of the bitmap two pixels farther in than the ttedit version. I assume whatever is causing this difference is what is responsible for the "bunching". This 'bug' has been around since much earlier versions of freetype. (I don't remeber if xtt has the same behaviour) On another (perhaps related) note, as I was running pfaedit on this font, many of the characters came up completely garbled. Looks like its looking at the wrong area of memory. Didn't bother taking a shot of that but can provide one if anyone is interested. Thanks, Ken > KP> The glyph spacing is set as a part of each embedded glyph image; > > Calls for a fontconfig option to use the scalable spacing for embedded > bitmaps? DPS used to have that. > > (Actually, if memory serves, it was a three-state switch: use bitmap > metrics, use scalable metrics, and use bitmap metrics with retouching > in order to get scalable metrics on average. How they did that in a > procedural API is beyond me.) > > KP> it appears that the font you're using is just broken. I beleve > KP> you can probably use pfaedit to both verify this and even fix it. > > Current pfaedit will drop the instructions (hints). > > Juliusz > _______________________________________________ > Fonts mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/fonts >
<<attachment: pfa-edit-k-14pix.png>>
<<attachment: ttedit-k-14pix.png>>
