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