groff
[Top][All Lists]
Advanced

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

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


From: Robin Haberkorn
Subject: [Groff] [mom][patch] FLOAT bug fixes
Date: Thu, 12 Sep 2013 22:59:11 +0200

Dear groffers,

I have found and fixed two severe mom bugs in the FLOAT macro. See
attachment - it's a patch against CVS HEAD.

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

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. Restoring \n[dn] after NEWPAGE doesn't help though.
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.
The forced FLOAT will then be printed properly by the HEADER trap.

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

Best regards,
Robin

Attachment: float_fixes.patch
Description: Binary data


reply via email to

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