() Rodolfo Medina () Tue, 03 Mar 2015 10:37:40 +0000 > Maybe some setting in the environment is the cause of the > weirdness. How can I check that? I don't know. It was idle speculation. Since then, i have looked at stampa.ps as converted to a PNG via: gm convert stampa.ps stampa.png and i see that the "half" that is cut off from the footer is the *upper* half! The footer text is clipped by the footer frame. So that excludes incorrect bounding box problems (due perhaps to improper paper size specification) in my mental model. Also supporting the theory that the paper size is indeed correctly specified are the stampa.ps lines: %%DocumentMedia: A4 595 842 0 () () %%PageMedia: A4 (where "A4" appears). Thus, there must be something else going on; paper size is a red herring... Since i don't even have gv installed on this computer, it looks like gv cannot be at fault, either. So, the only thing left is the postscript itself must be wrong. I see that in: (setq ps-print-footer t ps-print-footer-frame nil ps-top-margin 18 ps-bottom-margin 14 ps-left-margin 12 ps-right-margin 0 ps-print-header nil ps-show-n-of-n nil ps-print-footer-frame nil ps-footer-lines 1 ps-footer-offset 0) the var ‘ps-print-footer-frame’ is set to nil (twice!), yet stampa.ps line 217 obstinately reads: /PrintFooterFrame true def If you manually change the "true" to "false", then there is no footer frame and thus there is no footer frame clipping. So the bug lies in the failure of the Emacs Lisp code to propagate the Emacs Lisp variable ‘ps-print-footer-frame’ to the postscript definition of ‘PrintFooterFrame’. Or you could say, "one bug". Maybe there are others. But before you file a bug report, are you very sure that you evaluated the ‘(setq ...)’ form *before* generating stampa.ps? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) => nil