Re: Re: Label layout

[Jeff Dairiki <dairiki wharf-rat apl washington edu>]

In message <lz90tq1bme.fsf@cu-dialup-0225.cit.cornell.edu>,Owen Taylor writes:
>A few comments:

Good points, all of them....

>- I think GTK_JUSTIFY_FILL has been hijacked. That is, it should
>  only specify full justification. (Actually, the whole thing is
>  a (commonly accepted) abuse of terminology. Text can be set:
> 
>  Justified
>  Flush left/ragged right 
>  Flush right/ragged left

Yes, I was worried about this too, but was afraid to take the responsibility
of changing/augmenting the API in order to add the necessary controls.
The code for these cases is simple enough...

>  See Robert Binghurst's _Elements of Typographic Style_)
>
>  There should be a separate flag (break_lines?) to control whether
>  the text should be automatically be line-broken or not. This is
>  especially important becaues often labels will be too narrow to look good
>  filled - so line breaking without filling is quite desirable.

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

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.

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 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?

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

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


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

(My guess is that neither of these issues are worth losing much sleep over.)





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?


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

Jeff