Re: One Page Dungeon Layout in groff?

[Deri]

On Tuesday, 16 August 2022 10:18:17 BST Ralph Corderoy wrote:
> > Interestingly if you use the command "convert file.png file.pdf" a
> > valid pdf is produced which works with gropdf.
> 
> That was Laurens' original command but I found the convert(1) here
> sticks an ASCII NUL after the title, which pdfinfo pipes to grep which
> stops the dimensions being extracted by gropdf.

Hi Ralph,

Yes, it uses UTF-16 in the string as well. However, using the git version of 
PDFPIC it now works with the Ascii Null, I think Branden added a filter for 
the nulls to the pdfinfo command in January.

Cheers 

Deri

Re: One Page Dungeon Layout in groff?

[Dave Kemper]

On 8/15/22, Ralph Corderoy  wrote:
> First, pdfinfo(1) was writing a NUL byte as part of the name of the PDF
> produced by ImageMagick's convert(1)

This has been reported as a bug
(http://gitlab.freedesktop.org/poppler/poppler/-/issues/776) but
doesn't seem universally regarded as such by the poppler team.
Comment there if you want to lobby for it.

> and that caused grep to just say
> the file matching instead of giving the image's dimensions.

This happens with groff 1.22.4 (the only released groff that includes
pdfpic), but has since been fixed in
http://savannah.gnu.org/bugs/?58206.  So if you compile your own groff
from the git bleeding edge, this shouldn't be an issue.

Re: One Page Dungeon Layout in groff?

[Ralph Corderoy]

Hi Deri,

> It starts a hash with "<<" but fails to close it with ">>". Each hash
> entry is a key/value pair where the key is preceded by a "\". The
> endstream should follow after a stream but that is missing.

Thanks for digging deeper.

> Interestingly if you use the command "convert file.png file.pdf" a
> valid pdf is produced which works with gropdf.

That was Laurens' original command but I found the convert(1) here
sticks an ASCII NUL after the title, which pdfinfo pipes to grep which
stops the dimensions being extracted by gropdf.

$ convert map.png map.pdf
$ pdfinfo map.pdf | sed -n l
 →  Title:  map\000$
Producer:   https://imagemagick.org$
CreationDate:   Tue Aug 16 10:16:59 2022 BST$
ModDate:Tue Aug 16 10:16:59 2022 BST$
Tagged: no$
UserProperties: no$
Suspects:   no$
Form:   none$
JavaScript: no$
Pages:  1$
Encrypted:  no$
Page size:  1440 x 1440 pts$
Page rot:   0$
File size:  127000 bytes$
Optimized:  no$
PDF version:1.3$
$ pdfinfo map.pdf | grep 'Page size'
Binary file (standard input) matches
$

That's why I moved from convert(1) to gm(1) only to hit a new problem.
:-)

-- 
Cheers, Ralph.

Re: One Page Dungeon Layout in groff?

[Deri]

On Monday, 15 August 2022 11:20:10 BST Ralph Corderoy wrote:
> 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.

I created a random png to pdf with gm convert and it produced a pdf which 
caused the same error message. Running "qdf --check" on the pdf produced 
several messages:-

checking AJ.pdf
PDF Version: 1.2
File is not encrypted
File is not linearized
WARNING: AJ.pdf (object 11 0, offset 10197): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10207): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10219): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10227): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10234): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10261): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10281): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10301): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10321): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10341): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10361): unknown token while reading 
object treating as string
WARNING: AJ.pdf (object 11 0, offset 10361): too many errors; giving up on 
readng object
WARNING: AJ.pdf (object 11 0, offset 10364): expected endobj

So, the problems are with object 11 in the pdf. Here it is:-

11 0 obj
<<

endstream
endobj

It starts a hash with "<<" but fails to close it with ">>". Each hash entry is 
a key/value pair where the key is preceded by a "\". The endstream should 
follow after a stream but that is missing. In fact object 11 is not referenced 
by any other object in the file so could be dropped completely, which is 
probably what ps2pdf has done.

Interestingly if you use the command "convert file.png file.pdf" a valid pdf 
is produced which works with gropdf. It may also give a clue what object 11 
was intended to be. In the valid pdf it is specified as a thumbnail of the 
embedded image, but because it is just a single pixel it does not fulfill its 
role very well!

Laurens Wrote:-

> true, it's quicker, converting the postscript to pdf takes longer then the
> actual formatting. I found the quality of the convert map somewhat lacking
> in the pdf example, though. I'll probably stick to what I've got.

Does the map have to be a png? If it can be produced in a vector format, i.e. 
svg, postscript, or even built using groff draw primitives, it will 
considerably improve the quality of the map and substantially reduce the size 
of the pdf produced.

Cheers 

Deri

Re: One Page Dungeon Layout in groff?

[Ralph Corderoy]

--- Begin Message ---
It's working nicely now! Yay!

Am Mon, Aug 15, 2022 at 11:20:10AM +0100 schrieb Ralph Corderoy:
> 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 $@

