On Sat, Jul 20, 2002 at 05:57:23AM +0000, Mikhael Goikhman wrote:
> On 18 Jul 2002 15:22:20 +0200, Dominik Vogt wrote:
> >
> > I'm still loking for a reliable way to get a good contrast between
> > text and a random background picture. The best I've come up with
> > yet is:
> >
> > colorset 27 transparent, fg white, fgsh black
> > menustyle * menucolorset 27
> > menustyle * font "Shadow=1 n s e w nw ne sw se:lucidasanstypewriter-14"
> >
> > A black halo is drawn around the the white text. But the halo is
> > still too thin to give a good contrast. If it were possible to
> > extend the halo to a size of 2 it would be much more readable.
>
> I postponed this reply, and now it seems to be too late. Anyway, I am
> posting it, because I think it is a more general solution than the special
> "center" direction (by the way we already have "all", do we need both?).
Well, "all" doesn't provide the effect "center" does. Now that we
have the latter, "all" is pointless. I think I'll remove it.
> Some time ago I wrote that I would disable shade size greater than 1 with
> more then one direction (i.e. force size 1 if there are more than 1
> direction), because it looks unnaturally bad.
I fail to see what multiple directions are good for in the first
place. Why would I have a N+S or a S+SE+E shadow?
> I think there may be added support for sizes 2+ with multiple directions
> using this simple algorithm. If the current 8 directions are encoded using
> one bit per direction, bits 12346 currently produce ugly:
>
> ....... ....... o..o..o
> ....... .o.o.o. .o.o.o.
> ..ooo.. ..ooo.. ..ooo..
> ...xo.. ...xoo. ...xooo
> ...o... ...o... ...o...
> ....... ...o... ...o...
> ....... ....... ...o...
>
> But they may produce instead a bit more natural:
>
> ....... ....... ooooooo
> ....... .ooooo. .oooooo
> ..ooo.. ..oooo. ..ooooo
> ...xo.. ...xoo. ...xooo
> ...o... ...o... ...o...
> ....... ...o... ...o...
> ....... ....... ...o...
>
> For each of 8 pairs of bits (i, i+1), if both are set then in addition to
> 2 shadow pixels drawn in each iteraction, all pixels between them are
> drawn too. If size=N and offset=0 this is N-1 additional line pixels.
>
> This may also get rid of this diagonal problem (when specifying "r br").
>
> "br" (old) (new)
> ....... ....... .......
> ....x.. ....xoo ....xoo
> ...x.o. ...xooo ...xooo
> ..x.o.o ..xoo.o ..xoooo
> ...o.o. ...o.o. ...ooo.
> ....o.. ....o.. ....o..
Well, feel free to give it a shot. It's quite easy to do. In
FlocaleGetShadowTextPosition, the code handing "center" scans the
grid of pixels around the origin for positions where a shadow
pixel has to be drawn. All you need to do is modify this code to
handle the normal directions and the merging between adjacent
directions. There is one pitfall: since a "center" shadow is
symmetrical, I didn't handle text rotation.
> So all three "n s e w nw ne sw se", "all" and "center" would be the same.
>
> Currently "all" works like "center", but the code suggests that it should
> work like "n s e w nw ne sw se", not "center". I don't know why it is.
Because "all" includes "center" at the moment.
> Starting from yesterday xft fonts with shadow are very slow.
Any shadows or just the ones using "all"? If this happens only
with "all", see above. If not, please add a debug statement
around line 437 in Fft.c:
fprintf(stderr, "\n");
while (FlocaleGetShadowTextPosition(&xt, &yt, &gstp_args))
{
fprintf(stderr, "fftds: fgstp returned %d %d\n", xt, yt);
DrawStringFunc(fftdraw, &fft_fgsh, uf, xt, yt, str, len);
}
I don't have a working Xft library.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
