Re: [Gnash-dev] device fonts

[strk]

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;