true, it's quicker, converting the postscript to pdf takes longer then the 
actual formatting. I found the quality of the convert map somewhat lacking in 
the pdf example, though. I'll probably stick to what I've got.

But even with the postscript variant, 1.5 seconds including all conversions is 
still much faster than LaTeX. I'm curious how this will work out for longer 
texts.

Best,

L.

-- 
Have this adventurer for your next game:
Sarah is a boatbuilder
STR 8  INT 8  WIS 8  DEX 12  CON 5  CHA 6  
HP 4  50 gp

--- End Message ---

Re: One Page Dungeon Layout in groff?

[Ralph Corderoy]

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 \\nbuopdEM2

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.

Re: One Page Dungeon Layout in groff?

[Ralph Corderoy]

Hi Laurens,

> I'll lo ok at setting up some traps :D

The tutorial at the end of Ossanna and Kernighan's CSTR 54 uses ‘.wh’.
https://troff.org/54.pdf

> Is there a way to preserve the extra wide page offset while next to
> the image ? The regular paragraph macros seem to reset PO whenever
> they get called?

You're using ‘.in’ which is setting the indent.  There is also ‘.po’ to
set the page offset.  I don't know which paragraph macros you're
referring to unless you give the macro set you're using, e.g. ‘-ms’.
The one I quickly tried didn't much with the indent or page offset.
Perhaps attach the whole source file, macros and the text which uses
them.

-- 
Cheers, Ralph.

Re: One Page Dungeon Layout in groff?

[Laurens Kils-Hütten]

Am Sun, Aug 14, 2022 at 12:25:31PM +0100 schrieb Ralph Corderoy:
> You might want to turn off the adjusting of space [...] 

yay, will look into those spacing issues ...

> You could play with setting a trap, sounds right up your street!, WHen
> output reaches a vertical position with ‘.wh’ to remove the large
> image-skipping indent once we've passed its bottom.  This would allow
> the ‘General description’ paragraphs to flow back to the left.

right, this is exactly what i meant to do. only i didn't know how. so I'll look 
at setting up some traps :D

Is there a way to preserve the extra wide page offset while next to the image? 
The regular paragraph macros seem to reset PO whenever they get called?

thanks a bunch!

~lkh

-- 
One planet is all you get.

Re: One Page Dungeon Layout in groff?

[Ralph Corderoy]

Hi Laurens,

> Here's my proof of concept: https://ttm.sh/qhr.png

You might want to turn off the adjusting of space between words which is
giving a straight edge to the end of lines: ‘.na’.  This would remove
the varying space before ‘Goblins’ and ‘Orcs’, which looks odd to me.

A non-breaking space is ‘\~’ and would stop ‘HD 1-1’ being split across
lines.

Look out for the number of spaces you use; whitespace is significant in
troff input, e.g. the gap between ‘concept. The’ looks too small as if
troff doesn't know it's the end of the sentence.  Indicate this by
either ending the input line after ‘concept.’ or typing two spaces.

You could play with setting a trap, sounds right up your street!, WHen
output reaches a vertical position with ‘.wh’ to remove the large
image-skipping indent once we've passed its bottom.  This would allow
the ‘General description’ paragraphs to flow back to the left.

-- 
Cheers, Ralph.

Re: One Page Dungeon Layout in groff?

[Laurens Kils-Hütten]

So, I learned quite a bit today, thanks for the pointer to the archives.

Here's my proof of concept: https://ttm.sh/qhr.png

.\" Macros to typeset One Page Dungeons
.\" in groff
.\"
.de opdMap\" start with the map
.br
.mk a \" Mark current position
.PSPIC -L \\$1 4i \" insert map image 4 inches wide
.br
.mk b \" Mark lower edge of map
..
.de opdSB \" start the side bar
.sp |\\nau\" move back to mark a
.in +4.2i \" increase indent by 4.2 inches
. \" left margin is now just right 
. \" of the map
.ft R
..
.de opdH \" section header for opd stuff
.sp 1v
.ft B
..
.de opdLB \" opd begin entries
.ft R
.in +1.3
.br
..
.de opdLI \" opd list entries
.br
.ti -1.3
..
.de opdLE \" opd end list
.in -1.3
.br
..
.de opdEN \" end of special opd stuff
.br  \" break line, just to make sure
.sp |\\nbu   \" move to mark b
.\" that's the lower edge of the map
.\" we marked above
.sp 1v
..

-- 
https://octodon.social/web/@lkh
xmpp: l...@jabber.de
IRC: lkh on Libera.chat and others
Signal: +491627291956
Discord: lkh#2319

Re: One Page Dungeon Layout in groff?

[Laurens Kils-Hütten]

Am Sat, Aug 13, 2022 at 11:11:07AM +0100 schrieb Ralph Corderoy:
> Laurens wants to use an image for the map.  I think he just wants to
> flow text around a top-left image on a page.

