Re: [Groff] Letterspacing

[hohe72]

Peter Schaffter <address@hidden> wrote (Thu, 27 Mar 2014 19:29:13
-0400):
> On Thu, Mar 27, 2014, Tadziu Hoffmann wrote:
> > 
> > > So there are two readily-available methods: varying
> > > letter-spacing, or varying inter-word spacing.
> > 
> 
> Not "or" -- "and".  Most times, I opt for word-spacing adjustments.  
> The reason for my comparison was only to show that deft use of
> letterspacing goes unnoticed.  If I'd used all the other tricks, I'm
> sure I could have crafted a paragraph to make even the most die-hard
> TeX fanatic weep.  As could we all. :)
> 
> > Overall, I think I'm with Werner on the issue of letterspacing.
> > I usually find it visible (and irritating), but I can tolerate
> > rather large amounts of word-spacing.
> 
> By letterspacing, I mean both tightening and loosening.  Sounds as
> if you're talking about loosening only.  Either way, if you can see
> it, it's because it's been done badly.  That's the point I was
> demonstrating.
> 
> The other reason for the comparison was to get this very discussion
> started.  How do we go about improving justified text?  Doug's
> comments got me thinking.  We all agree groff's paragraph formatting
> needs an overhaul, but is Knuth the right way to go?  Should it be
> mentioned as a specific goal in the mission statement?
> 
> I have nothing but my gut to go on here, but my strongest feeling is
> that there's a simpler way.
> 
> Groff uses a greedy, line-by-line approach to justifying text
> (hereafter, I'll use "formatting lines" instead of "justifying
> text"):
>   - collect words until the line-length is reached/exceeded
>   - look for legal breakpoints (spaces after words, hyphenation
> points)
>   - choose the rightmost breakpoint that does not exceed line-length
>   - expand spaces till the full measure is reached
>   - break the line

user: What's being easier to understand in the case of page break.

> When groff doesn't "get it right", we see lines with overlarge
> wordspaces, which we fix by adjusting word- and letter-spacing
> (and, very occasionally, glyph width).

user: hyphenation (with the risk of spell checking blindness)

> KP posits that the solution to getting it right is to scan the
> whole paragraph.  The number of words on each line is determined by
> choosing a line arrangment for the whole paragraph that minimizes
> the sum of the squares of the spaces at the ends of lines.  IOW,
> an arrangement that strives to equalize wordspacing throughout the
> whole paragraph.
> 
> Overall, the principle is sound.  If we could wave a magic wand and
> get groff to do this, I doubt anyone would mind.  The problem is, as
> Gunnar Ritter reminded me: "...the task of rewriting large portions
> of an existing environment that assumes line based formatting."
> 
> KP works well with TeX because TeX was written from the start to
> implement it.  Groff wasn't.  When I step back from pie-in-the-sky,
> it's obvious that KP and groff aren't a mix, not without massive
> rewrites of a key part of the code.  Like Doug, I smell an increase
> in complexity that runs counter to simplicity, flexibility, and
> portability.

Maybe, parts of groff will be provided (libgroff) such that a semantic
markup approach will profit as well a paragraph-at-once one, without
interfering. Maybe that is the deadlock groff is actually in: first
that the code have to be overhauled to step forward, second that the
overhaul becomes the same to specific.

> I've been pondering this for a long, even raised the issue a few
> times.  Groff's line-at-a-time formatting isn't awful, otherwise we
> wouldn't be using the program.  It's fine for the majority of work
> people do, and have done over the years.  Its limitations show up
> in narrow-column work and fine typography, sure, but when they do,
> we use tools groff already provides to massage individual lines
> until our paragraphs look right, typically by adjustments to the
> word-spacing, and, in my case, letter-spacing as well.  The end
> result is often identical to a paragraph formatted by TeX.
> 
> In short, we work within the limitations of line-at-a-time
> formatting by doing manual line-at-a-time adjusting.  Which begs
> the question: is it really necessary to scan an entire paragraph
> to determine optimal linebreaks if judiciously adjusted word-and
> letter-spacing on a line-by-line basis can produce similar results?
> Would it not make more sense to have groff, more or less as-is,
> shoulder more of the burden of what we do manually, *using the same
> strategies*, to achieve better *lines*, rather than focussing on
> the whole paragraph?

typographic options: I can opt, but not judge. As long as it can
be enabled or disabled artificially.

so to say: People rather life a problem they cannot solve, than with a
solution they cannot understand. It however raises the question: Where
to go? Or maybe: How to go?

> I have some thoughts on how to approach this conceptually, which
> I'll post in a day or two.  Been at this too long already.
>