You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by IvanLatysh <Iv...@yahoo.ca> on 2003/07/20 23:06:20 UTC
PS Renderer.
Hello, Jeremias!
Recently I update the FOP , now I am having the fun with fop-0.20.5rc3a :-)
In the last release you add the future to automatic switch orientation (landscape,portrait).
Here is my IMHO.
Since rendered is dealing with the document, not with the media on the document prints on, it is making no sense to decision about document layout.
For example, the document have the dimension 10in * 5in. You would say that it is the landscape layout, but this document can be printed on the letter paper, portrait layout.
My point, it is an ambiguous decision to set page layout based on the page size when you don't know what kind of media are going to be used.
Some workaround:
According to "PostScript® LANGUAGE REFERENCE third edition."
[begin]
PageSize:
An array of two numbers, [width height], specifying the overall dimensions
of the physical medium that were assumed during the generation of this
page description.
[bla, bla, bla]
The PostScript interpreter
will set up the transformation from user space to device space so that
the longer and shorter dimensions specified by PageSize are properly oriented
with those of the physical medium.
[end]
Here is interpreter will do the trick to set the page layout based on the page dimensions,
because interpreter know about the media and about the document.
It making more sense to specify PageSize instead of the layout.
I did some experiments with it, and PageSize gives more realistic results.
For myself I wrap PDFRenderer into my class, and overload
>> public void renderPage(Page page)
method.
Looking forward to see your thought about.
---
Yours sincerely, Ivan Latysh.
Ivan[a]yourmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Awful problem with image cache.
Posted by IvanLatysh <Iv...@yahoo.ca>.
Hello, J.Pietschmann!
You wrote to <fo...@xml.apache.org> on Mon, 21 Jul 2003 21:43:49 +0200:
J> This is almost certainly an overstatement. Do you have measurements
J> on how much using a new Driver decreases overall performance
J> (including rendering) compared to resetting an used Driver object?
I don't have a numbers, but it looks like 2 longer.
>> By the way driver.reset() does not reset the Renderer.
J> Bug #1859. BTW it's the renderer which keeps references to your
J> image, not the image cache (after resetting it).
I know :-)
I am digging PSRenderer to fix it, if I have any luck, I will let people know about.
Just an observation, this problem is disappearing after 3,4 rendered pages.
---
Yours sincerely, Ivan Latysh.
Ivan[a]yourmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Awful problem with image cache.
Posted by "J.Pietschmann" <j3...@yahoo.de>.
IvanLatysh wrote:
> I have a singleton which returns one Driver all the time.
This is not a good idea. It is better to use a new Driver every time
because, as you experienced, reset() isn't reliable.
> it is dramatically decreasing performance.
This is almost certainly an overstatement. Do you have measurements
on how much using a new Driver decreases overall performance
(including rendering) compared to resetting an used Driver object?
> By the way driver.reset() does not reset the Renderer.
Bug #1859. BTW it's the renderer which keeps references to your
image, not the image cache (after resetting it).
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Awful problem with image cache.
Posted by IvanLatysh <Iv...@yahoo.ca>.
Hello, All!
I have a singleton which returns one Driver all the time.
This driver is using to render a series of the pages, and returns when done.
All this works fine, but after driver finish rendering the page it keep looked an image, not all of the images which were used, only one image.
For now I have to create and destroy the driver each time, it is dramatically decreasing performance.
Is there are any way to reset the driver after use.
Here is my release procedure:
driver.reset();
org.apache.fop.image.FopImageFactory.resetCache();
By the way driver.reset() does not reset the Renderer.
I create my renderer which is an empty class and set this renderer each time, when driver is resetting, but it does not help at all.
---
Yours sincerely, Ivan Latysh.
Ivan[a]yourmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: PS Renderer.
Posted by IvanLatysh <Iv...@yahoo.ca>.
Hello, Jeremias!
You wrote to <fo...@xml.apache.org> on Mon, 21 Jul 2003 19:59:19 +0200:
JM> I hear you. Incidentally, I've had the same problem reported to me
JM> via a different channel. Funny things happen.
JM> I've checked the PPD of the HP Laserjet 5. It supports the PageSize
JM> setting. So my reservation was a bit premature. Looks like your
JM> proposal shouldn't hurt.
We runs HPLaserJet III Si, HPLaserJet 5si and a few older models.
And we just got Xerox Phaser 7300.
All of them doing well with PageSize.
The PostScript reference says:
[begin]
Matching Requests with Attributes
The page device parameters include a special dictionary, InputAttributes, that describes
the attributes of all physical media available on the current output device.
Depending on the device, this information may either be discovered automatically
by the PostScript interpreter or configured manually by a human operator or
system administrator. The setpagedevice operator matches the media requirements
specified by the page description against the attributes described in the
InputAttributes dictionary to determine which media source to select.
The keys in the InputAttributes dictionary are integer position numbers representing
media sources on the device. The value associated with each key is a subdictionary
whose entries describe the attributes of the medium currently
available from that source. Entries in this subdictionary include PageSize,
MediaColor, MediaWeight, MediaType, MediaClass, and InsertSheet. These keys
have the same meanings as the correspondingly named page device parameters,
but they describe the actual attributes of the medium instead of the requirements
of the page description.
Note: All implementations of setpagedevice support input media selection by means
of the PageSize, MediaColor, MediaWeight, MediaType, MediaClass, and Insert-
Sheet attributes, whether or not the device can sense these attributes automatically.
On some devices, other attributes may also influence media selection; those attributes
can appear in the InputAttributes dictionary as well.
[end]
I propose to make following changes:
Class PSRenderer:
/**
* String with additional Page Device parameters.<br/>
*/
protected String pageDeviceParameters;
/**
* Return Page Device Parameters string or null if not set.
*
* @return Page Device Parameters
*/
public String getPageDeviceParameters() {
return pageDeviceParameters;
}
/**
* Set Page Device Parameters.<br/>
* The string will be added to the page setup section.<br/>
* For Example:<pre>/Duplex true<br/>/Tumble true</pre>
* Set the printer to print the document with duplex mode flipping it on the short edge.<br/>
* <strong>Note:</strong><br/>
* <i>Refer to the PostScript reference for your PostScript device for more details about
* additional Page Device options. </i>
*
* @param pageDeviceParameters String with parameters or null.
*/
public void setPageDeviceParameters(String pageDeviceParameters) {
this.pageDeviceParameters = pageDeviceParameters;
}
/**
* Overloaded method.<br/>
* The page will be rendered as usual, but instead of the PageOrientation
* the proper page width anf height will be set. Together with user defined
* {@link #pageDeviceParameters}.
*
* @param page page to render.
*/
public void renderPage(Page page) {
this.pagecount++;
this.idReferences = page.getIDReferences();
write("%%Page: " + page.getNumber() + " " + page.getNumber());
final long pagewidth = page.getWidth();
final long pageheight = page.getHeight();
final double pspagewidth = pagewidth / 1000f;
final double pspageheight = pageheight / 1000f;
write("%%BeginPageSetup");
// write page device parameters
write("<<");
// write user defined parameters, if not null
if (null!=pageDeviceParameters) write(pageDeviceParameters);
// write page size
write("/PageSize ["+pspagewidth+" "+pspageheight+"]");
// set PS variable
write(">> setpagedevice");
write("FOPprocs begin");
write("FOPFonts begin");
write("0.001 0.001 scale");
write("%%EndPageSetup");
renderRegions(page);
write("showpage");
write("%%PageTrailer");
write("%%EndPage"); //This is non-standard, but used by Adobe.
}
After this changes, the ps file could be directly send to the printer.
pageDeviceParameters gives a way to specify additional page parameters, like page weight, duplex, etc.
---
Yours sincerely, Ivan Latysh.
Ivan[a]yourmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: PS Renderer.
Posted by Jeremias Maerki <de...@greenmail.ch>.
I hear you. Incidentally, I've had the same problem reported to me via a
different channel. Funny things happen.
I've checked the PPD of the HP Laserjet 5. It supports the PageSize
setting. So my reservation was a bit premature. Looks like your proposal
shouldn't hurt.
On 21.07.2003 16:26:54 IvanLatysh wrote:
> Just do a simple test.
> Here is a dummy FO:
<snip/>
> 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.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: PS Renderer.
Posted by IvanLatysh <Iv...@yahoo.ca>.
Hello, Jeremias!
You wrote to <fo...@xml.apache.org> 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: PS Renderer.
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hello Ivan
You're right, this could be a way to go. But I'm not sure if this
approach is supported by all PostScript printers, especially the HP ones
where quite a few things are special. So basically it comes down to the
problem of being able to test on various printers. I can test the
current code using GhostScript. I'm not so sure about device control
stuff like "PageSize". Sooner or later we will have to implement some
kind of PPD support but until then I think we should keep on the safe
side. So your subclassing looks fine to me. I'm open to suggestions on
how to improve on it in the redesign. Anyone interested to write a PPD
parser?
On 20.07.2003 23:06:20 IvanLatysh wrote:
> Recently I update the FOP , now I am having the fun with fop-0.20.5rc3a :-)
>
> In the last release you add the future to automatic switch orientation (landscape,portrait).
>
> Here is my IMHO.
> Since rendered is dealing with the document, not with the media on the document prints on, it is making no sense to decision about document layout.
> For example, the document have the dimension 10in * 5in. You would say that it is the landscape layout, but this document can be printed on the letter paper, portrait layout.
> My point, it is an ambiguous decision to set page layout based on the page size when you don't know what kind of media are going to be used.
>
> Some workaround:
>
> According to "PostScript® LANGUAGE REFERENCE third edition."
> [begin]
> PageSize:
> An array of two numbers, [width height], specifying the overall dimensions
> of the physical medium that were assumed during the generation of this
> page description.
> [bla, bla, bla]
> The PostScript interpreter
> will set up the transformation from user space to device space so that
> the longer and shorter dimensions specified by PageSize are properly oriented
> with those of the physical medium.
> [end]
> Here is interpreter will do the trick to set the page layout based on the page dimensions,
> because interpreter know about the media and about the document.
>
> It making more sense to specify PageSize instead of the layout.
> I did some experiments with it, and PageSize gives more realistic results.
>
> For myself I wrap PDFRenderer into my class, and overload
> >> public void renderPage(Page page)
> method.
>
> Looking forward to see your thought about.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org