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 [EMAIL PROTECTED]
