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:simple-page-master master-name="page" page-height="185mm" page-width="255mm">
<fo:region-body margin-top="0mm" margin-left="0mm" margin-bottom="0mm" 
<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.

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.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to