groff
[Top][All Lists]
Advanced

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

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


From: Peter Schaffter
Subject: Re: [Groff] [mom][patch] FLOAT bug fixes
Date: Fri, 13 Sep 2013 02:38:45 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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