Re: [Groff] EPS vs PDF support in MOM
On Monday 03 Dec 2012 11:48:15 Kobus Botha wrote: The problem I have now is that PDF_IMAGE does not act as a replacement for PSPIC The reason the pdf driver for groff cannot behave like pspic is because groff has no way of knowing the media size of the pdf graphic which you are importing. For postscript it has a request .psbb which returns the bounding box of the postscript file, there is no equivalent for pdf files, and would be extremely difficult to implement for pdf files. In addition the BoundingBox of a postscript file is not the same as the MediaBox of a pdf file, the former describes the extent of the drawn strokes, while the latter describes the size of the media upon which the pdf graphic is stroked. Imagine a logo centred with a transparent centimetre border around it, the bounding box and media box would be different. Due to the above it is not even possible to use ghostscripts bbox device on the pdf graphic since this will give the extent of the strokes, not the actual size of the media. A tool such as pdfinfo will tell you the page size of the pdf file, and once you have this data you are in business. To use pdf included graphics you must tell groff the actual height of the graphic you want to embed in the document (so that it can continue flowing text after the graphic), the width will be set in proportion to the height you specify. I use this little macro as a helper. The flag parameter can be -L (left) -C (centred) or -R (right) control allignment within the current line length. (Caution: the right and centre flags have a bug in current versions of gropdf, it may not do quite what you want!!). \# params fname flag height .de PDFPIC_HEIGHT .sp -.6v .ne 0\\$3+1v \\X'pdf: pdfpic \\$1 \\$2 0 \\$3 \\n[.l]z' .sp 0\\$3-.3v .ne 1v .. You can use it with a call such as:- .PDFPIC_HEIGHT ChuzLogoPlain.pdf -L 5c Which would include the pdf scaled so that it was a height of 5cm (and its width proportionally scaled), left alligned. If there is insufficient room on the current page it will throw to a new page and place the graphic at the top. I have not tested this in conjunction with the MOM macros. Using the information from pdfinfo, and a bit of arithmetic, you can use this macro to control the width of the graphic as well by calculating what height would provide the desired width using the page proportions provided by pdfinfo. Cheers Deri
[Groff] EPS vs PDF support in MOM
Hi I've been using groff for generating reports which can contain screenshots with the MOM macros. I used the groff currently in the Ubuntu repos which does not include pdfmom. The eps images worked well except for the time taken to build the pdf due to the size of the eps files which are in the order of 70MB after conversion from a png of 70KB. I then discovered the -compress option in convert, only to discover that eps2 is not currently supported. I then thought that getting pdfmom will solve my problems and e-mailed Peter Shaffter and he helped me to get pdfmom working. The problem I have now is that PDF_IMAGE does not act as a replacement for PSPIC and I want to know if the current development snapshots of groff supports eps2? The problem I have with PDF_IMAGE is that it treats images like floats... Mom treats images inserted into a document with PDF_IMAGE like floats, which is to say that if the image doesn’t fit on the output page, she will defer it to the top of the next page while continuing to process running text. ADJUST is ignored whenever an image is deferred, and a message is printed to stderr advising you where the deferment has taken place. For my use the position of the image is critical and I can't see a way of preventing this behavior. So, maybe sticking to eps is the best idea, if there is a way to bring down the size of the eps images. Is there any way to do this?
Re: [Groff] EPS vs PDF support in MOM
Kobus -- On Mon, Dec 03, 2012, Kobus Botha wrote: The problem I have now is that PDF_IMAGE does not act as a replacement for PSPIC and I want to know if the current development snapshots of groff supports eps2? I just did a quick test, converting a 23K .ps image to .eps2 with 'convert'. The resulting 12K file processed fine with PSPIC under an up-to-date groff and the command line pdfmom -Tps ... The problem I have with PDF_IMAGE is that it treats images like floats... Mom treats images inserted into a document with PDF_IMAGE like floats, which is to say that if the image doesn’t fit on the output page, she will defer it to the top of the next page while continuing to process running text. ADJUST is ignored whenever an image is deferred, and a message is printed to stderr advising you where the deferment has taken place. For my use the position of the image is critical and I can't see a way of preventing this behavior. I'm not sure which part of the behaviour is problematic, given your concerns. If there isn't sufficient room for an image, groff either has to ignore it completely, or output it when space becomes available (ie top of the next page). If neither is acceptable, the only solution, under groff/mom, is to tweak the page on which the image is to appear until there's enough space to hold it. If the problem is that ADJUST is ignored when an image is defered to the top of the next page, you cannot raise the image above the top margin, but you can lower it to any acceptable position on the page by wrapping PDF_IMAGE inside a float and using the .SP macro or the .sp request inside the float. If the overall problem is the shimming that takes place underneath the image (which adds enough space to ensure the next line of output falls on a valid baseline), that behaviour can be disabled by inserting .NO_SHIM prior to the image. If it's something else, let me know. -- Peter Schaffter Author of The Binbrook Caucus http://www.schaffter.ca
