lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Hebrew/Arabic Bidirectional issues with lynx


From: Foteos Macrides
Subject: Re: LYNX-DEV Hebrew/Arabic Bidirectional issues with lynx
Date: Sat, 06 Sep 1997 18:07:16 -0500 (EST)

David Woolley <address@hidden> wrote:
>> the character definitions.  Are there browsers that switch the direction
>> of reading according to the individual character being read, within a
>> page written in one charset?
>
>I would say any browser that claims to support a bidirectional character
>set should do this (on the principle that HTML is a logical markup language
>and physical aspects are for the browser).  However, I can't see it being
>high on the priority list for developers (although it does seem true than
>NS and MS are extending their markets as much geographically as by increased
>capability now).  You can also almost certainly assume that the average site
>manager, in this plug and play era, doesn't know how to make his site give
>out the correct character set designation, anyway (there seem to be enough
>problems with undeclared KOI8 being reported, and many sites send CP 1252
>but declare it as ISO 8859/1).
>
>I'd say this is likely to be an area which remains a mess for a long time.


earlier, Doug Kaufman <address@hidden> wrote:
>I found a web page that puts together most of the issues about
>right-to-left languages on the web, including links to the RFC about this
>and to the ECMA technical report on handling bidirectionality.  Anyone
>interested in the topic might want to see:
>
>"http://ourworld.compuserve.com/homepages/Jonathan_Rosenne/hebrew.htm";


        That page is useful, but dated, and the developers beyond Klaus
might be better off to activate the "HTML i18n" link in the Lynx online
'h'elp and study the information provided there and in its set of links,
particularly because essentially all of RFC 2070 has been incorporated
into the W3C's so-called HTML 4.0, and since Netscape and MSIE have de
facto veto power at the W3C (and are manuevering to acquire it in the
IETF, with a well meaning but not very bright member of the IETF inner
circle stupidly granting it to them in a number of respects), one can
anticipate that Netscape and MSIE plan to follow Tango in implementing
it.

        Read the paragraph that contains the "page of pointers" link,
and then activate that link.  It returns a page with a META that sets
charset=utf-8 (not unicode-1-1-utf-8, but the "default" document
character set it's trying to assert is basically that which replaces
iso-8859-1 as of RFC 2070 and so-called HTML 4.0 :).  The page has
8-bit/multibyte characters only as link names, none as attribute values,
and no fancy BIDI markup, so in theory with the Lynx chartrans support
you should see a variety of languages displayed as intended if you have
unicode support and "UNICODE UTF 8" selected as your display character
set.  If you select ISO-based, or ISO-like-based display character sets,
which are "sub-sets" of what is now the default document character set
for HTML, you should see the proper ASCII and 8-bit characters supported
by your display character set, and others as Uhhh substitutions.  So if
you've added Doug's patch, or are using the current fotemods, and have
iso-8859-8, when you select "ISO 8859-8 Hebrew" what do you see in the
"Yiddish" section?  If you have koi8-r or Cyrillic charsets, and select
the corresponding display character set, what do you see in the "Russian"
section?  If you have iso-8859-7, and select "ISO 8859-7 Greek", what do
you see in the "Greek" section?  AND, if you select "ISO Latin 1", or
"IBM PC codepage 850", or "WinLatin1 (cp1252)", what do you see overall?

        Now what do you suppose users of the most recent or about to be
released versions of Netscape and MSIE will be seeing, and will be in
documents created by their HTML editors, for *attribute values* as well
as state S_text components of those documents?

        We're not talking about Christmas trees of colors, or other
glitz and blitz, or what is meant by "featuritis", or a so-called
"completely different method" yielding an error and warning free
compilation.  We're talking about a basic requirement for those
people who still really need a browser like Lynx -- ability to get
at the content and make it readeable on a character cell terminal,
or speech or braille interface.  Stop kidding yourselves that time
isn't running out.

        And what's been done in the devel code since Klaus' return
is that more #ifdef EXP_CHARTRANS conditionals have been added so
that it might actually be built without that defined.  Why?

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]