Peter Schaffter <pe...@schaffter.ca> 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. >