Re: lynx-dev Superscripts

[Klaus Weide]

On 5 Jun 2000, Sergei Pokrovsky wrote: > I find the behavior of Lynx superscripts rather unpredictable. It's predictable, mut you may not like the rules... > To take an example, the file > > ,---- > | Ekz-e la lingvo > | <p align="center">{ab, aabb, aaabbb, aaaabbbbb, ... > | aⁿbⁿ ... }</p>estas lineara. > | <p> > | Iam oni ankaŭ konsideras la "rigore pozitivan" lingvoiteracion > | <p align="center">L⁺ = L + L² + L³ + ... > | </p>(angle <i lang="en">Kleene plus</i>). > | <p> > | La normo</a> de <em>C^-1MC</em>.<p> > `---- > > is rendered as > > ,---- > | Ekz-e la lingvo > | > | {ab, aabb, aaabbb, aaaabbbbb, ... a^nb^n ... } > | estas lineara. > | > | Iam oni konsideras la "rigore pozitivan" lingvoiteracion > | > | L+ = L + L² + L³ + ... > | (angle Kleene plus). > | > | La normoj > | de C^-1MC. > `---- > > The rendering a^nb^n is what I expect; C^-1MC is worse (I'd prefer to > see C^{-1}MC); but I cannot understand why L⁺ becomes mere > L+ ? (To my surprise, L⁺¹ also becomes "L+1".) To quote from CHANGES: 1999-11-03 (2.8.3dev.14) * changes for SUP and SUB: Render SUP visibly as a '^' character if it needs to be separated from a preceding character in order to prevent misinterpretation. The test currently used is isxdigit for the the preceding character. Render <SUB> and </SUB> always as brackets '[' and ']' respectively. SUB is mostly used in technical material while SUP occurs frequently in pages of general nature where it is not essential, therefore the different treatment. Before that, lynx was never trying to show SUP and SUB at all (except with --enable-color-style, where it could be made to show them with different colors). Obviously that's a compromise. When I added that change, I was trying to avoid the most obvious misreadings (like 2<SUP>2</SUP> => 22), while at the same time avoiding that "blah blah<SUP>&trade</SUP>." becomes "blah blah^{(TM)}." or similar instead of just "blah blah(TM).". The latter kind of use for SUP seems much more widespread than its use for math, for which support in HTML (and in lynx) is quite poor anyway. For your use of lynx (as indicated by your examples), you may want to change the source code. Let me know if you need a pointer where to look. > Also linebreaks often occur in strange places, like in the last > paragraph of my example. Invalid HTML does that, in this case </a> which doesn't correspond to an open <a>. Toggling to "tag soup" mode sometimes "improves" rendering in such cases, so try ^V. Klaus ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]