Re: [ANN] New release of PDF image support for Apache FOP
Jeremias, We are trying to maintain a 'clean' maven setup to build our own software from. For those dependencies we don't have external maven repo's we try to build from the source. The 'problem' we are currently facing is that it is unclear for us which version of PDFBox the fop-pdf 1.3 build depends on. We found a PDFBox-0.7.4-dev.jar and local version of some of the classes in /src/java/org/apache/fop/render/pdf/pdfbox/ Do you see a way to help us. Perhaps you have the svn revision corresponding to PDFBox-0.7.4-dev? Many thanks indeed! Peter From: Jeremias Maerki [EMAIL PROTECTED] Reply-To: fop-users@xmlgraphics.apache.org Date: Fri, 28 Nov 2008 16:36:12 +0100 To: fop-users@xmlgraphics.apache.org Subject: [ANN] New release of PDF image support for Apache FOP I've just uploaded a new release (Version 1.3) of the PDF image support plug-in for Apache FOP (0.95beta and later). The plug-in allows to include existing PDF files using fo:external-graphic and fox:external-document when generating PDF output. It is published under the Apache License V2.0, just like Apache FOP. For details on the plug-in, please read the README file in the distribution. Download from here: http://www.jeremias-maerki.ch/development/fop/index.html Changes since version 1.2: - Fixed a NullPointerException when the MediaBox is inherited. - An invalid page number is now properly handled. Hashes: 6B2563F90128F2C4F2C5B5CD2F59BEAB fop-pdf-images-1.3-bin.tar.gz 619BF5486A34D9E4E5ABD0E273659149 fop-pdf-images-1.3-bin.zip 252126A3CDE5EC7A48892C1787B1403C fop-pdf-images-1.3-src.tar.gz C77C3D5647E96233D5B1F4A3722E28E2 fop-pdf-images-1.3-src.zip Enjoy, Jeremias Märki _ Jeremias Märki, Software-Development and Consulting Contact Information: http://www.jeremias-maerki.ch/contact.html Blog: http://www.jeremias-maerki.ch/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] New release of PDF image support for Apache FOP
On 01.12.2008 11:36:12 Peter Coppens wrote: Jeremias, We are trying to maintain a 'clean' maven setup to build our own software from. For those dependencies we don't have external maven repo's we try to build from the source. The 'problem' we are currently facing is that it is unclear for us which version of PDFBox the fop-pdf 1.3 build depends on. We found a PDFBox-0.7.4-dev.jar and local version of some of the classes in /src/java/org/apache/fop/render/pdf/pdfbox/ Do you see a way to help us. Perhaps you have the svn revision corresponding to PDFBox-0.7.4-dev? PDFBox @SourceForge ran on CVS. The code change I needed to make the plug-in work was this one: http://sourceforge.net/tracker/?func=detailatid=552834aid=1806912group_id=78314 So I guess if you checked out the source with date 2007-10-16 you should get a version that works with the plug-in. What I'm publishing with the plug-in is a local snapshot build. I know, it's not beautiful. Anyway, I'm planning to migrate the plug-in to the migrated PDFBox (currently in ASF incubation) as soon as the first release is ready. That will make things easier. HTH Many thanks indeed! Peter From: Jeremias Maerki [EMAIL PROTECTED] Reply-To: fop-users@xmlgraphics.apache.org Date: Fri, 28 Nov 2008 16:36:12 +0100 To: fop-users@xmlgraphics.apache.org Subject: [ANN] New release of PDF image support for Apache FOP I've just uploaded a new release (Version 1.3) of the PDF image support plug-in for Apache FOP (0.95beta and later). The plug-in allows to include existing PDF files using fo:external-graphic and fox:external-document when generating PDF output. It is published under the Apache License V2.0, just like Apache FOP. For details on the plug-in, please read the README file in the distribution. Download from here: http://www.jeremias-maerki.ch/development/fop/index.html Changes since version 1.2: - Fixed a NullPointerException when the MediaBox is inherited. - An invalid page number is now properly handled. Hashes: 6B2563F90128F2C4F2C5B5CD2F59BEAB fop-pdf-images-1.3-bin.tar.gz 619BF5486A34D9E4E5ABD0E273659149 fop-pdf-images-1.3-bin.zip 252126A3CDE5EC7A48892C1787B1403C fop-pdf-images-1.3-src.tar.gz C77C3D5647E96233D5B1F4A3722E28E2 fop-pdf-images-1.3-src.zip Enjoy, Jeremias Märki _ Jeremias Märki, Software-Development and Consulting Contact Information: http://www.jeremias-maerki.ch/contact.html Blog: http://www.jeremias-maerki.ch/blog/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] New release of PDF image support for Apache FOP
Thanks. It does help, Peter. From: Jeremias Maerki [EMAIL PROTECTED] Reply-To: fop-users@xmlgraphics.apache.org Date: Mon, 01 Dec 2008 11:45:22 +0100 To: fop-users@xmlgraphics.apache.org Subject: Re: [ANN] New release of PDF image support for Apache FOP On 01.12.2008 11:36:12 Peter Coppens wrote: Jeremias, We are trying to maintain a 'clean' maven setup to build our own software from. For those dependencies we don't have external maven repo's we try to build from the source. The 'problem' we are currently facing is that it is unclear for us which version of PDFBox the fop-pdf 1.3 build depends on. We found a PDFBox-0.7.4-dev.jar and local version of some of the classes in /src/java/org/apache/fop/render/pdf/pdfbox/ Do you see a way to help us. Perhaps you have the svn revision corresponding to PDFBox-0.7.4-dev? PDFBox @SourceForge ran on CVS. The code change I needed to make the plug-in work was this one: http://sourceforge.net/tracker/?func=detailatid=552834aid=1806912group_id=7 8314 So I guess if you checked out the source with date 2007-10-16 you should get a version that works with the plug-in. What I'm publishing with the plug-in is a local snapshot build. I know, it's not beautiful. Anyway, I'm planning to migrate the plug-in to the migrated PDFBox (currently in ASF incubation) as soon as the first release is ready. That will make things easier. HTH Many thanks indeed! Peter From: Jeremias Maerki [EMAIL PROTECTED] Reply-To: fop-users@xmlgraphics.apache.org Date: Fri, 28 Nov 2008 16:36:12 +0100 To: fop-users@xmlgraphics.apache.org Subject: [ANN] New release of PDF image support for Apache FOP I've just uploaded a new release (Version 1.3) of the PDF image support plug-in for Apache FOP (0.95beta and later). The plug-in allows to include existing PDF files using fo:external-graphic and fox:external-document when generating PDF output. It is published under the Apache License V2.0, just like Apache FOP. For details on the plug-in, please read the README file in the distribution. Download from here: http://www.jeremias-maerki.ch/development/fop/index.html Changes since version 1.2: - Fixed a NullPointerException when the MediaBox is inherited. - An invalid page number is now properly handled. Hashes: 6B2563F90128F2C4F2C5B5CD2F59BEAB fop-pdf-images-1.3-bin.tar.gz 619BF5486A34D9E4E5ABD0E273659149 fop-pdf-images-1.3-bin.zip 252126A3CDE5EC7A48892C1787B1403C fop-pdf-images-1.3-src.tar.gz C77C3D5647E96233D5B1F4A3722E28E2 fop-pdf-images-1.3-src.zip Enjoy, Jeremias Märki _ Jeremias Märki, Software-Development and Consulting Contact Information: http://www.jeremias-maerki.ch/contact.html Blog: http://www.jeremias-maerki.ch/blog/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
spot colours
I have a requirement to provide some 'camera ready copy' for a supplier. They need this in PDF and also they need to have it with 'spot colours'. I'm happily generating the PDF with FOP (thanks to all authors!), but I'm struggling with how to make the colours 'spot'. To make matters a tad more complicated, the main location of the colours are in some graphics which I'm generating by including SVG markup. The available documentation on XSL-FO and SVG both seem rather sparse where spot colour (I gather ICC is another name for this!) comes in to play. Can anyone provide pointers or better, snippets of code or worse (but still helpful) and authoritative statement that I have the wrong tree to bark up?! :) Cheers Iain
Re: spot colours
On 01.12.2008 13:52:02 Iain Downs wrote: I have a requirement to provide some 'camera ready copy' for a supplier. They need this in PDF and also they need to have it with 'spot colours'. I'm happily generating the PDF with FOP (thanks to all authors!), but I'm struggling with how to make the colours 'spot'. You're not the first: http://fop.markmail.org/search/?q=spot%20colors To make matters a tad more complicated, the main location of the colours are in some graphics which I'm generating by including SVG markup. The available documentation on XSL-FO and SVG both seem rather sparse where spot colour (I gather ICC is another name for this!) comes in to play. Sparse is overstated. Both standards have currently no provisions for spot colors. Only the current SVG Print working draft [1] is trying to do something about this, but SVG print won't help us here. [1] http://www.w3.org/TR/SVGPrintPrimer12/#named Can anyone provide pointers or better, snippets of code or worse (but still helpful) and authoritative statement that I have the wrong tree to bark up?! :) As you might have guessed from the first link above, FOP doesn't currently have support for spot colors. Some of the commercial FO implementations have defined proprietary extension functions to specify spot colors. Something similar would have to be done for FOP. Patches would be most welcome. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
0.95 Acrobat Performance Problems
Hi, I receive lots and lots of small (1-3 page) PDFs each day, combine them using Acrobat Professional, and print and mail them for clients. One client recently upgraded from FOP .2x to FOP 0.95, and the combining of his files has become nearly impossible. It'll put the first 10 pages together fairly quickly, but gets incrementally slower with subsequent additions until the process grinds to a halt before page 150 or so. He tends to send me batches of between 1500 and 3500 pages, so I'm well shy of what I need to accomplish. The process worked great with the earlier version, and works fine with my other clients' PDFs that are created with various other tools. These files are invoices. Batches of which regularly represent several millions of dollars, so they really have to be right, timely, and without duplicates or omissions. I'm not at all familiar with FOP - please forgive my ignorance. I hadn't heard of it until the problem occurred and I started doing a bit of research. From what I've read, there seems to be a fair amount of discussion related to memory issues and large PDFs. I'm wondering if anyone else has a situation similar to mine, and / or might be able to suggest what I might be able to do to get my production back on track. I'm working in Windows XP SP3, 2Gb RAM and a 3GHz processor. Any advice would be sincerely appreciated. Thanks, Ed -- View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p20774481.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unresolved ID and page-number-citation allocated width
Hi ! I took a look at a few discussions around this issue on the mailing list and at the current implementation in FOP Trunk. Currently i'm having a PDF with several chapters whose content may have some links pointing to some content in another chapter. These chapters can be generated separately so that some links are unresolved and that's ok. But my problem is that i attach a page-number-citation to each link like this: fo:basic-link color=blue internal-destination=myId A link fo:inline baseline-shift=super font-size=8pt [fo:page-number-citation ref-id=myId/]/fo:inline /fo:basic-link The behaviour that i was expecting was to have empty brackets [] when the ID couldn't be resolved. Instead, i got empty brackets but with a large space between them []. After a quick look at the code, i saw that page-number-citation allocates a space corresponding to the string MMM if the ID can't be immediately resolved. My FOP understanding is quite limited so i can't understand how FOP manages to shrink the space previously allocated when it succeeds in resolving the ID and why it leaves this MMM-space when it fails to resolve the ID. So I have two questions: 1) Is there a way to squeeze that space in case of unresolved ID ? I don't want to hack the code and replace the MMM string by a | string for instance, it's ugly and it will surely lead to severe mistakes in the layout. Is it difficult to implement such a behaviour ? I'm guessing that if this hasn't been implemented yet it must be because of some tricky implications and/or issues ? 2) I can bear not to have any page-number-citation at all in case of unresolved ID but in this case, i will need to know when my ID can be resolved and when it can't. It leads to some xsl-testing (i guess) and i don't think an XSLT processor can be aware of such things... But i may be wrong and perhaps this cool feature exists ? Thanks again for your help. Seb
Re: 0.95 Acrobat Performance Problems
egibler wrote: Hi, I receive lots and lots of small (1-3 page) PDFs each day, combine them using Acrobat Professional, and print and mail them for clients. One client recently upgraded from FOP .2x to FOP 0.95, and the combining of his files has become nearly impossible. It'll put the first 10 pages together fairly quickly, but gets incrementally slower with subsequent additions until the process grinds to a halt before page 150 or so. He tends to send me batches of between 1500 and 3500 pages, so I'm well shy of what I need to accomplish. The process worked great with the earlier version, and works fine with my other clients' PDFs that are created with various other tools. These files are invoices. Batches of which regularly represent several millions of dollars, so they really have to be right, timely, and without duplicates or omissions. I'm not at all familiar with FOP - please forgive my ignorance. I hadn't heard of it until the problem occurred and I started doing a bit of research. From what I've read, there seems to be a fair amount of discussion related to memory issues and large PDFs. I'm wondering if anyone else has a situation similar to mine, and / or might be able to suggest what I might be able to do to get my production back on track. I'm a little confused. While FOP does indeed have some known performance issues with multi page documents, isn't the performance issue YOU'RE talking about inside Acrobat? BugBear - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.95 Acrobat Performance Problems
Thanks for the response. My problem is absolutely in Acrobat, specifically in how Acrobat deals with the PDFs generated using FOP 0.95 (I'm pretty sure). I'm hoping there might be some setting, or known issue, in dealing with the two products in the fashion I'm doing it. I combine somewhere between 20,000 and 30,000 PDF pages daily, and have done so for about three years. The process is quick and reliable. Last week, one of our clients migrated from FOP .2 to FOP .95, and abolutely every subsequent file sent by them has brought me to my knees. The remaining 90% of my work (coming from other clients and using other PDF generation tools) is flowing great, and I can rerun old FOP .2 files which also still work great. To me, the smoking gun is the upgrade, but I could be pursuaded otherwise. It wouldn't be my first incorrect assumption. I'm hoping to find the cause, or at least some sort of work around, or I'm afraid I'm going to have to turn away this client's business. Does that make sense? I readily acknowledge my lack of experience with the FOP toolset. Any light shed on the issue would be most helpful. Thanks, ed paul womack wrote: egibler wrote: Hi, I receive lots and lots of small (1-3 page) PDFs each day, combine them using Acrobat Professional, and print and mail them for clients. One client recently upgraded from FOP .2x to FOP 0.95, and the combining of his files has become nearly impossible. It'll put the first 10 pages together fairly quickly, but gets incrementally slower with subsequent additions until the process grinds to a halt before page 150 or so. He tends to send me batches of between 1500 and 3500 pages, so I'm well shy of what I need to accomplish. The process worked great with the earlier version, and works fine with my other clients' PDFs that are created with various other tools. These files are invoices. Batches of which regularly represent several millions of dollars, so they really have to be right, timely, and without duplicates or omissions. I'm not at all familiar with FOP - please forgive my ignorance. I hadn't heard of it until the problem occurred and I started doing a bit of research. From what I've read, there seems to be a fair amount of discussion related to memory issues and large PDFs. I'm wondering if anyone else has a situation similar to mine, and / or might be able to suggest what I might be able to do to get my production back on track. I'm a little confused. While FOP does indeed have some known performance issues with multi page documents, isn't the performance issue YOU'RE talking about inside Acrobat? BugBear - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p20777151.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 0.95 Acrobat Performance Problems
I would look for differences in the source PDFs between the two versions. Even opening a PDF in a text editor will possibly show enough differences to explain the problem. FOP 0.95 creates PDF v1.4 files. I don't remember what FOP 0.20.5 created. Maybe there's a difference in how the contents of the PDF are compressed/uncompressed that influences the ability to concatenate. There are filters that FOP applies to certain items in the PDF, like the FLATE filter on images, so maybe those are affecting the behavior. Are files of similar content and page count approximately the same size between a source that works and a source that does not? If you have to, you could write a program to use iText to do the PDF concatenation instead of Acrobat just to see if the problem is reproducible from other software. -Original Message- From: egibler [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 1:40 PM To: fop-users@xmlgraphics.apache.org Subject: Re: 0.95 Acrobat Performance Problems Thanks for the response. My problem is absolutely in Acrobat, specifically in how Acrobat deals with the PDFs generated using FOP 0.95 (I'm pretty sure). I'm hoping there might be some setting, or known issue, in dealing with the two products in the fashion I'm doing it. I combine somewhere between 20,000 and 30,000 PDF pages daily, and have done so for about three years. The process is quick and reliable. Last week, one of our clients migrated from FOP .2 to FOP .95, and abolutely every subsequent file sent by them has brought me to my knees. The remaining 90% of my work (coming from other clients and using other PDF generation tools) is flowing great, and I can rerun old FOP .2 files which also still work great. To me, the smoking gun is the upgrade, but I could be pursuaded otherwise. It wouldn't be my first incorrect assumption. I'm hoping to find the cause, or at least some sort of work around, or I'm afraid I'm going to have to turn away this client's business. Does that make sense? I readily acknowledge my lack of experience with the FOP toolset. Any light shed on the issue would be most helpful. Thanks, ed paul womack wrote: egibler wrote: Hi, I receive lots and lots of small (1-3 page) PDFs each day, combine them using Acrobat Professional, and print and mail them for clients. One client recently upgraded from FOP .2x to FOP 0.95, and the combining of his files has become nearly impossible. It'll put the first 10 pages together fairly quickly, but gets incrementally slower with subsequent additions until the process grinds to a halt before page 150 or so. He tends to send me batches of between 1500 and 3500 pages, so I'm well shy of what I need to accomplish. The process worked great with the earlier version, and works fine with my other clients' PDFs that are created with various other tools. These files are invoices. Batches of which regularly represent several millions of dollars, so they really have to be right, timely, and without duplicates or omissions. I'm not at all familiar with FOP - please forgive my ignorance. I hadn't heard of it until the problem occurred and I started doing a bit of research. From what I've read, there seems to be a fair amount of discussion related to memory issues and large PDFs. I'm wondering if anyone else has a situation similar to mine, and / or might be able to suggest what I might be able to do to get my production back on track. I'm a little confused. While FOP does indeed have some known performance issues with multi page documents, isn't the performance issue YOU'RE talking about inside Acrobat? BugBear - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p20777151.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
Re: 0.95 Acrobat Performance Problems
On 01 Dec 2008, at 20:39, egibler wrote: Hi snip / To me, the smoking gun is the upgrade, but I could be pursuaded otherwise. It wouldn't be my first incorrect assumption. I'm hoping to find the cause, That would be helpful indeed. A lot has changed in the way the PDF is constructed between the two versions, so it's definitely possible that some of those changes are responsible. OTOH, without /any/ indication whatsoever of what precisely is going on, it will be difficult to address. So, the most important question is probably: is there something special about those PDFs? Are there many images, custom fonts, tables ...? Anything that might give us a clue? Apart from the mere theoretical possibility, you're the first to report such an issue (but this could be because there's only very few people that have the exact same setup, and use Acrobat to merge PDF generated by FOP? iText is among the most popular libraries to be used for this purpose.) or at least some sort of work around, or I'm afraid I'm going to have to turn away this client's business. That would be unfortunate, and is something we would help to avoid, if only we knew where to start looking... :/ Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unresolved ID and page-number-citation allocated width
On 01 Dec 2008, at 17:11, Sebastien wrote: Hi snip / The behaviour that i was expecting was to have empty brackets [] when the ID couldn't be resolved. Instead, i got empty brackets but with a large space between them []. After a quick look at the code, i saw that page-number-citation allocates a space corresponding to the string MMM if the ID can't be immediately resolved. Right. A sort of pessimistic guess. If you're in luck, and the page- number is resolved before the actual breaks for the part in question are determined, then this will lead to nice results (= most cases, since either the link points forwards and the reserved space is more than enough to fit the actual text, or the link points backwards, which avoids the generation of the dummy element altogether; once the page-count grows too large, there might also be undesired side- effects, IIC). My FOP understanding is quite limited so i can't understand how FOP manages to shrink the space previously allocated when it succeeds in resolving the ID and why it leaves this MMM-space when it fails to resolve the ID. So I have two questions: 1) Is there a way to squeeze that space in case of unresolved ID ? I don't want to hack the code and replace the MMM string by a | string for instance, it's ugly and it will surely lead to severe mistakes in the layout. Is it difficult to implement such a behaviour ? I'm guessing that if this hasn't been implemented yet it must be because of some tricky implications and/or issues ? One could try go into the direction of avoiding the addition of the area if the link is unresolved. The tricky part is that it's possible the dummy area is added, and replaced later, so you have no guarantee, unless you know in advance whether the ID will occur on a later page in the document... 2) I can bear not to have any page-number-citation at all in case of unresolved ID but in this case, i will need to know when my ID can be resolved and when it can't. It leads to some xsl-testing (i guess) and i don't think an XSLT processor can be aware of such things... But i may be wrong and perhaps this cool feature exists ? Well, there is a possibility... Assuming that there is some element- or attribute-value in the XML source that determines the value of the ref-id/id pair, then theoretically, it should be possible to check, at the time the page-number-citation node is generated, whether 'myId' in your example, will appear anywhere in the result document. If not, then you can simply skip generation of the element. As I see it, FOP knows no more about that than you can find out with the help of your XSLT processor. In some of the most common cases, FOP never sees the document in its entirety, so it is not able to determine whether the id will or will not be resolved, eventually. It can tell you, at a given point, whether a FO with the given id already exists. If it does not, then there's no way to guarantee that it will not turn up further in the stream, I'm afraid... unless by having looked at the entire source-document (which, strictly speaking, the XSLT processor has, albeit before it was transformed into FO) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unresolved ID and page-number-citation allocated width
On 01 Dec 2008, at 21:39, Andreas Delmelle wrote: snip / there's no way to guarantee that it will not turn up further in the stream, I'm afraid... unless by having looked at the entire source-document (which, strictly speaking, the XSLT processor has, I realize this should have been 'possibly has'. In full streaming mode, it is possible for the XSLT processor to send FOP a startElement(root) long before it has processed the full XML source. The point is that you could build an xsl:key map to search for the values of elements/attributes in the entire document. In doing so, you will force the processor to look at the whole document before FOP receives the first startElement() event, which could be put to work to your advantage, I think... HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unresolved ID and page-number-citation allocated width
On Mon, Dec 1, 2008 at 9:39 PM, Andreas Delmelle [EMAIL PROTECTED] wrote: On 01 Dec 2008, at 17:11, Sebastien wrote: My FOP understanding is quite limited so i can't understand how FOP manages to shrink the space previously allocated when it succeeds in resolving the ID and why it leaves this MMM-space when it fails to resolve the ID. So I have two questions: 1) Is there a way to squeeze that space in case of unresolved ID ? I don't want to hack the code and replace the MMM string by a | string for instance, it's ugly and it will surely lead to severe mistakes in the layout. Is it difficult to implement such a behaviour ? I'm guessing that if this hasn't been implemented yet it must be because of some tricky implications and/or issues ? One could try go into the direction of avoiding the addition of the area if the link is unresolved. The tricky part is that it's possible the dummy area is added, and replaced later, so you have no guarantee, unless you know in advance whether the ID will occur on a later page in the document... What about a mechanism which squeeze all the unresolved page-number-citation dummy space at the end of the processing ? I didn't really look into FOP's code so it might very well be a stupid idea and/or an impossible thing to do... I just think that since FOP is obviously able to replace a forward reference when it encounters it, it might be able to replace/squeeze an unresolved reference as well. But again, i'm surely missing some internal details... 2) I can bear not to have any page-number-citation at all in case of unresolved ID but in this case, i will need to know when my ID can be resolved and when it can't. It leads to some xsl-testing (i guess) and i don't think an XSLT processor can be aware of such things... But i may be wrong and perhaps this cool feature exists ? Well, there is a possibility... Assuming that there is some element- or attribute-value in the XML source that determines the value of the ref-id/id pair, then theoretically, it should be possible to check, at the time the page-number-citation node is generated, whether 'myId' in your example, will appear anywhere in the result document. If not, then you can simply skip generation of the element. I'm not sure i understood your solution. How would you check that ? (ok, i saw your second mail, i understand now ;) ) Actually i named my FO ids with a convenient name which is [chapter]_[number] (eg: actions_52) so i might be able to get a list of chapters which are generated from my application. Then i would split the ref-id with the '_' delimiter and compare the first part with the list of generated chapters and decide whether to add the page-number-citation or not... But considering all the links in the document, doing a string split + an array search + a test for each and every one of them seems like a real pain and i would hate to do that. Anyways, if i'm stuck with this problem, this will be the way to go i guess... Thanks for your answers anyways ;) Seb
How to use marker in order to print dynamic data into table-header?
Currently I have a marker printing same table header when I iterate through the loop printing table-rows and they overflow onto the next page, then the title has cont. and same table-header. But in my latest requirement I need to put not only title cont. onto next page, but also to print dynamic data into table-header, like for item A, table header will be headerA, and so on, whatever I iterate through the for-loop. So is there a way how to make it in a single file, if it is supported? Let me know, if you need me to send a file, because, it's too big. Thank you, -Gennady -- View this message in context: http://www.nabble.com/How-to-use-marker-in-order-to-print-dynamic-data-into-table-header--tp20781583p20781583.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Measurement accuracy in PDF vs PCL
Hi Jeremias, I have also run into the problem of trying to disable the scale settings in Acrobat. What I had to do was edit the registry key entries before I printed: reg add HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\9.0\AVGeneral /v bprintExpandToFit /t REG_DWORD /d 0x /f reg add HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\9.0\AVGeneral /v iprintScaling /t REG_DWORD /d 0x /f These registry entries are only applicable to version 9.0. I hope someone else has a cleaner solution... Cheers, David Gerdt wrote: Jeremias- Thanks for this thorough explanation. Very helpful. And I wasn't really thinking bug. I assumed that there was something in the various specs (like the margin issue you mentioned with PCL) that was playing games with me. And thanks for the heads up about the settings in Acrobat. You were correct. I'm guessing there's no way to disable scaling/auto rotate/center within the PDF itself via FOP. That's certainly not a necessity, just curious. Thanks again for all the work. Jeremias Maerki [EMAIL PROTECTED] 5/9/2008 3:27 AM I guess that goes into my department again. ;-) Problem 1: Most likely you've fallen into the trap that you forgot to disable the Page Scaling setting in Acrobat Reader's print dialog. That has been the case in 95% of the cases similar problems were reported here. Problem 2: Another problem that I think occurs here is that in PCL I cannot print without margins. If I have text that is too close to the paper edge, it is indented. I have never found a way to print text all the way to the upper/left page edge in PCL 5. That's just a language limitation which is explicitely mentioned in the language spec. Especially with these labels where the text is very near to the paper edges such shifting effects are to be expected. Anyway, just to be sure I compared PDF and PCL output locally with your labels.fo. The only change I've applied to the file is that I switched to A4 because I don't have letter-sized paper. I sent the generated PCL to my Brother HL-1250 directly and printed the PDF via Acrobat Reader with all page scaling options (even page centering) off. If you don't do that you can't be sure that the margins are really those you specified in FO. My result: The two pages are nearly identical. What I could see is that the first table column is shifted to the right because of the problem 2 I noted above. If I just compare columns 2 and 3, the output has differences in the area of 0.3mm which I think can be tolerated. Also note in this context that PDF and PCL use different font metric sources (PDF: FOP's own font subsystem, PCL: the same as the Java2D-based renderers). You can see the effect yourself if you generate the intermediate format for both renderers: fop -fo labels.fo -at application/pdf labels.pdf.at.xml fop -fo labels.fo -at application/x-pcl labels.pcl.at.xml So this difference accounts for different line break decisions in more complex situations. You can work around that to a certain degree. See: http://markmail.org/message/n3myr6scq6afh7uz Just as an illustration how the two output formats differ, I've generated bitmap versions of the PDF and PCL with GhostScript and GhostPCL and created a comparison image using TortoiseSVN's bitmap differ. The result is attached. You'll see that the two output formats use slightly different fonts and that the first column is shifted to the right as mentioned above. You can also see from background-colors I applied to some table-cells that PCL cannot paint its cell background all the way to the right paper edge. But the rest is practically identical even though the intermediate files are slightly different due to font metric differences. Conclusion: Not a FOP bug. :-) On 08.05.2008 18:17:11 David Gerdt wrote: I'm curious as to the differences between how distances are measured between different output formats. I've been trying to get a sheet of address labels to align correctly and am noticing a vast difference between how they are rendered in a PDF vs how they appear in PCL. I use a combination of Eclipse and the Orangevolt XSLT plugin to develop my style sheets and generate PDFs on a WinXP box because I can quickly see the results. Ultimately, the documents will be rendered on an AIX system, normally (though not always) as PCL. There are instances where the same document can be rendered in either of these two formats, and that's why these differences make me nervous. In the case of the mailing labels, I'm noticing about a 1mm difference in height for the table cells. PDF cells are right at 26mm and PCL at 27mm. That sounds like a very slight difference, but it adds up to a 1cm difference over the ten rows of the sheet of labels. Also, the top margin has a difference of about 5mm between the two formats, with the first table row starting at 17mm in the PDF output and about 12mm for the PCL
