Re: [Groff] Formatting algorithm

[Clarke Echols]

Whatever you do, don't do what Microsoft and relatives do by *assuming*
a block of text in one line is a paragraph, and you can't write a
paragraph as a series of shorter single lines.

Word was written for idiots who don't want to learn anything they don't
have to, and it drives me nuts!

I do all of my text work with vim and groff.  I've never attempted TeX
or LaTeX, though I've seen it and we used it as a back-end for producing
a lot of manuals at HP in the 1980s and '90s.  I wasn't involved in the
associated software my co-workers developed at all.

I've even used AT&T troff to create artwork for manufacturing printed
circuit boards by writing some useful macros.  It's amazing what can be
done with groff.

Clarke

On 04/14/2014 09:56 AM, Denis M. Wilson wrote:
> Brave statement -- good luck!
>
> Unlike TeX, troff has no modes, so a method of delimiting a paragraph has to
> be introduced. Text outside would be treated as currently, text inside would
> be subject to whatever algorithm is selected.  Some care to get this right
> should be taken, as for macro sets to take advantage of this some rewriting
> will be required anyway.
>
> What does Heirloom troff do?
>
> I have long wished for a shaped paragraph facility, it would make many tasks
> so much easier. Could this be incorporated? Unless paragraphs with holes were
> required, it would just be required to specify a sequence of
> (indent, line length) pairs.
>
> Denis
>
> On Mon, 14 Apr 2014 13:14:58 +0200
> Ulrich Lauther <address@hidden> wrote:
>
> > On Mon, Mar 31, 2014 at 07:44:07PM -0400, Peter Schaffter wrote:
> > > Here's the bare bones version of the algorithm I was thinking of
> > > when I proposed improving line formatting by getting groff to
> > > shoulder the burden for some of the work we do manually.  It's
> > > written out in brute-force pseudo-code; should be pretty clear.
> > >
> > > The aim is not to find optimal breaks in Knuthian fashion, but to
> > > improve the uniformity of grey from line to line using a greedy
> > > algorithm.  Key features are that letterspacing and wordspacing are
> > > orthogonal, and that NextWord can be read during optimization.
> > Even if a greedy algorithm will be implemented, it should have
> > the whole paragraph available as input.
> > That way, one could easily switch over to a KP-implementation and
> > compare the two appraoches in terms of quality, running time, and
> > code complexity.
> > Provided a clean interface and input/output specifications are
> > available I would volunteer to implement the dynamic programming (KP)
> > variant.
> >
> > Kind regards,
> >
> >       ulrich lauther