groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: One Page Dungeon Layout in groff?


From: Ralph Corderoy
Subject: Re: One Page Dungeon Layout in groff?
Date: Mon, 15 Aug 2022 11:20:10 +0100

Hi Laurens,

> Sorry to bombard you with my questions ... 

Not a problem; you're clearly making steady progress on things you're
not asking so it's not as if you're not making an effort and just asking
everything which crops up.

> The problem about resetting line length I got partially figured out.
> While -ms resets stubbornly resets .ll with every paragraph, I can
> reset .LL, so this kind of works.

Yes, -ms has .PO and .LL and their value is used at various times to
influence the .po and .ll settings.  It's all a bit messy when you have
to start changing the variables mid-page.

At the moment, I don't think -ms is giving you much so you may wish to
ditch it and do everything yourself, e.g. have you own ‘heading’ macro.
Or you may know heavy future use of -ms is intended.

> However when resetting the margins after the map, some text gets put
> out still with the shorter line length ... hm ...

Yes.  That's where I got to when editing your first opd.tgz attachment.
:-)  The cause is explained in §6 of CSTR 54.

   ‘The maximum line length for fill mode may be set with ll.
    ...
    The effect of ll, in, or ti is delayed, if a partially collected
    line exists, until after that line is output.’

The first line output after the image is correctly at the left-hand edge
of the page but the longer line length hasn't yet taken effect.

The solution is to use two ‘.wh’ traps with the first catching a line's
height before the end of the image.

    .wh \\nbu-1v opdEM1
    .wh \\nbu    opdEM2

I also noticed most of your numbered-list items have two lots of
numbers.  :-)

In playing around, I switched to groff producing a PDF with .PDFPIC but
this showed a couple of problems on my old system...

First, pdfinfo(1) was writing a NUL byte as part of the name of the PDF
produced by ImageMagick's convert(1) and that caused grep to just say
the file matching instead of giving the image's dimensions.  Switching
to gm(1)'s convert avoided this.

Second, gropdf(1) chokes on gm PDF with

    PDF Dict Key 'endstream' does not start with '/'

so I filter gm's output through ps2pdf(1) first.

It's still quicker overall than going through PostScript with an EPS
map.

    dungeon.pdf: dungeon opd.tmac map.pdf
            groff -U -Kutf8 -Tpdf -ms opd.tmac dungeon >$@

    map.pdf: map.png
            gm convert $< tmp.pdf
            ps2pdf tmp.pdf $@

PDFPIC here requires -U; that requirement may have gone in a later
groff.

-- 
Cheers, Ralph.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]