gmane.text.xml.fop.user

How to use marker in order to print dynamic data into table-header?

gennady — 2008-12-01T22:08:52

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 "xxxx cont." and same table-header. But in my latest requirement I need to put not only title "xxxx 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

Re: Unresolved ID and page-number-citation allocated width

Sebastien — 2008-12-01T21:21:47

On Mon, Dec 1, 2008 at 9:39 PM, Andreas Delmelle < andreas.delmelle< at >telenet.be> wrote: 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... 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 n

Re: Unresolved ID and page-number-citation allocated width

Andreas Delmelle — 2008-12-01T21:11:30

On 01 Dec 2008, at 21:39, Andreas Delmelle wrote: 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

Re: Unresolved ID and page-number-citation allocated width

Andreas Delmelle — 2008-12-01T20:39:33

Hi 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). 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... 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 che

Re: 0.95 & Acrobat Performance Problems

Andreas Delmelle — 2008-12-01T20:01:01

Hi 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.) That would be unfortunate, and is something we would help to avoid, if only we knew where to start looking... :/ Cheers Andreas

RE: 0.95 & Acrobat Performance Problems

Griffin,Sean — 2008-12-01T19:53:14

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:egibler< at >zytron.net] Sent: Monday, December 01, 2008 1:40 PM To: fop-users< at >xmlgraphics.apache.org Subject: Re: 0.95 & Acrobat Performance Problems Thanks

Re: 0.95 & Acrobat Performance Problems

egibler — 2008-12-01T19:39:53

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 readi

Re: 0.95 & Acrobat Performance Problems

paul womack — 2008-12-01T16:11:17

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

Unresolved ID and page-number-citation allocated width

Sebastien — 2008-12-01T16:11:49

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: A 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 manage

0.95 & Acrobat Performance Problems

egibler — 2008-12-01T15:49:34

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, th

Re: spot colours

Jeremias Maerki — 2008-12-01T13:49:58

You're not the first: http://fop.markmail.org/search/?q=spot%20colors 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 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

spot colours

Iain Downs — 2008-12-01T12:52:02

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: [ANN] New release of PDF image support for Apache FOP

Peter Coppens — 2008-12-01T11:42:10

Thanks. It does help, Peter.

Re: [ANN] New release of PDF image support for Apache FOP

Jeremias Maerki — 2008-12-01T10:45:22

PDFBox < at >SourceForge ran on CVS. The code change I needed to make the plug-in work was this one: http://sourceforge.net/tracker/?func=detail&atid=552834&aid=1806912&group_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 Jeremias Maerki

Re: [ANN] New release of PDF image support for Apache FOP

Peter Coppens — 2008-12-01T10:36:12

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

Re: [ANN] New release of PDF image support for Apache FOP

The Web Maestro — 2008-11-30T16:47:30

Congratulations on the release, Jeremias! Your efforts are appreciated, and I suspect many will take advantage of your hard work! Regards, The Web Maestro

Re: Encryption garbles external link

Andreas Delmelle — 2008-11-30T11:42:53

Hi Peter Thanks for the effort in investigating a fix! Or maybe, we should do this in PDFLink#setAction() ? That seems to be the point where the PDFAction (PDFUri) is associated with the PDFLink. I already checked whether this had unwanted side-effects when the same URI is used in multiple links, but that does not seem to be the case. The parent link is only used to get to the ancestor document, which is obviously the same for all links. I'm wondering to what extent this new, separate method could be merged with the original encodeText(), maybe by changing the signature, and adding a second parameter to distinguish this case from the one covered by the original method. Anyway, this is all going a bit OT for the users-list. You're welcome to add any progress/potential patches to the Bugzilla entry directly. That way, when someone finally wants to address it, he doesn't have to delve through the list-archives... :-) I'll take care of adding these recent comments to the issue repo

Re: Encryption garbles external link

Peter Coppens — 2008-11-30T01:33:04

I have something that seems to be working, but I am not sure it is always correct and I doubt it's the most optimal approach. Here are the changes I did 1. PDFLink#toPDFString Added this.action.setParent(this); (would be better to do this when creating the PDFUri object ) 2. PDFUri#getAction public String getAction() { return "<< /URI (" + uri + ")\n/S /URI >>"; } --> public String getAction() { String uriString=new String(this.encodeText2(uri)); return "<< /URI " + uriString + "\n /S /URI >>"; } 3. Added PDFObject#encodeText2 protected byte[] encodeText2(String text) { if (getDocumentSafely().isEncryptionActive()) { final byte[] buf = PDFText.encode(text); byte[] enc = getDocument().getEncryption().encrypt(buf, this); return PDFText.toHex(enc,true).getBytes(); } else { return encode(PDFText.escapeText(text, false)); }

Re: Encryption garbles external link

Peter Coppens — 2008-11-29T14:56:12

Looks like the uri is not encrypted at all. The code that writes out the PDFLink object seems to completely skip the 'normal' pdf output processing and writes out text without going through the encodeText method from PDFObject. I tried to hack around a bit and after making sure PDFUri has its parent set to PDFLink (which it has not in the 0.95 code) something encrypted is written, but Acrobat still can not make sense of it. With the hack enabled I get << /Type /Annot /Subtype /Link /Rect [ 72.0 707.25 132.024 718.35 ] /C [ 0 0 0 ] /Border [ 0 0 0 ] /A << /URI (ö?§^[BÎ^OØ^^éOªûL^A;èÇ?%^Oµ?^G-?CS>^TÔñÏ?f:¯?±??!£?¯ÉÀ^]y?n¬??^OE5Ä}| ,^V) /S /URI >> /H /I (without the hack the URI is plain text) Unfortunately that is not what it should be...and I am clueless as to what is going wrong now. I guess I will have to dive in the encryption part of the pdf spec to figure out what exactly needs to be encrypted for Acrobat to be happy with it. Perhaps someone has suggestions on what might

Re: Encryption garbles external link

Peter Coppens — 2008-11-29T14:08:01

Thanks for the prompt feedback. I will try to get my head around the code and see whether I can come up with a possible suggestion for a fix Peter Andreas Delmelle-2 wrote:

Re: Encryption garbles external link

Andreas Delmelle — 2008-11-29T13:38:04

Hi Peter Seems like this is a known bug (since 0.92) that no one has got around to fixing yet... (see also: http://issues.apache.org/show_bug.cgi?id=41959) Cheers Andreas