Exactly, thanks Ralph, I'm sure there is a proper name for this kind
of layout ... 

> It's popped up before.
> https://lists.gnu.org/archive/html/groff/2013-01/msg00039.html is one
> thread and the second post refers back to an earlier one.  

I'll check that out!

Cheers,

lkh

-- 
Laurens Kils-Hütten
https://sdf-eu.org/~lkh

Re: One Page Dungeon Layout in groff?

[Ralph Corderoy]

Hi John,

> > | dungeon. Basically it's a|
> > | page, with one top-left  |
> > | aligned image and text   |
> > | floating around the image.   |
>
> This is what pic(1) 
> is for:

Laurens wants to use an image for the map.  I think he just wants to
flow text around a top-left image on a page.

It's popped up before.
https://lists.gnu.org/archive/html/groff/2013-01/msg00039.html is one
thread and the second post refers back to an earlier one.  It may be
more list-archive searching hones in on a solution, though Laurens
top-left-corner requirement seems the easiest layout.

-- 
Cheers, Ralph.

Re: One Page Dungeon Layout in groff?

[John Gardner]

This is what pic(1) <https://en.wikipedia.org/wiki/PIC_(markup_language)>
is for:

# Long version
$ pic < dungeon.roff | troff -Tpdf | gropdf > map.pdf

# Concise version (recommended)
$ groff -p -Tpdf dungeon.roff > map.pdf

If you're new to pic(1), there's a browser-friendly (albeit limited)
reimplementation of the program called Pikchr <https://pikchr.org/home>
that supports live rendering <https://pikchr.org/home/pikchrshow>. Good for
practice, but poor for troff-quality output.

Regards,
— John

On Sat, 13 Aug 2022 at 18:57, Laurens Kils-Hütten  wrote:

> Hello dungeon delving GNU people,
>
> I hope it's fine to write a lengthy request like the following
> as a first post to this list. If not, please be so kind and
> advise me, where I should have asked instead. That said, here
> goes my question:
>
> Yesterday I once more discoverered, how ridiculously fast groff
> is compared to other typesetting toolchains like LaTeX, Python +
> weasyprint or whatever.
>
> Since I enjoy using fast UNIX tools to build some dungeons in my
> spare time, I wonder how much work it'll take to reproduce the
> classic One Page Dungeon layout in groff. Just in case you don't
> know, the layout would simply look like this:
>
> ---
> | ---  Table with  |
> ||   | random  |
> ||  Map of the   | encounters, |
> ||   | various |
> ||Dungeon| general |
> ||   | descriptions|
> || Level | of the level|
> ||   | And finally |
> | ---  a key with  |
> | descriptions of each |
> | individual room of the   |
> | dungeon. Basically it's a|
> | page, with one top-left  |
> | aligned image and text   |
> | floating around the image.   |
> | That shouldn't be too hard.  |
> | Nothing fancy really ... |
> 
>
> The text might extend to the facing uneven page, thus creating a
> two page spread for the level.
>
> Of course I tried what groff seems to deliver out of the box, but
> I find that displays typically use up a page width, or column
> width, with text continuing below the image, but not floating
> around the image like i've shown.
>
> So, any ideas how to do this in groff? Maybe one of the common
> macro packages already supports this kind of layout, only I
> haven't discoverered it, yet?
>
> Thanks in advance,
> cheers,
>
> ~lkh
>
> --
> https://sdf-eu.org/~lkh
>
>

One Page Dungeon Layout in groff?

[Laurens Kils-Hütten]

Hello dungeon delving GNU people,

I hope it's fine to write a lengthy request like the following 
as a first post to this list. If not, please be so kind and 
advise me, where I should have asked instead. That said, here
goes my question:

Yesterday I once more discoverered, how ridiculously fast groff
is compared to other typesetting toolchains like LaTeX, Python +
weasyprint or whatever.

Since I enjoy using fast UNIX tools to build some dungeons in my
spare time, I wonder how much work it'll take to reproduce the
classic One Page Dungeon layout in groff. Just in case you don't
know, the layout would simply look like this:

---
| ---  Table with  |
||   | random  |
||  Map of the   | encounters, |
||   | various |
||Dungeon| general |
||   | descriptions|
|| Level | of the level|
||   | And finally |
| ---  a key with  |
| descriptions of each |
| individual room of the   |
| dungeon. Basically it's a|
| page, with one top-left  |
| aligned image and text   |
| floating around the image.   |
| That shouldn't be too hard.  |
| Nothing fancy really ... |


The text might extend to the facing uneven page, thus creating a
two page spread for the level.

Of course I tried what groff seems to deliver out of the box, but
I find that displays typically use up a page width, or column
width, with text continuing below the image, but not floating
around the image like i've shown. 

So, any ideas how to do this in groff? Maybe one of the common
macro packages already supports this kind of layout, only I
haven't discoverered it, yet?

Thanks in advance, 
cheers,

~lkh

-- 
https://sdf-eu.org/~lkh