Re: Fixed Column Width not working.
On 31 Mar 2009, at 19:13, Andreas Delmelle wrote: On 31 Mar 2009, at 18:11, Manuel Mall wrote: Go to your Print dialog, select Page Scaling None. FWIW: I'm not 100% sure, but I think this setting can also be influenced by an entry in the PDF Document Catalog. If so, there's a slim chance that an extension I have in queue to look at, could be of help (somewhere in Bugzilla; I'll look it up later, and will post the exact link) Just found it in yesterday's bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=45390 Looking at the sample I posted, it would be something like: ... ... None ... Still quite some things to clear up, and I'm not sure how easy it is to apply that prototype-patch to current FOP Trunk. Haven't looked at it for quite a while... Cheers Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Fixed Column Width not working.
On 31 Mar 2009, at 18:11, Manuel Mall wrote: Go to your Print dialog, select Page Scaling None. FWIW: I'm not 100% sure, but I think this setting can also be influenced by an entry in the PDF Document Catalog. If so, there's a slim chance that an extension I have in queue to look at, could be of help (somewhere in Bugzilla; I'll look it up later, and will post the exact link) If I get around to finish that work, it would be possible to specify the setting through an extension element in fo:declarations. Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Renderer Performance
On 31 Mar 2009, at 12:03, Jeremias Maerki wrote: FWIW: The change that happened from 0.94 to 0.95 was the introduction of a new image loading framework. But that has improved performance in most cases rather than the opposite. Specifically for PNG, there was a change: before, our internal PNG codec was used while now we use the PNG codec from ImageIO. That this should have such an effect surprises me as I would expect that to actually be faster. As always: It depends... :-) This should be the case if the ImageIO codec is a native one. I seem to remember a similar issue on Mac OS X for TIFF output. Apple does not supply a native TIFF codec(*), so the pure Java implementation is used, and that one is much, much slower than the TIFF codec we used to use. (*) I would have to look up if that's still the case. With 1.4, they did supply a native codec, but apparently it raised some security issues, so in 1.5, it was removed. Haven't checked yet if they included one with their 1.6 JVM. Cheers Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Fixed Column Width not working.
Go to your Print dialog, select Page Scaling None. In the "Preview: Composite" box it will now show under the preview your document size and your paper size. If they are identical then Adobe will shrink your document to make it fit the printable area size which is smaller than the paper size. Adobe doesn't know anything about margins in the PDF. It knows the page size in the PDF and it knows (from the printer driver) the printable area available to it. In your case the page size in the PDF is bigger than the printable area so it will scale it down to make everything fit. -Original Message- From: Patrick [mailto:ptho...@trey-industries.com] Sent: Tuesday, 31 March 2009 11:55 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Fixed Column Width not working. I understand what your saying. What I still don't get is why Adobe feels the need to scale my form in the first place. It fits perfectly fine within the printable area. What is Adobe seeing that is telling it that it needs to shrink down my form? Is the paper size? The margins? If the table that I'm creating is wider than the paper, it just cuts it off. It doesn't scale down to fit everything in the width. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Fixed Column Width not working.
I understand what your saying. What I still don't get is why Adobe feels the need to scale my form in the first place. It fits perfectly fine within the printable area. What is Adobe seeing that is telling it that it needs to shrink down my form? Is the paper size? The margins? If the table that I'm creating is wider than the paper, it just cuts it off. It doesn't scale down to fit everything in the width. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Fixed Column Width not working.
Following on from this in the Acrobat KB (http://kb.adobe.com/selfservice/viewContent.do?externalId=332720&sliceId=2# 4) under "SCALE PAGES" it says: ---QUOTE START --- You can also set a default page scaling on a document-by-document basis as well as some other Print dialog options: 1. Open a PDF in Acrobat and choose File > Document Properties. 2. Click on the Advanced tab and select the desired options for the Print Dialog Presets. 3. Click OK to dismiss this dialog. 4. Choose File > Save, or File > Save As to apply the new defaults to the PDF file. ---QUOTE END --- If Acrobat can set these preferences in the PDF may be a FOP extension to the PDF renderer could do the same? -Original Message- From: Manuel Mall [mailto:m...@arcus.com.au] Sent: Tuesday, 31 March 2009 11:05 PM To: 'fop-users@xmlgraphics.apache.org' Subject: RE: Fixed Column Width not working. The Adobe Reader printing subsystem distinguishes between paper size and printable area. Most printers can't print to the edges of the paper, therefore the printable area is smaller than the paper size (and the printable area differs between printers). The scaling ensures that the PDF page fits into the printable area of the paper / printer combination and no content is lost when printing. Because the printable area differs between printers assuming it will always be 94% of the paper size will not give consistent results between printers. If you don't want any scaling then as mentioned before the solution is to set it to None in the Adobe Reader Print dialog. This means your page will be printed starting at the top/left corner of the printable area (not the paper) and anything that does not fit to the right or bottom is cropped. For the visual appearance of the page on the paper this means that if for example you have a left margin of 1/4" in your PDF and your printer's printable area starts at 0.1" from the left edge of the paper your left margin on the printed page will be 1/4" + 0.1" (assuming perfect paper feed mechanism and paper alignment in the printer). I know this is not what you want but this is how it appears to work. -Original Message- From: Patrick [mailto:ptho...@trey-industries.com] Sent: Tuesday, 31 March 2009 10:31 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Fixed Column Width not working. > So the margins you specified in FO lie outside the printable area > supported by your printer. The margins are 1/4", which my printer supports. I'm not sure why those didn't work, but that's OK. > Other people had the same problem (you can check the archives). They > switched off the scaling in Acrobat's print dialog and they confirmed > that the dimensions specified in FO were correct when printed out. There > is no bug in FOP concerning that. It's a user setting in Acrobat which > FOP doesn't have an influence on. So I don't know how to help you any > further with this. Sorry. I searched the archives and couldn't find the problem, but now that I know what I'm looking for, I can probably find more info. Do you know if a PDF would be capable of containing print settings that I could code into my form? Would that be a feature worth requesting or is it impossible? I think I may have figured out a way to make it work without requiring the user to turn of scaling. For some reason, Adobe always scales my documents to 94% for all of my forms. If I adjust my measurements to compensate for that, then the printout comes out fine. What I still don't understand is why Adobe is doing this scaling. My form, margins included, is smaller than the 8.5x11 paper that it's printing on. Would the amount that it's adjusting be different on different printers? I would think that it would be the same for the same paper size regardless of the printer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Fixed Column Width not working.
The Adobe Reader printing subsystem distinguishes between paper size and printable area. Most printers can't print to the edges of the paper, therefore the printable area is smaller than the paper size (and the printable area differs between printers). The scaling ensures that the PDF page fits into the printable area of the paper / printer combination and no content is lost when printing. Because the printable area differs between printers assuming it will always be 94% of the paper size will not give consistent results between printers. If you don't want any scaling then as mentioned before the solution is to set it to None in the Adobe Reader Print dialog. This means your page will be printed starting at the top/left corner of the printable area (not the paper) and anything that does not fit to the right or bottom is cropped. For the visual appearance of the page on the paper this means that if for example you have a left margin of 1/4" in your PDF and your printer's printable area starts at 0.1" from the left edge of the paper your left margin on the printed page will be 1/4" + 0.1" (assuming perfect paper feed mechanism and paper alignment in the printer). I know this is not what you want but this is how it appears to work. -Original Message- From: Patrick [mailto:ptho...@trey-industries.com] Sent: Tuesday, 31 March 2009 10:31 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Fixed Column Width not working. > So the margins you specified in FO lie outside the printable area > supported by your printer. The margins are 1/4", which my printer supports. I'm not sure why those didn't work, but that's OK. > Other people had the same problem (you can check the archives). They > switched off the scaling in Acrobat's print dialog and they confirmed > that the dimensions specified in FO were correct when printed out. There > is no bug in FOP concerning that. It's a user setting in Acrobat which > FOP doesn't have an influence on. So I don't know how to help you any > further with this. Sorry. I searched the archives and couldn't find the problem, but now that I know what I'm looking for, I can probably find more info. Do you know if a PDF would be capable of containing print settings that I could code into my form? Would that be a feature worth requesting or is it impossible? I think I may have figured out a way to make it work without requiring the user to turn of scaling. For some reason, Adobe always scales my documents to 94% for all of my forms. If I adjust my measurements to compensate for that, then the printout comes out fine. What I still don't understand is why Adobe is doing this scaling. My form, margins included, is smaller than the 8.5x11 paper that it's printing on. Would the amount that it's adjusting be different on different printers? I would think that it would be the same for the same paper size regardless of the printer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Fixed Column Width not working.
> So the margins you specified in FO lie outside the printable area > supported by your printer. The margins are 1/4", which my printer supports. I'm not sure why those didn't work, but that's OK. > Other people had the same problem (you can check the archives). They > switched off the scaling in Acrobat's print dialog and they confirmed > that the dimensions specified in FO were correct when printed out. There > is no bug in FOP concerning that. It's a user setting in Acrobat which > FOP doesn't have an influence on. So I don't know how to help you any > further with this. Sorry. I searched the archives and couldn't find the problem, but now that I know what I'm looking for, I can probably find more info. Do you know if a PDF would be capable of containing print settings that I could code into my form? Would that be a feature worth requesting or is it impossible? I think I may have figured out a way to make it work without requiring the user to turn of scaling. For some reason, Adobe always scales my documents to 94% for all of my forms. If I adjust my measurements to compensate for that, then the printout comes out fine. What I still don't understand is why Adobe is doing this scaling. My form, margins included, is smaller than the 8.5x11 paper that it's printing on. Would the amount that it's adjusting be different on different printers? I would think that it would be the same for the same paper size regardless of the printer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to create version 2.0 PS files
Hi Frank, Yes, you can do this with the language-level configuration option (see http://xmlgraphics.apache.org/fop/0.95/output.html#ps-configuration). Adrian. Frank Niedermann wrote: Hi, we are using Apache FOP to create PS files which should be printed on a HP-Unix machine. Unfortunately this machine only supports version 2.0 PS files: %!PS-Adobe-2.0 Apache FOP creates version 3.0 PS files which are ignored by the HP-Unix print system. Is there a way to tell FOP to generate version 2.0 PS files? Thanks, Frank - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
How to create version 2.0 PS files
Hi, we are using Apache FOP to create PS files which should be printed on a HP-Unix machine. Unfortunately this machine only supports version 2.0 PS files: %!PS-Adobe-2.0 Apache FOP creates version 3.0 PS files which are ignored by the HP-Unix print system. Is there a way to tell FOP to generate version 2.0 PS files? Thanks, Frank -- View this message in context: http://www.nabble.com/How-to-create-version-2.0-PS-files-tp22804932p22804932.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Renderer Performance
Hello all,
I am currently rendering a legal size document to PDF with fop 0.94 that
contains two panels of graphics. Each panel contains a single 300 dpi PNG file.
Additional text is rendered on the page but is very minimal. The rendering is
taking upwards of 4 seconds to complete on my development box (1g ram, 2.5ghz
processor). I've tried all optimizations I could find including the use of
BufferedOutputStreams and usage of url's for external graphics to try to
improve the time (hopefully to 1 to 1.5 seconds). Nothing I've tried is making
much of an improvement in the render time. Does anyone have any experience
with increasing render performance from fop? I upgraded to fop 0.95 and
actually saw performance drop off dramatically so I'm currently using 0.94.
Any help with this issue would be greatly appreciated!
My rendering source code looks like the following which is the basic strategy
proposed by apache's website:
// Setup input and output for XSLT transformation
Source xslSrc = new StreamSource(xslFile);
// Create transformer.
Transformer transformer = createTransformer(xslSrc);
// Resulting SAX events (the generated FO) must be piped through to FOP
Result res = new SAXResult(fop.getDefaultHandler());
// Load specification into a source.
Source src = new DOMSource(document);
// Perform the transform.
transformer.transform(src, res);
My FO document is very simple. Below is an abridged version:
http://www.w3.org/1999/XSL/Transform";
xmlns:fo="http://www.w3.org/1999/XSL/Format";>
My xsl file is simple as well:
url('c:/example/example1.png')
url('c:/example/example2.png')
RESOLVED: Top Margin vs First Printable Position on a Page
I just noticed that my top margin for the "simple-page-master" was not
set correctly. That fixed it.
Thanks.
Jeff
> __
> From: Steffanina, Jeff
> Sent: Tuesday, March 31, 2009 7:01 AM
> To: 'fop-users@xmlgraphics.apache.org'
> Subject: Top Margin vs First Printable Position on a Page
>
> Friends,
> If I use MicroSoft Word and print "ABC" with the top margin set to 0,
> I get the ABC in the extreme upper left corner (about one-tenth of an
> inch from the top) of the printed page on my printer.
>
> I need to get an image to start at the extreme, upper left corner of
> the printed page. It seems that the best I can do with FOP, is about
> one-half inch from the top of the page. I have carefully reviewed the
> graphic (.jpg) and I am confident that it is in good form.
> Here are my "region-before" settings:
>
>line-height="1in"
>
> background-image="url('java/images/RI_Thrive_nospace.jpg')"
> background-position-vertical="bottom"
> background-repeat="no-repeat"
> margin-top=".1in"
> margin-left=".25in"
> absolute-position="fixed"
> font-size="0pt"
> display-align="after" />
>
>
> If I change the "extent", it chops off the image at the top.
>
> Any ideas
>
> Jeff
Top Margin vs First Printable Position on a Page
Friends, If I use MicroSoft Word and print "ABC" with the top margin set to 0, I get the ABC in the extreme upper left corner (about one-tenth of an inch from the top) of the printed page on my printer. I need to get an image to start at the extreme, upper left corner of the printed page. It seems that the best I can do with FOP, is about one-half inch from the top of the page. I have carefully reviewed the graphic (.jpg) and I am confident that it is in good form. Here are my "region-before" settings: If I change the "extent", it chops off the image at the top. Any ideas Jeff
Re: Renderer Performance
Uhm, I think you have sent this to the wrong mailing list. FOP support
is at fop-us...@xmlgraphics.apache.org. Please drop batik-users@ from
the CC when you reply.
The change that happened from 0.94 to 0.95 was the introduction of a new
image loading framework. But that has improved performance in most cases
rather than the opposite. Specifically for PNG, there was a change:
before, our internal PNG codec was used while now we use the PNG codec
from ImageIO. That this should have such an effect surprises me as I
would expect that to actually be faster. Maybe we have to provide an
option to still use the internal PNG codec. What JVM are you running
this on?
As for improving performance in general, I'm not sure what could be done.
The PNG needs to be decompressed, built up in memory and then
recompressed for PDF output. I've once experimented with 1:1 embedding
of PDFs in PDF but was unable to get this working. The only thing you
can do is try other image formats if possible. For example, if you have
black/white images, you may want to switch to TIFFs with CCITT
compression or, for color images, to JPEG images which can both be
embedded lightning-fast in PDF without decompression and recompression.
On 30.03.2009 19:47:39 Kevin Whittington wrote:
> Hello all,
>
> I am currently rendering a legal size document to PDF with fop 0.94
> that contains two panels of graphics. Each panel contains a single 300 dpi
> PNG file. Additional text is rendered on the page but is very minimal.
> The rendering is taking upwards of 4 seconds to complete on my
> development box (1g ram, 2.5ghz processor). I've tried all
> optimizations I could find including the use of BufferedOutputStreams
> and usage of url's for external graphics to try to improve the time
> (hopefully to 1 to 1.5 seconds). Nothing I've tried is making much of
> an improvement in the render time. Does anyone have any experience
> with increasing render performance from fop? I upgraded to fop 0.95 and
> actually saw performance drop off dramatically so I'm currently using
> 0.94. Any help with this issue would be greatly appreciated!
>
> My rendering source code looks like the following which is the basic strategy
> proposed by apache's website:
>
> try {
> // Setup input and output for XSLT transformation
> Source xslSrc = new StreamSource(xslFile);
>
> // Create transformer.
> Transformer transformer = createTransformer(xslSrc);
>
> // Resulting SAX events (the generated FO) must be piped through
> to FOP
> Result res = new SAXResult(fop.getDefaultHandler());
>
> // Load specification into a source.
> Source src = new DOMSource(document);
>
> // Perform the transform.
> transformer.transform(src, res);
>
> } catch (FOPException e) {
> ...
> } catch (TransformerException e) {
> ...
> }
>
>
> My FO document is very simple. Below is an abridged version:
>
>
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> xmlns:fo="http://www.w3.org/1999/XSL/Format";>
>
>
>
>
>
>
>
>
> page-height="8.5in"
> page-width="14.5in"
> margin-top="0in"
> margin-bottom="0in"
> margin-left=".1875in"
> margin-right="0in">
>
>
>
>
>
>
>
> select="specification/panelOneFile"/>
> select="specification/panelTwoFile"/>
>
>
>
>
>
>
>
>
>
> left="4.5in" padding="0mm" position="absolute">
>
>
>
>
>
>
>
> left="9.1in" padding="0mm" position="absolute">
>
>
>
>
>
>
>
>
> My xsl file is simple as well:
>
>
>
> url('c:/example/example1.png')
> url('c:/example/example2.png')
>
>
> Kevin Whittington
> Store Systems Senior Programmer/Analyst
> Catalina Marketing Corporation
>
>
Jeremias Maerki
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: HowTo export several pages to PNG-format
If you set up a user agent, you can set the output file in addition to
the output stream. That way, the PNG renderer will be able to create
additional files in the same location for the pages > 1.
File outputFile = new File(path + ".png")
FOUserAgent ua = fopFactory.newUserAgent();
ua.setOutputFile(outputFile);
Fop fop = fopFactory.newFop(MimeConstants.MIME_PNG, ua, output);
Of course, that doesn't give you much control over how the various files
are produced but it might be enough for your case. If you need more
control over the output files, you need to subclass
org.apache.fop.render.bitmap.PNGRenderer and override
getCurrentOutputStream(int). If you do that you need to construct the
renderer yourself and pass it into FOP through
FOUserAgent.setRendererOverride(Renderer).
HTH
On 31.03.2009 10:16:08 Leopard2A5 wrote:
>
> Hello!
>
> I've searched the mailing lists and the docs but i somehow couldn't find
> help.
> I'm using fop to generate PDFs in my web-application, but i also need
> preview-pictures to display via HTML.
> Generating PDFs via FOP works great, but i can't manage to get more than the
> first page as a preview.
>
> Here's my code:
>
> private int getImagesFromPDF(String path, Reader stylesheet) throws
> Exception
> {
> FileOutputStream output = new FileOutputStream(path + ".png");
>
> //Instantiate FOP
> FopFactory fopFactory = FopFactory.newInstance();
> fopFactory.setSourceResolution(96);
> fopFactory.setBaseURL(VISITE_BASE_PATH);
> try
> {
> fopFactory.setUserConfig(VISITE_BASE_PATH + "fop_config2.xml");
> }
> catch (SAXException e)
> {
> e.printStackTrace();
> }
>
> Fop fop = fopFactory.newFop(MimeConstants.MIME_PNG, output);
>
> TransformerFactory factory = TransformerFactory.newInstance();
> Transformer transformer = factory.newTransformer();
>
> // get the right input format for conversion
> Source style = new StreamSource(stylesheet);
> Result res = new SAXResult(fop.getDefaultHandler());
>
> // Step 6: Start XSLT transformation and FOP processing
> transformer.transform(style, res);
>
> return 0;
> }
>
> and my fop_config-file:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Any help would be appreciated!
> Thx in advance!
> --
> View this message in context:
> http://www.nabble.com/HowTo-export-several-pages-to-PNG-format-tp22800402p22800402.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
Jeremias Maerki
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
HowTo export several pages to PNG-format
Hello!
I've searched the mailing lists and the docs but i somehow couldn't find
help.
I'm using fop to generate PDFs in my web-application, but i also need
preview-pictures to display via HTML.
Generating PDFs via FOP works great, but i can't manage to get more than the
first page as a preview.
Here's my code:
private int getImagesFromPDF(String path, Reader stylesheet) throws
Exception
{
FileOutputStream output = new FileOutputStream(path + ".png");
//Instantiate FOP
FopFactory fopFactory = FopFactory.newInstance();
fopFactory.setSourceResolution(96);
fopFactory.setBaseURL(VISITE_BASE_PATH);
try
{
fopFactory.setUserConfig(VISITE_BASE_PATH + "fop_config2.xml");
}
catch (SAXException e)
{
e.printStackTrace();
}
Fop fop = fopFactory.newFop(MimeConstants.MIME_PNG, output);
TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer();
// get the right input format for conversion
Source style = new StreamSource(stylesheet);
Result res = new SAXResult(fop.getDefaultHandler());
// Step 6: Start XSLT transformation and FOP processing
transformer.transform(style, res);
return 0;
}
and my fop_config-file:
Any help would be appreciated!
Thx in advance!
--
View this message in context:
http://www.nabble.com/HowTo-export-several-pages-to-PNG-format-tp22800402p22800402.html
Sent from the FOP - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
