Re: lynx-dev patch - "JUSTIFY"

[Vlad Harchev]

On Wed, 14 Jul 1999, Klaus Weide wrote:

> On Wed, 14 Jul 1999, Vlad Harchev wrote:
> > 
> >  Binding j. info to styles will require complete implementaion of style 
> > stack
> > (since table elements can contain lists, parargaphs, etc). 
> 
> We agree that the current (and ancient) implementation of 'style
> stack' is incomplete.  I would go further and say its use in HTML.c is
> inconsistent, a mess, and nearly incomprehensible :).
> 
> So I don't blame you for working around it, rather than cleaning it up
> and then using it.  I still point out that such working-around for a
> specific purpose makes things still more complicated, and is probably
> how the mess came into existence in the first place.

 Yes, seems lynx development is turned into lynx hacking IMO (code is badly
documented, nobody wishes to spent a lot of time on it). But seems it's ok for
end-user.
 
> >  And according to the logic - all text with HT_LEFT alignment can be 
> > justified
> > (except H[1-6]), so rather than changing each style definition in
> > DefaultStyle.c I prefered to do this implicitly.
> 
> Another logic sez: All text with HT_LEFT alignment can NOT be justified, since
> unjustified left-aligned text is the default style for the Web.  Only where
> the author explicitly said ALIGN="justify" should justification be applied.
> Or at least, that should be one (the default) option for using/not-using
> text justification.  (one user stylesheet choice if you will)
 
 I didn't understand your last sentence. FYI, -justify commandline option is
added by that patch, as well as JUSTIFY lynx.cfg setting. As for ALIGN=justify
in web pages, IMO we don't have to follow it exactly. IMO html describes
structure first and layout only at second (at least the mode in which
alignment information of the paragraph is ignored seems very useful to me).

> You also justify, if "justification is ON", where the HTML explicitly
> has ALIGN="left", and that really shouldn't be done.

> [ ... ]
> >  I agree that implementing the things you propose will be a right thing. But
> > seems that I won't have time to do anything revolutionary like that in next 
> > 2
> > monthes for free. We have several directions lynx can be improved in, but 
> > all
> > those additions will require a lot of time so seems noone will implement 
> > them
> > in this year.
> 
> Cleaning up style usage in HTML.c isn't really revolutionary, and wouldn't
> have immediately noticeable effects so it's not an attractive project, but
> *someone* should do it...

 Yes, there are a lot of things in lynx someone should do..

> >  I have a very few spare time for anything, and most of the time took 
> > reading
> > the lynx sources (in order to guess how it should be implemented). The
> > shortest (and very strong) agrument I have is that alsmost 98% of the part
> > that is relevant to justification is implementation of the justification of
> > a given line in GridText.c:split_line. The logic that controls whether the
> > given line can be justified can be (re)writtent in 10 minutes, so (at least)
> > we can consider that part as a good codebase for right implementation of
> > justification (the decision whether the current line will be justified is 
> > made
> > in HText_appendCharacter(..) ).
> 
> Ok, I agree that that is a strong argument, and good news.
> 
> (I hope 10 min for you doesn't mean 10 days for eveyone else. :))

FYI, currently justification has the following logic:
The line is considered to be justificable, if
the line is overfulled and
the macro REALLY_CAN_JUSTIFY(text) is true in GridText.c:3279
- this macro is used 3 times in GridText.c
so changing the macro will change entire justification logic.

currently it's defined as

 ( (wait_for_this_stacked_elt<0) && \
        ( text->style->alignment == HT_LEFT     || \
          text->style->alignment == HT_JUSTIFY) && \
        HTCJK == NOCJK && \
        can_justify_here && can_justify_this_line && !form_in_htext )

where 'wait_for_this_stacked_elt' is the index of the element in the stack
that prevents from justifying (H[1-6],pre,table,banner, etc - listed above).

form_in_htext is TRUE if there is FORM in the stack (this is a hack, since 
        FORM can't be present in stack - its content is SGML_EMPTY, so the
        moment it's popped off the stack is detected in HTML_end_element),

can_justify_here, can_justify_this_line - flags that are specific to the
        current line - they are changed if 'TAB' element is used, etc.

So, indeed logic can be changed in a few minutes by redefining
REALLY_CAN_JUSTIFY(text)

>[...] 

 Best regards,
  -Vlad