From: Martin V. <mar...@hu...> - 2001-01-17 16:50:10
|
On Wed, Jan 17, 2001 at 04:22:17PM +0200, do...@im... wrote= : > From: do...@im... > Subject: Re: [Wvware-devel] wv and documents from Hebrew word > To: mar...@hu... (Martin Vermeer) > Date: Wed, 17 Jan 2001 16:22:17 +0200 (IST) > Cc: wvw...@li... > In-Reply-To: <200...@hu...> from "Martin Vermeer" at Jan= 17, 2001 02:34:19 PM > X-Mailer: ELM [version 2.5 PL0pre8] >=20 > Martin Vermeer wrote: > > Now that I think about it... did you get the string=20 > >=20 > > Could Someone who sees this tag tell me what was is this type of > > justification, asian languages only i thing=20 > >=20 > > inserted in your HTML output? Translating t1.doc, I don't. If you don= 't, > > it's no use replacing it by anything, as it won't go anywhere... the > > only alignment tag I see embedded into the <p ...> tag is text-align:= right. >=20 > No it was only written to stderr after I compiled wv with the -DDEBUG > flag. So what would I have to do to get the p tag insert something base= d on > the RTL justification. That is weird... I've grepped wv for this string and the *only* places I can find it is the xml templates. But they *embed* their stuff in the output file, not stderr. I don't understand that at all. In principle it would be: put DIR=3DRTL; in the p tag. Which should be achieved is the <asian> .. </asian> tags were really used, by putting it in there. You could try, I am lost on this one. > > =20 > > > > I get Hebrew text in Mozilla 0.7, nicely at the right margin. > > > > But it's Hebrew to me ;-) Pic attached. > > >=20 > > > Yep, it's Hebrew alright. But the characters come out in the wrong > > > order because the bidi algorithm isn't applied. As far as I underst= and > > > the BiDi support is not yet in the main branch of Mozilla. > > > =20 > > > But what I don't understand is if you didn't have the problems with > > > the endiness of Unicode as I described in my mail?=20 > >=20 > > Didn't I? what does the picture tell? The code I get in t1.html is > >=20 > >=20 > >=20 > This seems to be the correct UTF-8 sequence though it would be easier t= o say=20 > if you would have sent a HEX dump.=20 Here: 0001120 6574 203b 3e22 0a0a a9d7 9cd7 95d7 9dd7 t e ; " > \n \n =D7 =A9 =D7 234 =D7 225 = =D7 235 0001140 d720 d79c d79b 209c 94d7 a2d7 95d7 9cd7 =D7 234 =D7 233 =D7 234 =D7 224 =D7 =A2 =D7= 225 =D7 234 0001160 9dd7 0a21 3c0a 702f 0a3e 2f3c 6964 3e76 =D7 235 ! \n \n < / p > \n < / d i v > > So why didn't I get this sequence on=20 > my Linux system?=20 The only explanation I can come up with is that you have RH 7.0 and I have RH 6.2. There is a switch in wvware now that detects the endianness of the iconv version used (which was flipped by Red Hat going to 7.0 for some reason) and I suspect this is related to that. Somehow 1. iconv byte order is not properly detected in a Hebrew locale, or 2. the iconv implementation somehow treats Hebrew differently (but how=20 can it? UTF-8 is UTF-8). Dom fought with this some time ago (instating the switch) and I know he hates it. Dom? You're the expert ;-) And you have RH7. =20 > Dov >=20 Martin --=20 Martin Vermeer mar...@hu... Helsinki University of Technology=20 Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq |