gmane.text.xml.fop.devel

DO NOT REPLY [Bug 46319] New: OutOfMemoryError after generating several thousand pdfs

2008-12-01T22:40:04

https://issues.apache.org/bugzilla/show_bug.cgi?id=46319 Summary: OutOfMemoryError after generating several thousand pdfs Product: Fop Version: 0.95 Platform: Other OS/Version: Linux Status: NEW Severity: critical Priority: P1 Component: pdf AssignedTo: fop-dev< at >xmlgraphics.apache.org ReportedBy: adrian.meyer< at >crealogix.com After upgrading from fop 0.20.5 to fop 0.95 our web application crashes after generating about 15000 small size pdfs (max. 1-12 pages) with the following exception: (number of bytes varies) Exception java.lang.OutOfMemoryError: requested 65536000 bytes for GrET* in /BUILD_AREA/jdk1.5.0_10/hotspot/src/share/vm/utilities/growableArray.cpp. Out of swap space? Before crashing used heap and process memory are growing slowly but continously. (USER_MEM_ARGS="-Xmx3072m -XX:PermSize=128m") We already tried using newest xalan/xerces libraries (from 2.7.1 xalan distribution) and also appli

DO NOT REPLY [Bug 46315] fox:needs-balancing extension

2008-12-01T12:18:45

https://issues.apache.org/bugzilla/show_bug.cgi?id=46315 Vincent Hennebert gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #22970|0 |1 is obsolete| | --- Comment #2 from Vincent Hennebert gmail.com> 2008-12-01 04:18:44 PST --- Created an attachment (id=22971) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22971) Version 1, modified to basically do the job Hi Georg, Thanks for the patch. This is basically what needs to be done. I attach a modified version of your patch with the following comments: - you don't need to do anything on the Flow object actually. Since the property is defined as inherited, the property sub-system will take care of this automatically. - it's best to move the definition of the property from the createBlockAndLineProperties method to createLayoutProperties (where t

AW: AW: empty columns on multi-column-page

Georg Datterl — 2008-12-01T11:43:05

Hi everybody, AbstractBreaker.doLayout() creates a blockList for the fo:block. This list contains (I guess) a KnuthBlockBox for each line and a KnuthPenalty for each possible break. This list is correct, there are two boxes before the first break and two boxes after the last break, as required by orphan and widow parameter. Obviously the break after the first line is introduced later, I guess somewhere down doPhase3(). I had a look, but I didn't find the offending break, probably because I don't know what it would look like. There are lots of addAreas and Positions, LayoutManagers and Markers. Where could this break possibly get inserted and what would it look like in a debugger? Regards, Georg Datterl ------ Kontakt ------ Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Rea

DO NOT REPLY [Bug 46315] fox:needs-balancing extension

2008-12-01T10:37:55

https://issues.apache.org/bugzilla/show_bug.cgi?id=46315 --- Comment #1 from Georg Datterl geneon.de> 2008-12-01 02:37:55 PST --- Created an attachment (id=22970) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22970) Version 1

DO NOT REPLY [Bug 46315] New: fox:needs-balancing extension

2008-12-01T10:36:44

https://issues.apache.org/bugzilla/show_bug.cgi?id=46315 Summary: fox:needs-balancing extension Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: general AssignedTo: fop-dev< at >xmlgraphics.apache.org ReportedBy: gd< at >geneon.de This is how far I got (if the attachment is correct): Parameter value is transfered from fo:flow to Flow. Parameter value is transfered from fo:block to Block. Parameter is inherited from Flow if not specified in Block. Parameter value is used in LayoutContext. Open issues: How and where do I transfer the parameter value from Block to LayoutContext?

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

2008-12-01T10:24:22

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 --- Comment #8 from Jeremias Maerki apache.org> 2008-12-01 02:24:21 PST --- Created an attachment (id=22969) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22969) Proposed way to approach this problem. I've attached a patch that shows how I would approach the problem. I've done some testing but not enough to simply commit the changes. For example, I haven't checked FileSpecs which I changed, too, as they are also using "string" objects (they would have the same problem when encrypted). I assume Andreas could combine this with his changes. Anyway, a second pair of eyes would be good here. Let me know I should commit the changes. A more critical part could be the equals() methods that I removed from many classes I converted. I added an equals()/hashcode() pair to PDFDictionary to compensate but I'm not sure if any of this is needed and if it still works as before.

Re: AW: empty columns on multi-column-page

Chris Bowditch — 2008-12-01T10:20:50

The patch should be a Unified Diff file created a standard Subversion Tool. On Windows we use Tortoise for all SVN operations and this can create a Unified Diff File. Regards, Chris

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

2008-12-01T09:28:53

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 --- Comment #7 from Peter Coppens gmail.com> 2008-12-01 01:28:52 PST --- I kind of already wondered whether there would not be other cases where this issue would be present (which seems to come from 'forgetting' to invoke an encoding/encryption method before writing out the PDF). I guess that is confirmed now and obviously architectural improvements where it is just no longer possible to create this bug are to be preferred compared to an adhoc fix. That is why I said (..I doubt it's the most optimal approach...). But for now I am all set (having a local fix on 0.95) and I guess the next release will have the issue fixed (in a better way). Thanks for moving this forward (and helping me out).

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

2008-12-01T09:05:15

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 --- Comment #6 from Jeremias Maerki apache.org> 2008-12-01 01:05:13 PST --- I'm sorry that I'm a little late here but I fear the approach you both have taken is probably not the best one. Some background: When I write the PDF-in-PDF extension I needed generic PDF structures (arrays, dictionaries etc.) to I could easily transform the PDFBox model into something that can be processed by FOP's PDF library. That's when I introduced PDFArray, PDFDictionary & Co. The thing is: I've only converted some of the existing PDF classes to use the generic structures, yet. Now, fixing the encryption problem only for this special case seems like a bad idea. You may remember we had a similar problem with the PDF outlines (fo:bookmark) in the past. So we're essentially fixing the same bug in different places. A better idea would be to convert the existing PDF classes to use the generic structures when they need to be touched. Yesterday, I've had some tr

Re: DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

Jeremias Maerki — 2008-12-01T08:48:25

I think it should be safe to make them private. If there's a reason to make the protected we'll hear about it soon. On 30.11.2008 23:22:49 Andreas Delmelle wrote: Jeremias Maerki

Bug report for Fop [2008/11/30]

2008-12-01T07:08:11

+---------------------------------------------------------------------------+ | Bugzilla Bug ID | | +---------------------------------------------------------------------+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned | | | OPN=Reopened VER=Verified (Skipped Closed/Resolved) | | | +-----------------------------------------------------------------+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement TRV=Trivial | | | | +-------------------------------------------------------------+ | | | | Date Posted | | | | | +--------------------------------------------------+ | | | | | Description | | | | | | | | 1063|Ne

AW: empty columns on multi-column-page

Georg Datterl — 2008-12-01T06:57:56

Hi Vincent, Are there any guidelines what the patch should look like? Georg Datterl ------ Kontakt ------ Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de Willmy Consult & Content GmbH: www.willmycc.de

Re: DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

Andreas Delmelle — 2008-11-30T22:22:49

Regarding those 'cleanups', I noticed that all of the object lists in PDFDocument currently are protected. Does this have a reason? I changed most of the protected instance variables to private, since they didn't reveal any dependencies within FOP (= all necessary access goes via the public accessors). Are there implementors I should be aware of here? Andreas

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

2008-11-30T22:12:02

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 --- Comment #5 from Andreas L. Delmelle apache.org> 2008-11-30 14:12:01 PST --- I started playing with it myself, and I had the idea of registering the URI as a separate object, to be referenced by the links. Not sure, but it seems a cleaner and more comprehensive approach for cases where an identical URI is referenced by many links. OTOH, it could have drawbacks, in case a large number of different URIs is referenced by only one link at a time (?) Changes made in a nutshell: 1. PDFDocument -> added List of uris + accompanying findUriAction() method 2. PDFFactory -> added getUriAction() method, which depends on 1. -> changed getExternalAction() accordingly: replace instantiations to go through getUriAction() 3. PDFUri -> change getAction() implementation to return the PDF object reference (like PDFGoTo does) -> change toPDFString() to contain the code contained in Peter's suggested PDFObject.encodeText2() I'll try t

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

2008-11-30T11:47:50

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 --- Comment #4 from Andreas L. Delmelle apache.org> 2008-11-30 03:47:49 PST --- Adding my response to Peter's suggestions here too: --- 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. ---

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

2008-11-30T11:45:00

https://issues.apache.org/bugzilla/show_bug.cgi?id=41959 --- Comment #3 from Andreas L. Delmelle apache.org> 2008-11-30 03:44:59 PST --- Recently reported again on fop-users< at > by Peter Coppens, who made progress towards a fix: --- 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

DO NOT REPLY [Bug 41959] External links are broken if pdf is encryped

2008-11-29T13:37:03

Re: empty columns on multi-column-page

Vincent Hennebert — 2008-11-28T15:03:12

Hi Georg, Georg Datterl wrote: At that point, you may want to create a bug report on FOP’s bugzilla and attach a patch with your current modifications, so that we can have a look at it and provide you with early guidance. https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop Vincent

AW: AW: empty columns on multi-column-page

Georg Datterl — 2008-11-28T13:29:13

Hi Vincent (and others, if somebody wants to join, it's not a private conversation), That's possible. I could, by default, translate a given space-before of x into a space-before.minimum=".9*x" space-before.optimum="x" space-before.maximum="1.1*x" Actually, the inheritance is working fine. I have a tree structure with flow and blocks and foxNeedsBalancing is set correctly. But PageBreaker calls LayoutContext.getFoxNeedsBalancing(), so somewhere I have to call LayoutContext.setFoxNeedsBalancing(Block.getFoxNeedsBalancing()). I'm just not yet sure, where. Well, I need the orphan-widow function too. So it's an issue anyway. But one for next week. Which, of course, is not the case. Tables, images, headlines, ... Well, a bridge to cross when I reach it. Regards, Georg Datterl ------ Kontakt ------ Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36

Re: AW: empty columns on multi-column-page

Vincent Hennebert — 2008-11-28T12:10:39

Hi Georg, Georg Datterl wrote: Actually you would play with the space-before/after properties: If the difference between minimum and maximum is big enough, that should give FOP enough of flexibility to reach the bottom of the columns all the time. The widow and orphans properties might create trouble, although at their default values of 2 that should be ok. (Yes, sorry.) Alright, it’s not an error then and is quite sensible actually. I’m hoping that FO tree specialists will chime in to give you hints on that regard. Hopefully there’s not much to do to get this inheritance behaviour. This is normal and due to the ‘orphans’ and ‘widows’ properties... Errr... no, this is not normal at all actually. There’s enough space to put the last two lines of the ‘L’ paragraph on the first column. And, speaking about that, the ‘orphans’ property on

DO NOT REPLY [Bug 45342] AFP Renderer does not properly handle AFP fonts with relative metric

2008-11-28T11:18:32