Re: New GTK+ anti-aliasing patch posted



One last thing (or two).  Selecting text that is anti-aliased in any gtk
app will instantly change it to non-antialiased font and then the spacing
gets really weird as you try to hilight a block.  In mozilla, which of
course bypasses the Xft thing, hilighting really messes up the spacing.
It has to be a byproduct of this patch and related to the general
text selection rendering problem I've described.

One more thing that's gtk's fault is that labels on frames are simply
alpha-blended against the background, rather than having an opaque
background which makes the frame border go through the label.  It's an
obvious effect when you look at the theme selector in the control panel.
Not a biggy, but it will have to be addressed by GTK itself sometime.

Michael


On 14 Mar 2001, Bryan O'Sullivan wrote:

> m> Okay, it works now.  Thanks very much.  There's a few odd things,
> m> though.  My gtk default font is set to helvetica, 12 pt.  It came
> m> out using some other serif font, at a much smaller size, even
> m> though it claimed to be helvetica.  This caused, for some reason,
> m> my gnome control panel to be 2000 pixels wide.
>
> For some reason, the Xft call I use will always succeed on loading
> nonexistant fonts; it just substitutes a weird-looking broken font
> with bad bearing metrics instead.  The result is that some kinds of
> windows render at huge widths.
>
> I'll look into this, and try to get it to behave.
>
> m> In the program glimmer, everything is anti-aliased but the text in
> m> the editor itself, which is set to use a font that's aliasable
> m> (Courier New for example).
>
> This is almost always a sign that the program in question is using
> something other than GTK to render text in a particular widget.
> Mozilla, for example, inlines the body of gdk_draw_text.
>
> 	<b
>





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]