[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
Re: [Groff] space width, Tadziu Hoffmann, 2014/01/27