Re: Label layout

[Owen Taylor <owt1 cornell edu>]

> What's the best way to add this control?
> 
>    gtk_label_set_justify (widget, GTK_JUSTIFY_FILL | GTK_JUSTIFY_BREAK_LINES)
> 
>  or
> 
>    gtk_label_set_justify (widget, GTK_JUSTIFY_FILL);
>    gtk_label_break_lines (widget, TRUE);

I prefer the second since it is easier to map onto other languages,
and, I suspect, easier to handle in a graphical interface builder
as well. (Combining flags and non-flags in one value will be bad
from that perspective)

> A related problem is how to specify the line width.
> Clearly, (I think), if there is a set_usize()d width, we use that.
> 
> If there is no usized width, currently my code uses a hybrid of:
> 
>   1. A maximum width based on screen size (currently half the width).
>   2. A maximum width based on the width of a fixed sample line
>      (currently, "This is a good length for a line to have.")
>      in the labels font.
>   3. This width may be reduced further (by a somewhat hokey
>      algorithm) in order to try to avoid short final lines in paragraphs.
>      
>          This is done to avoid paragraphs which look like
>          this.
 
This sounds reasonable to me. (I suspect 1. is probably superflous.)
You might think about adjusting your width depending on the length of
the text - for a continuous block of text line length should be about
65 characters (Bringhurst, to cite authority again, says that
anything from 45 to 75 is considered satisfactory, with 66 the
"ideal". This will depend on the interline spacing (leading) - closer
spaced lines should be shorter) - but that is probably to long a
line length for just a few lines.

> Using this last algorithm means that a column of filled labels
> (in a vbox, say) will all pick different paragraph widths for themselves.
> This may not be desirable behavior.

The _requested_ width should be chosen by these types of heuristics.
But you should then use whatever width is finally allocated. So a
column of filled labels will all have the same width. You may
run into problems though, since GTK only does a single pass - Raph's
Gzw widgets do separate horizontal/vertical allocation passes to
handle text wrapping correctly.

> >- The vertical space between paragraphs is too large. If there is
> >  any extra space at all, it should just be a few pixels.
> 
> Okay, whatever you say --- I don't have strong feelings.  Perhaps
> there should be a user choice here too --- maybe double newlines
> (which, as the code currently stands would add a whole blank line)
> could get turned into a small vertical skip?

That would be fine. As long as the user can make paragraph breaks
without _having to_ introducing big gaps in the text.

> >- I don't think any extra space should be added between sentences.
> >  This is a holdover from Victorian typographic horrors and from
> >  bad typewriter manuals. (See the above reference). (Plus, this
> >  would avoid having to use double spaces to mark sentence
> >  boundaries.)
> 
> Not that I've looked at your Binghurst reference yet, but I really do
> like a little extra space after full stops.  The way its set up now,
> (with the double spaces), the post-Victorian programmer can just use
> single spaces at the end of sentences if he doesn't like the bigger gaps.

OK, you're probably right. Though I hate propagating the practice...

> >- The line breaking probably won't work very well for
> >  internationalized text. Probably not worth worrying about much 
> >  now. Eventually, we may want to go to using an internal wide
> >  character representation (Unicode probably) for all text, and
> >  have some standard utility functions to do word breaking, etc.
> 
> I have not given this any consideration at all yet.  It's certainly
> not a priority of mine, and I don't know much about the details.
> I highly doubt that my code works correctly for multi-byte strings now.
> Once the rest is working I'd certainly be willing to fix it so that
> it does.

It may work pretty much OK for the CJK locales anyways - since 
in the common EUC coding, all multibyte characters have the 8th
bit set. The bigger problem is that, e.g., in Japanese, text is
written without spaces at all. So an entirely different algorithm
for line breaking is needed. But I wouldn't worry about it too
much. When somebody needs localized line breaking, they'll write it.

> Other issues which may or may not be worth worrying about:
> 
>   Hyphenization?
> 
>   Also, there are certainly better line-breaking algorithms than
>   just fitting as many words as will fit on each line.  (The algorithm
>   used by TeX is the one I'm familiar with.)

It's only a label widget ;-) Size allocation between widgets isn't
good enough to worry about that much about line breaking right now,
IMO.

> As for your coding style comments --- I'm happy to do it any way you
> want.
> 
> Does someone happen to have the proper indentation settings
> for emacs cc-mode handy?

It should just be the standard 'gnu' settings, at least for reasonably
recent emacs. (I wish there was a way of doing the prototype
alignment automatically, but not enough to write it myself.)

> Thank you very much for the comments.   Give me a couple more hints about
> which direction you'd like to see this move, and I'll work on it.
> (I'm going away for Christmas though, so don't count on me for much
> until after New Years...)

Thanks for working on this!

                                        Owen