Re: lynx-dev Display of SGML Greek Math entities -- solution

[Steve White]

Jungshik,

Let me re-state my argument:

1) To transliterate SGML Mathematical Greek entities into Latin 
   characters is to make them useless for their stated purpose, which is 
   for use in mathematical text.  In such text, they are meant to be 
   distinct from Latin characters in the same text.

2) Although the HTML 4 documentation states that the SGML Mathematical 
   Greek entities map to the same iso10646-1 characters as the alphabetic
   Greek characters, it explicitly sets developers free to support them
   by whatever means is appropriate.

My reference is <http://www.w3.org/TR/html4/sgml/entities.html#h-24.3>.

Lynx running in an ASCII environment is an extreme case that perhaps
the authors of the HTML 4 documentation did not always keep in mind.

In this case, the current behavior of lynx is to *FAIL* to support
the SGML Mathematical Greek entities.  It would be better if it
behaved as though it didn't recognize them at all (when lynx doesn't 
recognize an entity, it just displays the code for the entity:
'&junk;' is rendered '&junk;").  At least, then the Greek Math symbols 
would be distinct from their Latin versions.

What is more important?  The letter of the law, or the intent of the law?

What does a good judge do in case of such a conflict?


On Mon, 19 Aug 2002 18:00:10 -0400 (EDT)
Jungshik Shin <address@hidden> wrote
> Therefore, I think it's neither a good idea nor compliant to HTML4 to
> modify def7_uni.tbl to map '&alphah;' to U+e0e1 and other Greek character
> entity names to PUA code points just to make them rendered as '&alpha;'
> instead of 'a'.  '&alpha;' must be treated exactly the same way  as
>'&#945;' and '&#0x3b1;' are treated because they are just different
> representations of the same character.



; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden