lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev hyphenation


From: Vlad Harchev
Subject: Re: lynx-dev hyphenation
Date: Sun, 1 Aug 1999 11:10:10 +0500 (SAMST)

On Sat, 31 Jul 1999, Klaus Weide wrote:

> On Sat, 31 Jul 1999, Vlad Harchev 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) -
seems only HText_appendCharacter should be tweaked and checked for side
effects.

>[...] 
> >  Can they be nested?
> 
> Well, I couldn't find NOBR in an official HTML spec, so I don't know.
> Since it doesn't officially exist, you might ignore it, although I
> seem to see it a lot.  Handling it anyway may help to reduce the
> problem you were already concerned with, hyphenating in inappropriate
> strings.
> 
> Keeping a counter (me->Nobr_Level) wouldn't be much more effort than a
> simple flag (me->inNOBR), should it be necessary to keep track of
> nesting.

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

> > 
> >  I don't know how much information from HTML document and HTTP headers that
> > patch will use, but seems this is situation similar to justification -
> > additional logic can be added later (remember, reasonable control for
> > justification can be provided if lynx style sheets support is implemented -
> 
> See below - we don't need to wait for extended style sheet support do
> do (3).  Part of what you call additional logic - what I call more correct
> logic - should be implementable now.
> 
> > that will require a lof of time) - but seems for this patch implementing
> > perfect logic and control will require much less efforts than with
> > justification.
> 
> It should at least be written in a way that it can deal with changes
> of the current language (which may come from HTML parsing).

 Ok, I'll try.

>[...] 
> 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).


>   (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().

 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).
 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.

 Best regards,
  -Vlad


reply via email to

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