Hello strk, Friday, June 15, 2007, 8:22:14 PM, you wrote: s> I guess precision of placement is a separate issue, due to the s> possibly different metrics found in systems and different fonts s> being used (font name to actual font filenames matching)
I meant that we could use the standard OS functions to render device fonts. After all, use of device fonts is very restricted in PP: o _alpha is ignored o _rotation != 0 hides the text field completely o _xscale != 100 changes the size of the bounding box, but not the font o _yscale != 100 scales the font proportionally in *both* directions o matrix transformations like skew make the text field disappear too So we have very few requirements for device fonts. s> Uh ? I think I used the same rules used for embedded glyhps. The s> only difference being the way we create the paths (SWF-defined for s> embedded, gnash-defined for OS fonts) which is where I belive OGL s> fails (it's known to fail with some of our drawing API tests too). When you look at the AGG code you'll notice that it uses non-zero filling rule for fonts but even-odd filling rule for other shapes. That makes a difference for paths that cross other paths, like some fonts do. Udo _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
