On Sat, Jun 21, 2014, Ted Harding wrote: > > PDF_IMAGE was originally implemented that way, but over time, the > > advantages of treating images as floats, rather than requiring users > > to insert them into floats (which functionality is fully implemented > > separately, BTW), far outweighed whatever advantages I imagined > > would accrue from treating them as non-floated elements. Simply > > put, when would you *not* want images inserted into a document > > deferred to the next page when they don't fit on the current one? > > When it is important, for clear or easy understanding, to have the > image on the same page as text that refers to it!
My thinking originally, too, about PDF_IMAGE and floats. Seems obvious. But that's thinking like a writer, not a typesetting program. From the point of view of groff, when an image doesn't fit vertically on the page, it can only: a) cause a page break b) be ignored c) cause the program to abort d) bleed off the page e) be deferred Of these choices, e) is the preferred default behaviour since, if the image must be kept on the same page, all five options, including deferring... > ...mean re-writing or re-structuring the text whereas if keeping the image on the same page doesn't matter, it's an added formatting fussiness to wrap the image inside a pair of float macros. The only other reasonable candidate for no-fit handling is a), even though it leaves a gap at the bottom of the page. There may well be situations where that's desirable, in which case, mom users can always wrap images inside FLOAT and pass FLOAT the 'FORCE' flag. -- Peter Schaffter http://www.schaffter.ca
