Re: lynx-dev Superscripts

[Sergei Pokrovsky]

>>>>> "Klaus" == Klaus Weide <address@hidden> writes:

  Klaus> On 5 Jun 2000, Sergei Pokrovsky wrote:
  >> I find the behavior of Lynx superscripts rather unpredictable.

  Klaus> It's predictable, mut you may not like the rules...

Well, that's better than nothing, but I'd prefer a simpler TeX-like
rule:

1) normally <sub>foo</sub> should be rendered as ^{foo}
2) exceptionally, if just one character appears in the superscript,
   it may be rendered as ^f.

Point (2) is not important for me, actually some people may see it as
a nuisance.

  Klaus> Obviously that's a compromise.  When I added that change, I
  Klaus> was trying to avoid the most obvious misreadings (like
  Klaus> 2<SUP>2</SUP> => 22), while at the same time avoiding that
  Klaus> "blah blah<SUP>&trade</SUP>." becomes "blah blah^{(TM)}." or
  Klaus> similar instead of just "blah blah(TM).". 

I'm ready to tolerate "blah blah^{(TM)}.", it occurs very
infrequently in the texts for which I use lynx.

(I must admit that it is often used for references and similar
attributions; but just in that case it is unpleasant that the
reference becomes fused to the word it relates to.)

In W3 the rendering of such things is governed via style-sheets, and
that seems to be the optimal approach.  Those interested in adequate
rendition of the text can specify delimiters they prefer; the others
may use colors of other typographical effect.  One can tune the
rendition according to one's current needs.

  Klaus> The latter kind of use for SUP seems much more widespread
  Klaus> than its use for math, for which support in HTML (and in
  Klaus> lynx) is quite poor anyway.

I think the lynx audience is rather special one, which should rather
rank the content higher than prettiness (though everybody wants the
rendering to be as beautiful as it is reasonably possible).  E.g. I
often want to use Lynx to dump a flat text.  No color effects, but I
need to have some delimiters.

  Klaus> For your use of lynx (as indicated by your examples), you may
  Klaus> want to change the source code.  Let me know if you need a
  Klaus> pointer where to look.

Well, I am interested in such pointers.  But I want to remain within
the standard.

  >> Also linebreaks often occur in strange places, like in the last
  >> paragraph of my example.

  Klaus> Invalid HTML does that, in this case </a> which doesn't
  Klaus> correspond to an open <a>.  Toggling to "tag soup" mode
  Klaus> sometimes "improves" rendering in such cases, so try ^V.

Sorry for the bug in the example.  Actually it was in a correct piece,
but now I've lost the spot, and the reduced example does not show the
misbehavior after correction.  But I'm afraid I'll have to return to
it when I find the spot next time :/

-- 
Sergei

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