Re: New release of libart/freetype-backend

[Adam Fedor]

Alexander Malmberg wrote:
> GSSet(Stroke,Fill)(Color,Colorspace)
> aren't implemented since I don't know what they're supposed to do. None
> of the other backends implement them, and gui never uses them. Why do
> they exist?

That's for Quartz compatibilty. Quartz defines different colors for 
stroking and filling, mostly for convienience I suppose. Also see some 
of the GS functions in the Text section. I think some of this can be 
implemented in gsc, but I haven't gotten around to it yet.


> c.
> What exactly am I supposed to do about view flipping? Does it belong in
> the backend at all? Currently I just flip the y axis when drawing text
> if viewIsFlipped is YES, and this seems to work.

I've always thought that was a big hack, but I'm not sure how to remove 
it. But yes, that's pretty much what you're supposed to do.


> d.
> How sophisticated should my font rendering be? Should I do kerning and
> stuff in DPSshow:?
>
> e.
> To get good unicode coverage with all fonts, I've implemented a simple
> fallback-font scheme. If a glyph can't be found for a character in the
> current font, it will try to find it in the global fallback font and
> render that instead. I'm considering extending this, but I'm not sure
> it's the right thing to do. Should the backend try to always find a
> glyph for a character (with different fallback fonts for different fonts
> and stuff like that), or should it leave all that to -gui?

Well my current grand scheme ;-) is to have gui use Pango for text 
layout and rendering. The more I look at it the more it seems to fit 
right in and solve many many problems. Pango would do all this stuff.



--
Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, because
http://www.doc.com                    | if I didn't, I'd eat it, and you
                                      | know how I hate the stuff.