lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev hyphenation


From: Klaus Weide
Subject: Re: lynx-dev hyphenation
Date: Sat, 31 Jul 1999 16:21:06 -0500 (CDT)

On Sun, 1 Aug 1999, Vlad Harchev wrote:
> On Sat, 31 Jul 1999, Klaus Weide wrote:
> > One way out of this would be to allow HText_appendCharacter some
> > "overdraft", i.e. let the line grow longer than it ever should be (up
> > to the next space or word delimiter, probably), but - apart from the
> > question where to stop - this will violate an invariant that has so
> > far always been true (except for SOURCE mode before LY_SOFT_NEWLINE
> > splitting was introduced), and may be assumed in various places, so
> > it would likely create problems (possibly very obscure ones).
> 
>   It seemed to me that entire next word is accumulated..   I'll try to do this
> first (ie to wait until entire word arrives - until next space or cr or lf) -

Or the line is full (MAX_LINE), or the candidate word is longer than the
longest you can handle (longest word in dictionary?).

> seems only HText_appendCharacter should be tweaked and checked for side
> effects.

It seems every use of HText_TrueLineSize and of HText_LastLineSize also
has to be checked.


>  Yes, will have a counter. (Does NOBR inhibbits justification or line wrapping
> too)?

I don't know.  I think it's a Netscape invention, maybe someone here knows
what it is indented to do, or where to look.

> >[...] 
> > Let me rephrase: I would like to see patches to make "text
> > justification" more correct, before patches for "hyphenation" start
> > getting applied (if at all).
> > 
> > The patches I would like to see for justification should handle
> > ALIGN="justify" at least for those elements where HTML_start_element
> > currently already reacts to an ALIGN attribute.  Those are not many
> > elements.  A third mode should be provided, in addition to what is
> > currently the case:
> >   (1) treat all ALIGN="left"[*] and ALIGN="justify" as ALIGN="left" 
> >       (traditional)
> >   (2) treat all ALIGN="left"[*] and ALIGN="justify" as ALIGN="justify"
> >       except for some hardcoded tags (your mode, as I understand it)
> 
>   yes, and for some special cases (in FORM - its content is SGML_EMPTY so it
> can't
> be tracked in the HTML parser stack), in DTs (it has SGML_EMPTY content).

Only with TagSoup.

> >   (3) treat ALIGN="left"[*] as ALIGN="left", and treat ALIGN="justify"
> >       as ALIGN="justify" (at least for those tags where HTML.c already
> >       interprets ALIGN; new)
> > 
> > [*] the ALIGN="left" may not be explicit but just the unstated default.
> > 
> > Or maybe (per user preference)
> >   (3a) treat explicit ALIGN="left" as ALIGN="left", and treat
> >        ALIGN="justify" and missing ALIGN as ALIGN="justify".
> 
>  Seems one of the solutions will be to rely on me->sp->style (I believe lynx
> maintains me->sp->style->align according to the ALIGN attribute - at least 
> HT_RIGHT and HT_LEFT are differenciated and reflected) - so (3) and (3a) can
> be achieved by initializing all stylesheet values to either HT_LEFT (first 
> case) or HT_JUSTIFY before entering mainloop().

Maybe only those styles in DefaultStyle.c for which (a) justification
actually makes sense (I thing this should exclude for example Hn) and
the code can deal with it, and (b) which don't already have variants
for specific alignments {HT_LEFT,HT_RIGHT,HT_CENTER} - DivLeft,DivRight,
DivCenter.  And add some new ones e.g. (or only?) DivJustify.  

In various places HTML.c (also to check: LYCharUtils.c) changes the
alignment of various HTStyles temporarily and later tries to reset
them to default values.  E.g. the alignment of DivCenter can become
HT_LEFT and so on.  (And the re-setting doesn't always seem to work
right, in more complicated cases of nested blocks with different
alignments).  It's all a mess that has to be checked...  But it seems
still better to me to plug the new kind of alignment into the existing
mechanism rather than having (only) a completely orthogonal mechanism.

>  Klaus, have you seen justification in work? (IMO anybody won't allow page
> author to inhibbit justification of the paragraph that can be nicely justified
> only because the author decided to do it so due to some unknown reason - or
> may be left-aligned texts looks not worth than justified in graphical mode).

I haven't seen it in Lynx.  I can see man pages.  I don't feel it is
something I am missing much in Lynx so far.  I got the impression that
others feel the same way.

If anything, I would think justified text is *more* likely to look good
in graphical browser than in text mode.

Not all authors are clueless.  Give them at least a chance to get the
alignment they can expect from a browser that implements "justify"
according to the HTML spec, instead of thinking you always know better
where ALIGN="justify" is 'reasonable' (if turned on at all).

You experience and opinion may also depend on the kinds of pages you
visit.  Pages with lots of short paragraphs (say 2 or 3 lines) likely
won't look good with justification.

>  Anyway, I don't guarantee that I will do this ASAP.
> 
>  Seems we can ask anybody that tried justification in lynx whether s/he would
> like to honor correct ALIGN= value of the html elements or s/he would like
> to see justified everything reasonable.
> 
>  I should inform that I'll have free time to work on hyphenation in the 2nd
> half of August. And I hardly can force myself to complete logic that controls
> justification before writing support for hyphenation. Sorry.

I think you said yourself that 99% of "justify" was already done...
(or was it 98%?)

   Klaus


reply via email to

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