Re: Line wrapping of mixed LTR/RTL text

2018-08-28 Thread Eli Zaretskii via Unicode
> From: Cosmin Apreutesei > Date: Tue, 28 Aug 2018 21:28:58 +0300 > Cc: unicode@unicode.org > > > That is not so if the line ends after the whitespace: in that case the > > whitespace is trailing, and will appear at the visual end of the > > line. > > So only if it's a soft break I should

Re: Line wrapping of mixed LTR/RTL text

2018-08-28 Thread Cosmin Apreutesei via Unicode
Hi Philippe, > The space encoded just before the logical end of line or linewrap (in the > middle of the displayed line) has to be moved at end of the physical line (in > the paragraph direction), it should not be kept in the middle. Ok, that seem to confirm what Eli is saying and it clarifies

Re: Line wrapping of mixed LTR/RTL text

2018-08-28 Thread Cosmin Apreutesei via Unicode
Hi Eli, thanks for answering! I think I'm getting closer. Just a few more clarifications if you please. > That is not so if the line ends after the whitespace: in that case the > whitespace is trailing, and will appear at the visual end of the > line. So only if it's a soft break I should indeed

Re: Line wrapping of mixed LTR/RTL text

2018-08-28 Thread Philippe Verdy via Unicode
doing some tests > with fribidi and libunibreak I noticed that the whitespace always > sticks to the logical end of the word (so visually to the right for > LTR runs and to the left for RTL runs), regardless of the base > paragraph direction. Is it safe to use this assumption and always &

Re: Line wrapping of mixed LTR/RTL text

2018-08-28 Thread Eli Zaretskii via Unicode
ans, but by doing some tests > with fribidi and libunibreak I noticed that the whitespace always > sticks to the logical end of the word (so visually to the right for > LTR runs and to the left for RTL runs), regardless of the base > paragraph direction. That is not so if the line

Line wrapping of mixed LTR/RTL text

2018-08-28 Thread Cosmin Apreutesei via Unicode
that means, but by doing some tests with fribidi and libunibreak I noticed that the whitespace always sticks to the logical end of the word (so visually to the right for LTR runs and to the left for RTL runs), regardless of the base paragraph direction. Is it safe to use this assumption and alw

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Philippe Verdy
So we would be in a case where it's impossible to warranty full compatiblity or interoperability between the two concurrent standards from the same standard body, and promissing the best interoperoperability with past flavors of HTML (those past flavors are still not in the past given that two of

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Leif Halvard Silli
Philippe Verdy, Thu, 29 Nov 2012 10:11:13 +0100: So we would be in a case where it's impossible to warranty full compatiblity or interoperability between the two concurrent standards from the same standard body, and promissing the best interoperoperability with past flavors of HTML (those

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Philippe Verdy
You're wrong. XHTML1 is integrated in the W3C validator and recognized automatically. The document you cite in the XHTML1 specs has just not been updated. http://validator.w3.org/check?uri=http%3A%2F%2Fwww.xn--elqus623b.net%2FXKCD%2F1137.htmlcharset=%28detect+automatically%29doctype=Inlinegroup=0

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Leif Halvard Silli
Philippe Verdy, Thu, 29 Nov 2012 13:26:28 +0100: You're wrong. XHTML1 is integrated in the W3C validator and recognized automatically. Indeed, yes. What I meant by doesn't integrate XHTML1' was that Unicorn doesn't 100% adhere to the two sections of XHTML1 that I quoted.[1][2] The document

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Philippe Verdy
And you forget the important part of Appendix A: *Consequence*: Remember, however, that when the XML declaration is not included in a document, AND the character encoding is not specified by a higher level protocol such as HTTP, the document can only use the default character encodings UTF-8 or

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Leif Halvard Silli
Philippe Verdy, Thu, 29 Nov 2012 14:24:29 +0100: And you forget the important part of Appendix A: *Consequence*: Remember, however, that when the XML declaration is not included in a document, AND the character encoding is not specified by a higher level protocol such as HTTP, the document

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Philippe Verdy
2012/11/29 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no Philippe Verdy, Thu, 29 Nov 2012 14:24:29 +0100: ... But why ? Isn't UTF-8 (or alternatively UTF-16) already the default encoding of XHTML? If not, then we should file a bug in the W3C Validator for not honoring the

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Philippe Verdy
In my opinion, from HTML5, and not XHTML5, there should also exist a leading prolog like ?html version=5.0 encoding=utf-8 For XHTML5, we will continue using the XML prolog ; but it *may* be followed by the html prolog, without needing to repeat the optional encoding pseudo-attribute, which XML

