groff
[Top][All Lists]
Advanced

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

Re: [Groff] space width


From: Werner LEMBERG
Subject: Re: [Groff] space width
Date: Wed, 29 Jan 2014 06:37:05 +0100 (CET)

> Back in the day of standalone phototypesetters, eg. the mighty
> Linotronic or CompuGraphic's 8400, everything was line-at-a-time yet
> the results were almost always better than what can be achieved with
> groff.  The reason was that both word- and letter-spacing (track
> kerning) were used to auto-justify lines.  For each, min-opt-max
> values could be given, which would then be used to determine optimal
> breakpoints with the best overall grey to the line.

Letter-spacing is bad in general.  A better solution is font
expansion, as implemented e.g. in pdflatex.  Unfortunately, MM fonts
have been abandoned, since a width axis to expand or compress glyphs
horizontally without modifying the counter width would be exactly the
right thing for making the HZ algorithm work perfectly.  Here is a
short overview:

  http://www.tug.org/TUGboat/Articles/tb22-3/tb72thanh.pdf

Note that implementing the HZ algorithm in pdftex was the subject of
Hàn Thế Thành's thesis; you can read it here:

  http://www.pragma-ade.com/pdftex/thesis.pdf

> I'm wondering if that older approach wouldn't be the better way to
> go if, one day, groff gets an overhaul in this area.  I don't know
> the internals, but I'm thinking it might be easier to implement,
> since it's still line-at-a-time.

Practical experiments done by Thế Thanh have shown that font expansion
or compression must not exceed approx. 2% of the natural width to be
optically acceptable by high standards (MM fonts with a width axis
could use slightly larger values, BTW).  The same holds for letter
spacing, which I consider a poor-man's alternative to font expansion.
In other words, only a very small percentage of lines can be improved
by playing around with `.tkf' IMHO.  The final goal is to get a
uniform grayness on a page, and for this you *must* use a
paragraph-oriented algorithm.

Given today's memory abundance and the high velocity of CPUs, the
ideal route would be to implement a document-wide algorithm for
typesetting a document (in contrast to TeX's page-wide approach).
This could then handle widows and orphans gracefully, and produce
optimized positioning of floats (i.e., images, tables, etc.).
However, this is not a trivial task.  For example, it should also
gracefully handle the situation of two-column text, but with a
centered image on the page so that the text of the two columns flow
around it.  Ditto for the generalized case of arbitrarily placed
images in multi-column layout, or even non-rectangle image shapes.


    Werner

reply via email to

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