On Sat, Jun 16, 2007 at 01:20:40AM +0200, Udo Giacomozzi wrote: > 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.
I saw AGG supports freetype, so I guess that's where you'd like to go ;) Doing so would likely need support in the GUI, so callbacks from the libserver (or libbackend) into libgui. Dunno if I'd like such a big redesign. > 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 Yes, I noticed too. Don't we want to do better than that ? :) > 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. I see. Can you find an example in which AGG fails rendering OS fonts ? If not, maybe we found the bug in OGL ? --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
