On Fri, Jun 20, 2014, Tadziu Hoffmann wrote: > > > - provides sensible float handling > > - can be captioned and labelled > > Wouldn't it be useful to split off that functionality into > a separate float handler, to have available also for tables > and pic diagrams, and provide a bare-bones PDF image includer > à la PSPIC instead?
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? > > It would be exceptionally nice if groff natively handled > > images in formats other than ps and pdf, but I don't think > > that's going to happen any time soon. For now, it's .ps, > > or .pdf, or nothing. Not a huge issue with 'convert'. > > True. For vector graphics, there really isn't much choice -- > you have PS/PDF and SVG (and some not-so-often used formats > such as HPGL and CGM and various CAD formats), so you > just stick to the most common and support that. For raster > graphics there's quite a large number of commonly used formats > (GIF, PNG, JPEG, PBM/PGM/PPM, TIFF, BMP, ...) and it seems > rather ambitious to support them all. I'd probably vote for > keeping groff small and doing the conversion with specialized > external programs instead. Performing conversions on-the-fly > by repeatedly calling external programs while running groff > strikes me as wasteful, since I'd be formatting a document > quite a number of times while writing it, and I'd probably > be too impatient to wait the extra few seconds... Completely agree. That "it would be nice" doesn't mean "it would be practical". :) -- Peter Schaffter http://www.schaffter.ca
