Subject: Superimposing characters

From: Marcus Lundblad <[email-masked]>
Date: Tue, 1 Jul 2003 22:46:08 +0200 (CEST)

I just commited my latest changes.
Now FVWM can render combinational characters superimposed on top of the
"base" character (even if there is no precomposed glyph).

I tested the code with and without xft fonts and with rotated text.
Please try make use of it to find any bugs.

What remains is to fix the drawing of underlined characters, which I think
is broken for BIDI locales (only partly related to combining charaacters).

By the way, I forgot to include the function FlocaleTextWidth in one
ChangeLog entry (only a minor change). Shall I commit just a ChangeLog
entry for this?

//Marcus

--
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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 1 Jul 2003 23:18:33 +0000

> ChangeLog entry (only a minor change). Shall I commit just a ChangeLog

You may commit it individually or with the next commit, by your choice.

Regards,
Mikhael.

---

From: Nadim Shaikli <[email-masked]>
Date: Mon, 7 Jul 2003 18:32:27 -0700 (PDT)

> is broken for BIDI locales (only partly related to combining charaacters).

Marcus, _very_ cool & sorry for the delay in getting back to ya.  I just
downloaded 'fvwm-snap-20030707' and tried the Arabic sample I mailed you.
It core dumps on me upon startup (well, fvwm never does startup) - you have
all my files, you don't get coredumps ?  I'll include the backtrace as well
as what fvwm spewed out upon its exit (for grins),

(gdb) where
#0  FlocaleDrawString (dpy=0xd56a0, flf=0xf0500, fws=0xffbedf58, flags=0)
    at Flocale.c:1767
#1  0x51060 in border_draw_title_deep (fw=0xf10a0, td=0xffbee118,
    tdd=0xffbedf50, fstr=0xffbedf20, dest_pix=79691911, w=79691852)
    at borders.c:3574
#2  0x51404 in border_set_title_pixmap (fw=0xf10a0, td=0xffbee118,
    dest_pix=0xffbee054, w=79691852) at borders.c:3715
#3  0x51494 in border_draw_title (fw=0xf10a0, td=0xffbee118) at borders.c:3742
#4  0x527bc in border_draw_titlebar (cd=0x100, fw=0xf10a0,
    pressed_parts=PART_NONE, pressed_button=-1,
    force_draw_parts=PART_TITLEBAR, clear_parts=CLEAR_ALL, old_g=0x0,
    new_g=0xf1264, do_hilight=0) at borders.c:4337
#5  0x531a8 in border_draw_decorations (fw=0xf10a0, draw_parts=PART_ALL,
    has_focus=0, do_force=0, clear_parts=CLEAR_ALL, old_g=0x0, 
    new_g=0xf1264) at borders.c:4723
#6  0x37ba0 in HandleMapNotify (ea=0xf10a0) at events.c:2466
#7  0x39194 in dispatch_event (e=0xffbee688) at events.c:3534
#8  0x3924c in HandleEvents () at events.c:3572
#9  0x5bd74 in main (argc=983488, argv=0xcdc00) at fvwm.c:2426

[FVWM][style_parse_and_set_window_style]: <<ERROR>> Bad style option:
 WindowList Skip
FvwmButtons: No buttons defined. Quitting
Cannot parse color "black"
Cannot parse color "white"
Cannot parse color "black"
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server ":0.0"

If I remove the Arabic strings, all works well.

Let me know if you need more info.

Regards,

 - Nadim

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Marcus Lundblad <[email-masked]>
Date: Tue, 8 Jul 2003 11:06:46 +0200 (CEST)

> as what fvwm spewed out upon its exit (for grins),

