[Groff] [mom][patch] multipage boxed tables

[Robin Haberkorn]

Dear groffers,

I ported the ms package's tbl macros, specifically the multipage boxed
table support, to Mom.
It appears to work fine so far, but I'm neither a groff nor a -ms guru yet.
There are possibly some bugs that could be easily avoided by someone
who is more familiar with the ms macros.
That's why I'm writing you this - instead of mailing it to Peter directly.

For instance, why does the tbl@print-header macro change the
environment before printing the diversion? Shouldn't be everything
already be formatted in an environment-independent way when the
diversion is created? Or do I have to expect transparent throughputs
(\! and the like) generated by tbl? What exactly is in a diversion -
after all it's not a macro?
Also have a look at the other comments I added.

See attached patch. It's diffed against CVS HEAD.

Best regards,
Robin


multipage_boxed_tbl.patch
Description: Binary data

Re: [Groff] mom without page numbers

[mikkel meinike]

Thank you guys. If I had remembered that page numbering was called
pagination i might have found it :-).

Mikkel
Den 13/09/2013 03.18 skrev "Peter Schaffter" :

> On Thu, Sep 12, 2013, Mikkel wrote:
> > Dear Groff users
> > It may well be that I haven't been looking long enough, but have been
> > looking and I have not been able to
> > figure out how to remove the automatic page numbering in mom. Can
> > anyone help me?
>
> .PAGINATE OFF
>
> --
> Peter Schaffter
> http://www.schaffter.ca
>
>

Re: [Groff] [mom][patch] FLOAT bug fixes

[Peter Schaffter]

On Thu, Sep 12, 2013, Robin Haberkorn wrote:
> 1) if a "FLOAT FORCE" block fits on the current page, the register
> #FORCE is not removed/reset. If it does not fit on the page, a NEWPAGE
> is emitted and #FORCE is removed.
> This results in the FLOAT immediately following a "forced" FLOAT
> (fitting on its page) being treated as a forced FLOAT as well, even if
> it isn't a forced FLOAT. I think Peter will understand...

Good catch.

> 2) "forced" FLOATs that do NOT fit on the current page are formatted
> strangely. At least if they contain `pic`-processed code, the picture
> is formatted at very top of the new page with everything else (like
> captions from the same FLOAT and running text) being layed over the
> picture.
> Apparently the diversion (FLOAT*DIV) cannot be reproduced properly
> after breaking to the new page. I could not find the root cause of
> this, but perhaps it has something to do with \n[dn] being reset after
> the NEWPAGE call.

No, it's nothing like that.  The problem stemmed from one of those
.ns/.rs situations another user posted about recently.  The effect
of .ns wasn't being cancelled, with the result that text following
the float wasn't being spaced down to below the float.

> I worked around this. Instead of emitting the FLOAT*DIV in the FLOAT
> macro call for forced FLOATs that do not fit on their page, I let them
> be added to the deferred float list (FLOAT*DIV:\n[defer]), just like
> ordinary deferred FLOATs, and then issue a NEWPAGE.

There are actually a couple of ways to have solved the problem, but
this makes all kinds of sense and is the cleanest.  There's no
reason to treat a forced float that doesn't fit on the page any
differently than a defered float.

> I'm in a hurry, so no test case this time.  If you do need one,
> just say so.

I tested the patch with floats containing text, tbl, pic, and
PDF_IMAGE.  Everything looks good.

Along the way, I fixed an oversight in defered float handling in
HEADER.  The SHIM that comes after outputting the float requires the
current .v to be #DOC_LEAD, but since HEADER is still in the
PAGE_TRANSITION environment, .v is nominally 12000u.  It's reset to
#DOC_LEAD now.

I'll commit the changes shortly.

-- 
Peter Schaffter
http://www.schaffter.ca