Re: LTR

2012-11-29 Thread Doug Ewell
Philippe Verdy verdy underscore p at wanadoo dot fr wrote: In all the ensuing discussion about this page, did anyone notice the typo in the Deseret cartoon? The non-mirrored question mark ? Nope, that's in the original cartoon too. U+003F isn't bidi-mirrored anyway. Try again. There's a

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Leif Halvard Silli
Philippe Verdy, Thu, 29 Nov 2012 16:10:14 +0100: Thanks a lot, this was really hard to see and understand, because I was only reading the XHTML specs, and the Validator did not complain. Glad to find we are no the same page! Philippe Verdy, Thu, 29 Nov 2012 16:27:13 +0100: ?html version=5.0

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Philippe Verdy
- Method 1 (the BOM) is only goof for UTF-16. not reliable for UTF-8 whuch is still the default for XHTML (and where the BOM is not always present). - Method 2 is working sometimes, but is not practicle for many servers that you can't configure to change their content-type for specific pages all

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Leif Halvard Silli
Philippe Verdy, Thu, 29 Nov 2012 19:11:42 +0100: 2012/11/29 Leif Halvard Silli: Philippe Verdy, Thu, 29 Nov 2012 16:27:13 +0100: ?html version=5.0 encoding=utf-8 Thus I can guarantee you that your idea about at method number 9, is not going to be met with enthusiasm. - Method 5 is where ?

Re: UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-29 Thread Philippe Verdy
Note that I challenge the term conforming you use, given that HTML5 is still not released, so its conformance is still not formally defined. The nu validator is still expliitly marked by the W3C as experimental. 2012/11/29 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no HTML5 already have

Re: ‮LTR

2012-11-29 Thread John H. Jenkins
I double-checked *very* carefully, and I did't see anything wrong at all. :-) You got sharp eyes there, Doug. On 2012年11月28日, at 下午10:58, Doug Ewell d...@ewellic.org wrote: John H. Jenkins wrote: Or, if one prefers: http://www.井作恆.net/XKCD/1137.html In all the ensuing discussion

Re: LTR

2012-11-29 Thread Philippe Verdy
The only minor typo that I see is the lowercase e in U+202e. But this not written in Deseret, and is similar to the Latin version. An exclamation point in the Latin version becomes a full dot in Deseret : minor typo as well I think but still a difference. The Latin word « DIDN'T » (reversed)

RE: LTR

2012-11-29 Thread Doug Ewell
Philippe Verdy verdy underscore p at wanadoo dot fr wrote: The Latin word « DIDN'T » (reversed) seems to be transliterated to Deseret as « DID'T » (reversed), missing an N You're about two hours behind John, but that's it. -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org |

Re: xkcd: LTR

