Re: [Groff] space width

[hohe72]

Peter Schaffter <address@hidden> wrote (Sun, 2 Feb 2014 00:03:58
-0500):
> On Sat, Feb 01, 2014, address@hidden wrote:
> > 
> > Werner LEMBERG <address@hidden> 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.

.cu is a font switch, .UNDERLINE part of a macro package. I think of
adding a groff command to permanently overstrike text, like changing
color using \m[], and setting a overstrike char(s), as .defcolor does
for colors.

BTW, using long names to pick names out from AT&T original command set
scales very well. Should have had prefixed generally.

> > 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.

Have attached a sample. The feature prevents dimensional stability
without a warning and doesn't scale text making it useless. The
responsibility for borders and border borders should be mine.

Holger

pic-scaling.groff
Description: Binary data

pic-scaling.ps
Description: PostScript document

pic-scaling-down.ps
Description: PostScript document