Yes, it works for me (although right now I'm rewriting the underline
textdrawing, so at the moment it's not compiling). Could you please send
me the output from ./configure

Another thing is that I renamed some files on 20030706.
Did you unpack the snapshot over an existing source? Could this be the
problem, I don't think so, but maybe...
I'll try to compile from the snapshot myself, and see what I find.

//Marcus

---

From: Marcus Lundblad <[email-masked]>
Date: Tue, 8 Jul 2003 12:36:28 +0200 (CEST)

> as what fvwm spewed out upon its exit (for grins),

I tried the snapshot.
It worked for me, but when checking the code from the snapshot against
your trace, I found a bug that might be the problem:

The goes like this:

		char_len = 0;
		i = 0;
		while(fws->e_str[i] != 0 && i < len)
		{
		        curr_len = FlocaleStringNumberOfBytes(
				flf, fws->str + i);
			char_len++;
			i += curr_len;
		}

this code calculates the number of characters (not number of bytes,
"chars").
It traverses the string stepping for the amount of bytes comprising each
character. It stops when it encounters the NULL char OR when it has
traversed as much as the length specified.
But since here i is incremented by the number of bytes for each character,
if the string is invalid, i might be incremented past the end of the
string, if for example the last character is a 2-byte UTF-8 char but the
second last byte would indicate a 3-byte sequence. Then i would point PAST
the NULL-byte for the next check in the while-statement

So the conditions should be swapped (since C evaluates the second only if
the first was true).

		char_len = 0;
		i = 0;
		while(i < len && fws->e_str[i] != 0)
		{
		        curr_len = FlocaleStringNumberOfBytes(
				flf, fws->str + i);
			char_len++;
			i += curr_len;
		}
 
I'm not sure if this is why it crashes for you. But in that case running
with this rc-file should give strange results also in older snapshots.

I made the modification, but cannot commit right now, since I'm in a
non-working/compiling state...

//Marcus

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 8 Jul 2003 13:16:15 +0200

> with this rc-file should give strange results also in older snapshots.

Well, why don't you just fix it :-)

By the way, I don't understand why while loops are so popular.  In
this case, you have all four parts of a for loop:  initialisation,
condition, loop body and increment:

  for (char_len = 0, i = 0;
       i < len && fws->e_str[i] != 0;
       char_len++, i += curr_len)
  {
    curr_len = FlocaleStringNumberOfBytes( flf, fws->str + i);
  }

Easier to read and less error prone.

Bye

Dominik ^_^  ^_^

---

From: Marcus Lundblad <[email-masked]>
Date: Tue, 8 Jul 2003 20:35:04 +0200 (CEST)

> Easier to read and less error prone.

OK, now I've submitted code to handle underlining, together with the above
fix.
But, just now I reallised I've been testing using a UTF-8 locale.
I tried to run with a non-UTF-8 locale (sv_SE). Using the Arabic rc file,
it dumps core. But my usual configuration works (except Cond is no longer
valid...)

Now I feel so stupid... So the risk is the current snapshots only work
using Arabic in a UTF-8 locale.

I'll do further debugging.... ^_^

//Marcus

---

From: Nadim Shaikli <[email-masked]>
Date: Tue, 8 Jul 2003 14:41:02 -0700 (PDT)

> me the output from ./configure

Sure, I'll attach config.log/config.cache (let me know if you want these
things off-list).  Its also odd that my sample files work for you, but
not me.

> I'll try to compile from the snapshot myself, and see what I find.

I unpacked snap-20030707 onto its own new directory and do have the new
renamed files (ie. did the right thing all along).

> your trace, I found a bug that might be the problem:

I replaced,

> 		        curr_len = FlocaleStringNumberOfBytes(

with

> the NULL-byte for the next check in the while-statement

Again, there is no difference in my Arabic setup compared to what I mailed
you - so I doubt I'm hitting any NULL or malformed characters (while you
are not).

> with this rc-file should give strange results also in older snapshots.

Older snapshots (pre your changes) worked great for me in terms of Arabic.
With the exception of composing (the superimposing of characters).

> non-working/compiling state...

As noted, I made the change but don't see any difference.  I got the same
stderr output and here is the coredump backtrace,

#0  0x8d668 in FlocaleDrawString (dpy=0xd56b0, flf=0xf0510, fws=0xffbedf58,
    flags=0) at Flocale.c:1767
#1  0x51060 in border_draw_title_deep (fw=0xf10b0, td=0xffbee118,
    tdd=0xffbedf50, fstr=0xffbedf20, dest_pix=79691911, w=79691852)
    at borders.c:3574
#2  0x51404 in border_set_title_pixmap (fw=0xf10b0, td=0xffbee118,
    dest_pix=0xffbee054, w=79691852) at borders.c:3715
#3  0x51494 in border_draw_title (fw=0xf10b0, td=0xffbee118) at borders.c:3742
#4  0x527bc in border_draw_titlebar (cd=0x100, fw=0xf10b0,
    pressed_parts=PART_NONE, pressed_button=-1,
    force_draw_parts=PART_TITLEBAR, clear_parts=CLEAR_ALL, old_g=0x0,
    new_g=0xf1274, do_hilight=0) at borders.c:4337
#5  0x531a8 in border_draw_decorations (fw=0xf10b0, draw_parts=PART_ALL,
    has_focus=0, do_force=0, clear_parts=CLEAR_ALL, old_g=0x0, new_g=0xf1274)
    at borders.c:4723
#6  0x37ba0 in HandleMapNotify (ea=0xf10b0) at events.c:2466
#7  0x39194 in dispatch_event (e=0xffbee688) at events.c:3534
#8  0x3924c in HandleEvents () at events.c:3572
#9  0x5bd74 in main (argc=983504, argv=0xcdc00) at fvwm.c:2426

Running on,
 + uname -a : SunOS pez 5.7 Generic_106541-19 sun4u
 + gcc -v   : gcc version 2.95.2 19991024 (release)

Let me know how I can help.

- Nadim