2012-11-28 Thread Philippe Verdy
2012/11/28 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no Philippe Verdy, Wed, 28 Nov 2012 04:50:06 +0100: detects a violation of the required extended prolog (sorry, the HTML5 document declaration, which is not a valid document declaration for XHTML or for HTML4 or before or even

UTF-8 isn't the default for HTML (was: xkcd: LTR)

2012-11-28 Thread Leif Halvard Silli
Philippe Verdy, Wed, 28 Nov 2012 11:02:45 +0100: In this case, Firefox and IE should not even be able to render *any* XHTML page because it violates the HTML5 standard. (1) The page in question (http://www.xn--elqus623b.net/XKCD/1137.html) is (from a source code point of view) a pure XHTML

Re: ‮LTR

2012-11-28 Thread Doug Ewell
John H. Jenkins wrote: Or, if one prefers: http://www.井作恆.net/XKCD/1137.html In all the ensuing discussion about this page, did anyone notice the typo in the Deseret cartoon? ☺ -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org | @DougEwell ­

Re: LTR

2012-11-28 Thread Philippe Verdy
The non-mirrored question mark ? 2012/11/29 Doug Ewell d...@ewellic.org John H. Jenkins wrote: Or, if one prefers: http://www.井作恆.net/XKCD/1137.**htmlhttp://www.xn--elqus623b.net/XKCD/1137.html In all the ensuing discussion about this page, did anyone notice the typo in the Deseret

Re: xkcd: ‮LTR

2012-11-27 Thread Simon Montagu
On 11/26/2012 08:42 PM, Marc Durdin wrote: Somewhat ironically, both Firefox and Internet Explorer, on my machine at least, detect this page is encoded with ISO-8859-1 and cp-1252 respectively, instead of UTF-8. It seems they both ignore the XML prolog which is the only place where the encoding

Re: xkcd: ‮LTR

2012-11-27 Thread Behnam Esfahbod ZWNJ
Simon, There's no sign of HTML5 on that page. The head of the file matches all XHTML 1.1 requirements and passes all checks on validator.w3.org. Now, why would Firefox follow anything from HTML5 spec here? -Behnam On Tue, Nov 27, 2012 at 3:37 AM, Simon Montagu smont...@smontagu.orgwrote: On

Re: xkcd: ‮LTR

2012-11-27 Thread Simon Montagu
On 11/27/2012 11:19 AM, Behnam Esfahbod ZWNJ wrote: Simon, There's no sign of HTML5 on that page. The head of the file matches all XHTML 1.1 requirements and passes all checks on validator.w3.org http://validator.w3.org. Now, why would Firefox follow anything from HTML5 spec here? As I

Re: xkcd: LTR

2012-11-27 Thread Philippe Verdy
HTML5 does not reference the Content-Type: text/html header as enough to qualify as meaning HTML5. HTML5 **requires** its own prolog (i.e. its basic document declaration **within** the document itself, for the HTML syntax, or its FULL document declaration for the XML/XHTML syntax). So Firefox is

Re: xkcd: LTR

2012-11-27 Thread Philippe Verdy
I've never said that user agents had to 'write the prolog. It's the reverse: yes authors have to write a prolog (but the prolog is perfect here so this is not the fault of the author). Why do have to use this prolog, it's exactly because user agents will have to read it (not write it), as it is

Re: xkcd: LTR

2012-11-27 Thread Philippe Verdy
Also you make a confusion in the sense that HTML5 must be able to parse HTML4. This is true, but this does not mean that they will be able to render it fully. HTML5 is not fully upward compatible with past versions (and the case of the identification of encodings is an example where it is

Re: xkcd: LTR

2012-11-27 Thread Leif Halvard Silli
Philippe Verdy, Tue, 27 Nov 2012 15:39:43 +0100: I've never said that user agents had to 'write the prolog. It's the reverse: yes authors have to write a prolog (but the prolog is perfect here so this is not the fault of the author). XML has (or more correctly: can have) a prolog. HTML does

Re: xkcd: LTR

2012-11-27 Thread Khaled Hosny
Looks OK here, but that is probably FreeType doing its magic as usual. Regards, Khaled On Tue, Nov 27, 2012 at 02:29:45AM +0100, Philippe Verdy wrote: Also I really don't like the Deseret font: {font-family: CMU; src: url(CMUSerif-Roman.ttf) format(truetype);} that you have inserted in your

Re: xkcd: LTR

2012-11-27 Thread Philippe Verdy
A ! I see now the problem: the XHTML file is being served as HTML instead of XHTML (but this is not invalid for XHTML 1). But anyway you're also right that the XML prolog found is NOT valid for HTML5 when the file is served as HTML instead of XHTML. This should immediately trigger the fact

Re: xkcd: LTR

2012-11-27 Thread Philippe Verdy
No. Freetype is not involved here for the ugly rendering (on screen) under Windows of the unhinted CMU font provided by the page. May be this looks OK on Mac (if Safari is autohinting the font itself, despite the font is not autohinted itself ; I'm not sure that Safari on MacOS processes TTF fonts

Re: xkcd: LTR

2012-11-27 Thread Leif Halvard Silli
Philippe Verdy, Tue, 27 Nov 2012 21:07:31 +0100: A ! I see now the problem: the XHTML file is being served as HTML instead of XHTML (but this is not invalid for XHTML 1). Both SGML-based HTML4 and XML-based XHTML 1 operate with syntax rules that are not - and has never been - compatible

Re: xkcd: LTR

2012-11-27 Thread Asmus Freytag
On 11/27/2012 5:39 AM, Masatoshi Kimura wrote: (2012/11/27 20:27), Philippe Verdy wrote: Could you please stop spreading an unfounded rumor such as Firefox is wrong because it ignores the lacking of HTML5 prolog? Getting Philippe to stop spreading unfounded anything is a near impossible

Re: xkcd: LTR

2012-11-27 Thread Philippe Verdy
2012/11/27 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no The fact that XHTML 1 permits the XML prolog regardless how the document is served, is just a shortcoming of the XHTML 1 specification. No, it was by design. Making HTML an application of XML. Only XML but with all rules of XML.

Re: LTR

2012-11-27 Thread Doug Ewell
So using the xml:lang=en-Dsrt pseudo-attribute remains a good suggestion to allow a CSS stylesheet to avoid using referening CMU font on Windows and MacOS when displaying the Latin text (using xml:lang=en) and to allow the same stylesheet to specify a much better Deseret font for Windows (Segoe

Re: xkcd: LTR

2012-11-27 Thread Leif Halvard Silli
Philippe Verdy, Wed, 28 Nov 2012 01:10:45 +0100: 2012/11/27 Leif Halvard Silli The fact that XHTML 1 permits the XML prolog regardless how the document is served, is just a shortcoming of the XHTML 1 specification. No, it was by design. Making HTML an application of XML. Only XML but with 

Re: xkcd: LTR

2012-11-27 Thread Philippe Verdy
2012/11/28 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no For a new version of the validator, that ask more of those questions, please try http://validator.w3.org/nu/ - it happens to for the most part be developed by one of the Firefox developers, btw. And it allows you to check

Re: xkcd: LTR

2012-11-27 Thread Philippe Verdy
detects a violation of the required extended prolog (sorry, the HTML5 document declaration, which is not a valid document declaration for XHTML or for HTML4 or before or even for SGML, due to the unspecified schema after the shema short name), it should catch this exception to try

Re: xkcd: LTR

2012-11-27 Thread Leif Halvard Silli
Philippe Verdy, Wed, 28 Nov 2012 04:23:10 +0100: 2012/11/28 Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no For a new version of the validator, that ask more of those questions, please try http://validator.w3.org/nu/ - it happens to for the most part be developed by one of the Firefox

Re: xkcd: LTR

2012-11-27 Thread Leif Halvard Silli
Philippe Verdy, Wed, 28 Nov 2012 04:50:06 +0100: detects a violation of the required extended prolog (sorry, the HTML5 document declaration, which is not a valid document declaration for XHTML or for HTML4 or before or even for SGML, due to the unspecified schema after the shema short name),

Re: xkcd: ‮LTR

2012-11-26 Thread John H. Jenkins
Or, if one prefers: http://www.井作恆.net/XKCD/1137.html On 2012年11月21日, at 上午10:22, Deborah Goldsmith golds...@apple.com wrote: http://xkcd.com/1137/ Finally, an xkcd for Unicoders. :-) Debbie

RE: xkcd: ‮LTR

2012-11-26 Thread Marc Durdin
...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf Of John H. Jenkins Sent: Tuesday, 27 November 2012 1:15 AM To: Unicode Mailing List Subject: Re: xkcd: LTR Or, if one prefers: http://www.井作恆.net/XKCD/1137.html On 2012年11月21日, at 上午10:22, Deborah Goldsmith golds...@apple.commailto:golds

Re: xkcd: LTR

2012-11-26 Thread Philippe Verdy
I wonder why this IDN link appears to me using sinograms in its domain name, instead of Deseret letters. The link works, but my browser cannot display it and its displays the Punycoded name instead without decoding it. This is strange because I do have Deseret fonts installed and I can view

Re: xkcd: LTR

2012-11-26 Thread Philippe Verdy
] *On Behalf Of *John H. Jenkins *Sent:* Tuesday, 27 November 2012 1:15 AM *To:* Unicode Mailing List *Subject:* Re: xkcd: LTR ** ** Or, if one prefers: ** ** http://www.井作恆.net/XKCD/1137.html ** ** On 2012年11月21日, at 上午10:22, Deborah Goldsmith golds...@apple.com wrote

Re: xkcd: LTR

2012-11-26 Thread John H. Jenkins
That's because the domain does, in fact, use sinograms and not Deseret. (It's my Chinese name.) On 2012年11月26日, at 下午1:54, Philippe Verdy verd...@wanadoo.fr wrote: I wonder why this IDN link appears to me using sinograms in its domain name, instead of Deseret letters. The link works, but my

RE: xkcd: LTR

2012-11-26 Thread Marc Durdin
Of Philippe Verdy Sent: Tuesday, 27 November 2012 7:49 AM To: Marc Durdin Cc: John H. Jenkins; Unicode Mailing List Subject: Re: xkcd: LTR Not a bug of your machine or browser; this is a problem of the webserver in its metadata. The transport layer indicates to the client another encoding in HTTP

Re: xkcd: LTR

2012-11-26 Thread Philippe Verdy
Also I really don't like the Deseret font: {font-family: CMU; src: url(CMUSerif-Roman.ttf) format(truetype);} that you have inserted in your stylesheet (da.css) which is used to display the whole text content of the page, including the English Latin text at the bottom part. This downloaded font is

Re: xkcd: LTR

2012-11-26 Thread Philippe Verdy
Did you try add the xml:lang=en-Dsrt pseudo-attribute to the html element, as suggested by the W3C Unicorn validator ? http://validator.w3.org/unicorn/check?ucn_uri=www.xn--elqus623b.net%2FXKCD%2F1138.htmlucn_lang=frucn_task=conformance# May be this could help IE and Firefox that can't figure

Re: xkcd: LTR

2012-11-26 Thread Philippe Verdy
Anyway, you could at least use Segoe UI before your CMU font, even if Segoe UI works only in Windows, but it has a decent support for Deseret. May be there's a good font also on your Mac that ships with some recent version of Mac OS, which you could list too. Leaving your CMU after them, only for

xkcd: ‮LTR

2012-11-21 Thread Deborah Goldsmith
http://xkcd.com/1137/ Finally, an xkcd for Unicoders. :-) Debbie

RE: RTL - LTR

2004-03-27 Thread Jony Rosenne
LRO/PDF Jony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hudson Sent: Saturday, March 27, 2004 5:05 AM To: [EMAIL PROTECTED] Subject: RTL - LTR What is the recommended method for reversing the normal direction of text? For example

RE: RTL - LTR

2004-03-27 Thread Asmus Freytag
Rosenne wrote: LRO/PDF Jony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hudson Sent: Saturday, March 27, 2004 5:05 AM To: [EMAIL PROTECTED] Subject: RTL - LTR What is the recommended method for reversing the normal direction of text

RTL - LTR

2004-03-26 Thread John Hudson
What is the recommended method for reversing the normal direction of text? For example, if one has Arabic text and wishes to reverse the direction so that it goes from left to right, how should one do this? Some app, e.g. InDesign ME, offer 'Character Direction' control that affects selected