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

[Steve White]

Henry,

I've been 8-bit-centric in all my discussions.

You have misunderstood my point, but you have raised another
technical issue that I hadn't considered, because I was only
thinking of 8-bit displays.  There is more work to be done yet on
this point.

To see how you missed my point, see below, where you give an
example.

Please understand what we're shooting for here.

On terminals that can display Greek glyphs, the SGML Greek
Mathematical symbols should be rendered using those glyphs.  On
terminals that cannot display Greek glyphs, these entities must be
displayed distinctly from other characters.

Otherwise, information is lost.  This is not a matter of personal
preference, it is a matter of the purpose of the SGML Greek
Mathematical symbols.

On the other hand, I had misunderstood the way these mappings
occur in lynx.  Mapping of the SGML Greek Math entities in
'entities.h' has to be accounted for in all the character set
files, somehow. I have only accounted for it in the default 7-bit
file.

Basically, they all have to get mapped to something.  The change
to 'entities.h' merely re-directs the SGML so that it will be
*possible* to treat them diffently from the Greek alphabetic
characters.

There is one 8-bit character set that does include the Greek
letters: iso-8859-7.  I've already fixed it by re-mapping them in
'iso07_uni.tbl', and tested it.

Until I get some terminals going that use these non-8-bit
character sets, I won't be able to test what I've done.  This may
take a while yet.

>
>Well, as for def7_uni.tbl, it's 'a default fallback for any 8bit user's
>"display character set".'  To use my own example, my display character
>set is "Japanese (EUC-JP)," which means I have a font available to
>represent the entire Greek alphabet (except for "ς").  Why would
>I want to see "Alpha" when I can see an alpha, albeit in double width?
>What I'm saying is, what may be a "pleasing" fallback for one person may
>not be so great for another, and what may be perfectly legible to one
>may be gibberish to the next.  I think the key word is "_a_ default,"
>not "the default."  Everyone is free to change any of those translation
>tables to meet their specific needs or preferences.
>

>> 1) Anyone who has used the SGML entities for their intended
>> purpose, the display of Greek symbols in mathematical formulas,
>> has been disppointed with the way Lynx displays them.
>> 
>> Currently, lynx tranliterates Greek mathematical characters into
>               /may\          =
>> their Latin equivalents, rendering them indistinct from Latin
>> characters in formulas, and often incomprehensible.  This amounts
>> to a loss of information, and is broken behavior.

I mis-stated this.  Try this:

"Currently, in character sets that don't contain the Greek alphabetic
characters, lynx transliterates Greek mathematical characters into 
their Latin equivalents, rendering them indistinct from Latin 
characters in formulas, and often incomprehensible.  This amounts to 
a loss of information, and is broken behavior."

>
>I think you go too far.  I am not "disppointed with the way Lynx
>displays" Greek and most mathematical symbols, at least the ones I
>can read or know what they mean :).  I do not believe Lynx's behavior
>is "broken." 

You aren't even looking at the problem in question.

>I put up an example for you to look at:
>    http://www.irm.nara.kindai.ac.jp/lynxdev/greek.html

Your example proves my point that we're talking about different
things.

Your example doesn't contain any SGML Greek Mathematical symbols
such as "Α" but rather, explicit numerical references such
as "&945;" to characters in you document's character set.

My patch wouldn't affect this document at all.  My patch ONLY
re-directs SGML Greek Mathematical symbols.



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