Hello, Jeremias! You wrote to <[EMAIL PROTECTED]> on Mon, 21 Jul 2003 14:02:36 +0200:
JM> Hello Ivan JM> You're right, this could be a way to go. But I'm not sure if this JM> approach is supported by all PostScript printers, especially the HP JM> ones where quite a few things are special. So basically it comes JM> down to the problem of being able to test on various printers. I can JM> test the current code using GhostScript. I'm not so sure about JM> device control stuff like "PageSize". Sooner or later we will have JM> to implement some kind of PPD support but until then I think we JM> should keep on the safe side. So your subclassing looks fine to me. JM> I'm open to suggestions on how to improve on it in the redesign. JM> Anyone interested to write a PPD parser? Just do a simple test. Here is a dummy FO: <?xml version="1.0" encoding="UTF-8"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format";> <fo:layout-master-set> <fo:simple-page-master master-name="page" page-height="185mm" page-width="255mm"> <fo:region-body margin-top="0mm" margin-left="0mm" margin-bottom="0mm" margin-right="0mm"/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence master-reference="page"> <fo:flow flow-name="xsl-region-body"> <fo:block linefeed-treatment="preserve" white-space-collapse="false"> Futurama: Using Java Technology to Build Robots That Can See, Hear Speak, and Move Steve Meloan July 2003 Robotics is playing an ever greater role in our world -- from industrial assembly 'droids performing the most mundane of tasks, to search-and-rescue robots saving lives in the depths of collapsed buildings, to interplanetary exploration robots probing the vastness of space. Such robots increasingly take on tasks that are too boring, costly, or dangerous for human beings to perform. But to develop robotic systems that are efficient and cost effective, we need a technology infrastructure that is both robust and future-proof. In a world of increasingly diverse devices and operating systems, with wildly differing hardware capacities and designs, it's essential that a robotics infrastructure be device-neutral and platform-neutral. After all, in the world of space exploration, the contractor for a given system can change at the stroke of a politician's pen. When early explorers of the moon experienced a breakdown in their equipment, their technical manuals reportedly advised them -- should all other diagnostic techniques fail -- to "kick with lunar boot." But for a robotic Mars rover sitting on an alien planet 141 million miles from Earth, there's no one there to do the kicking. A red planet robot in search of alien life can't afford the blue screen of death. </fo:block> </fo:flow> </fo:page-sequence> </fo:root> Render it into PS, now run Adobe and get an PDF. What you can see. The document size is default (letter or A4, depend on the local settings). But I specify that document must be 185mm by 255mm. If you incorporate changes, which I am talking about, the result document will have the size specified and will be rendered properly. By the way any single PS printer will do rotation and matching document to the paper, or at least it will throw an error about paper mismatch. And one more, the PS file which is produced by PSRenderer can't be printed directly to the printer, it is required post processing. My point is, when document rendered it must be rendered according to the specified size, and when you print it, you process PS file again and specify which media to use. --- Yours sincerely, Ivan Latysh. Ivan[a]yourmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
