On Sat, Feb 01, 2014, hoh...@arcor.de wrote:
>
> Werner LEMBERG <w...@gnu.org> wrote (Wed, 29 Jan 2014 06:37:05 +0100
> (CET)):
> > 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).
>
> I think, that an author can prevent any such algorithm to succeed,
> especially orphans or enlarged space after periods. It's
> therefore better, to give us the tools and we're doing the job.
I do agree with this. Because we don't yet have perfect algorithms
to deal with the myriad aesthetic challenges posed by quality
typesetting, it is very important for users to be provided with
tools to roll their own solutions. Tools, moreover, that do not
require in-depth knowledge of groff's idiosyncratic, albeit
thoroughly-documented, primitives.
> My TODO list would look like that:
> ...
> - Underlining across line breaks.
Tadziu's solution to this, implemented for PostScript output in mom,
is to attack the problem at the PostScript level. Works like a
charm. And kind of shores up my argument, above, namely that users
should have a "tool" (in mom, the macro 'UNDERLINE') to deal with
problems--in this case, that '.cu' doesn't do what any sane person
would expect it to do for PostScript output--without having to delve
into the guts of groff.
> When I find the time to develop for groff, the first I do is, removing
> the auto ("we think for you") shrink feature of pic.
I'm unaware of this problem. In gpic, at any rate, the default box
width, for example, is 0.75 inches, and unless you give a width arg to boxes,
that's exactly the size they come out. Shrinking only occurs if you
give .PS a scaling argument.
--
Peter Schaffter
http://www.schaffter.ca
