lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Superscripts


From: Klaus Weide
Subject: Re: lynx-dev Superscripts
Date: Mon, 5 Jun 2000 12:57:56 -0500 (CDT)

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<sup>n</sup>b<sup>n</sup> ... }</p>estas lineara.
> | <p>
> | Iam oni anka?? konsideras la "rigore pozitivan" lingvoiteracion
> | <p align="center">L<sup>+</sup> = L + L?? + L?? + ...
> | </p>(angle <i lang="en">Kleene plus</i>).
> | <p>
> | La normo</a> de <em>C<sup>-1</sup>MC</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<sup>+</sup> becomes mere
> L+ ?  (To my surprise, L<sup>+1</sup> 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 address@hidden

reply via email to

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