[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] Letterspacing
Re: [Groff] Letterspacing
Sun, 30 Mar 2014 15:15:13 +0200
Peter Schaffter <address@hidden> wrote (Thu, 27 Mar 2014 19:29:13
> 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
> 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
> - collect words until the line-length is reached/exceeded
> - look for legal breakpoints (spaces after words, hyphenation
> - 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
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.
Re: [Groff] Letterspacing, Tadziu Hoffmann, 2014/03/26
Re: [Groff] Letterspacing, Peter Schaffter, 2014/03/27
Re: [Groff] Letterspacing, Steve Izma, 2014/03/27