Re: PDFName.getName() returns escaped name?!
On 03/04/12 01:16, Vincent Hennebert wrote: From a quick look that sounds about right. Are you developing with a 1.7 JDK? You would have to make your code 1.5-compatible. Also, it would be good if you could back your optimizations with profiling data. If code safety/readability have to be compromised there has to be a good reason for it. Yep, I'm on 1.7, but was building for a 1.5 target and source level. The posted PDFName is really an example of what I'm thinking of; it's not something that can be seriously merged without a *lot* of changes across the rest of the tree to convert String name handling to PDFName, to check for leading /s being added, to check for use of toString() in name output to PDF data, etc. It's more a starting point for discussion and to see what kind of interest there is in working on the pdf lib. It looks like folks here are pretty receptive to significantly reworking the PDF lib if there's someone willing to stump up the time. That might well be me if it turns out porting the whole renderer to PDFBox instead turns out to be lots harder than reworking the fop pdf lib. I suspect not. That said, please do feel free to give it a try if that route appeals to you. We would certainly consider a switch if it looks more promising in the long term. I'm wondering how practical it'd be to progressively adopt PDFBox, actually, rather than doing an abrupt and total switch. The PDF primitives in PDFBox (COSName, COSNumber, COSDictionary, etc) are modeled extremely similarlines as those in FOP's PDF library, and while they won't be drop-in replacements they behave very similarly, just with different method names and in some cases different datatype assumptions (PDFName instead of String dictionary keys for example). The only truly big difference looks to be in the handling of indirect objects, where FOP uses one class that may be direct or indirect, and PDFBox uses a dedicated `COSObject' class that wraps other objects for indirect objects. If it proves possible to do a largely 1:1 substitution of PDFBox primitive PDF classes for FOP ones that'd *greatly* simplify the job of moving to using the PDFBox `PD' model for document output, and would let the job be done in a couple of distinct and separate chunks. PDFFont, PDFXObject, etc would build on top of the COS types like COSDictionary, COSBase and COSObject, rather than on top of PDFObject, PDFDictionary, etc. It's not a perfect 1:1 mapping; notable imperfect matches where one or more classes map to one or more different classes include: FOP PDFBOX --- java.lang.String, COSName (for PDF names) FOP PDFText java.lang.String (for Unicode text) byte[] or a binbuf/binstr class (for binary data) --- PDFNumber COSNumber COSInteger COSFloat --- ??? (j.l.Boolean?) COSBoolean --- PDFObject COSBase (direct) COSObject (wraps a COSBase, indirect) PDFDocument COSDocument [+a new class with fop-only functionality] PDDocument Of those, the first already needs a cleanup as noted previously; fop uses String for at least two distinct and incompatible things (Unicode text and raw binary data) that must be separated anyway. The second doesn't look to be a big deal as COSNumber has factory methods to take care of it, it's pretty transparent. I'm not too worried about boolean handling either. The bigger ones are the different model for indirect objects, and the non-trivial work to move PDFDocument to extend/wrap COSDocument. I haven't looked into this in enough depth to have a meaningful assessment of how hard either of those would be yet. OTOH, some of the important ones map pretty directly, allowing for the differences in handling of indirect and direct objects higher up the inheritance tree: FOP PDFBOX -- PDFDictionary COSDictionary PDFArrayCOSArray PDFStream COSStream PDFNull COSNull If I get time (big if, at the moment) I'll see if I can have a play and determine what kind of work is involved in doing this. -- Craig Ringer
DO NOT REPLY [Bug 53005] wrapper is not a block item
https://issues.apache.org/bugzilla/show_bug.cgi?id=53005 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Glenn Adams gl...@skynav.com 2012-04-03 16:39:02 UTC --- http://svn.apache.org/viewvc?view=revisionrevision=1309024 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: A proposal to change the configuration and deployment of FOP
Thanks for the extensive explanation, Mehdi (and Chris)! First, I'd like to stress that I'm not putting out a veto here. I'm just trying to take the position of an advocate to the FOP users who might not all follow the development closely. Back on the technical side: A JAXP TransformerFactory is just as mutable as the FopFactory, but only if it's handled wrongly by the developer of the client code. In the application I'm currently working on, the FopFactory is created once based on the configuration and registered as an OSGi service. All client code using the FopFactory (service) is written as if the FopFactory is immutable. Yes, I'm counting on the participants to play nice although I can still proxy the FopFactory if need be. And my application is also targeted to be deployable in the cloud (I hate that wishy-washy term) and already works with zero access to the local file system. So to be frank, I still see squeeky clean, best practice design (which is in itself nothing but good) being put before continuity (or API stability) without an absolute need for an API break to enable cloud-compatibility. And I personally weigh API stability higher than design principles. The world isn't perfect. However, I see no problem improving the URI resolution the way you propose it as long as it is done in a backwards-compatible way. Again, no veto, just my opinion. I might be the only one here who sees it that way. On 02.04.2012 16:25:21 mehdi houshmand wrote: Hi Jeremias/Chris, First thing first; I'll second Jeremias's suggestion and Chris in saying that this is definitely a major release. The best reason is because we're purposefully changing behaviour. FOP is currently very flexible in handling URIs, it has a lot of contingency mechanisms for falling back if a file can't be found. These are great when FOP is invoked on the commandline, however, they have to be controlled in a cloud environment and unauthorised file access cannot be allowed. If users are relying on these contingencies, then they're going to find they have issues and I think that's a compelling reason for calling it a major change. Jeremias, as for being unconvinced about the necessity of making these API changes, I'd say it's a shame you didn't hear the conversations we had here about it. I started this body of work a while ago, and took a lot of steps to avoid changing the API for 2 reasons: 1) The reasons you gave above 2) We're changing FOPs behaviour, changing the API as well, I was afraid the community wouldn't support so many changes. I'm not sure if this is an acceptable reason or not, but it played a big part in my thought process. However, it's just not feasible to unify URI resolution to a single mechanism to be used in a highly parallelised system if there is mutability in the member variables. Mutability in FopFactory means that FOP isn't thread-safe, changing the FopFactory in one thread could have repercussions in other threads, so we had to lock this down. Because there's some set up in FopFactory that requires I/O, the base-URI and the URI resolver have to be available from the start, from initialization of FopFactory. Unfortunately it's that simple. And we thought, since we're changing the API in an incompatible way (adding parameters to FopFactory.newInstance(...), we might as well take this time to update and improve the way FopFactory is built. The biggest problem being the disparity between when FopFactory is setup using a populated fop.xconf, an empty fop.xconf and no fop.xconf. The way we've implemented it, the API isn't actually changing very much, there're about 2/3 lines of code changes depending on if you're using a fop conf or not. The only thing I have left to say is that the system just wasn't designed for what we're asking it to do now. When FopFactory was written, clouds were in the sky and SaaS was a typo. For better or worse though, that's where the industry is putting its resources and if we want FOP to remain relevant, we've got to keep up with it. I know I'm preaching to the choir here, but we feel these changes are an improvement and they are a necessary part of the task. When we push up the changes to the temp branch, hopefully you'll be much more convinced that what we've done is a) an improvement and b) necessary. Mehdi On 2 April 2012 13:46, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 01/04/2012 15:47, Jeremias Maerki wrote: Hi Jeremias, Thanks for your feedback. I'm answering in place of Peter who is on holiday this week. Thanks for elaborating, Peter. Your use of the term deployment is indeed rather unorthodox. When I read deployment, I instantly think: http://en.wikipedia.org/wiki/**Software_deploymenthttp://en.wikipedia.org/wiki/Software_deployment I'm afraid you still haven't convinced me of the necessity to break the public API even if, as you say, it's only a minimal change. It's the difference
Re: A proposal to change the configuration and deployment of FOP
Glenn, I see the IF API as an advanced use case for FOP. I've realized from the beginning that the IF might have to mature over time and that requires changes. My main concern in the whole discussion is stability for the large majority of FOP's users who just rely directly or indirecly (in the case of XML editors and such) on relatively easy upgrades, especially if FOP can one day be released more often (with an easier release process). Just a thought loosely related to this: maybe we should introduce a version attribute on the root element to indicate the version of IF XML format so people can deal more easily with that. Maybe there should be a registry of FOP's APIs and the stability policy for each. On 02.04.2012 17:15:58 Glenn Adams wrote: On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: There must be a really, really good reason to change the frontmost public API of FOP in a backwards-incompatible way. Changing the API will cause considerable work for all users when they upgrade. We must not do that on a whim. Would you consider a minor, but substantive technical change to the IF APIs, specifically, to IFPainter, to require a revision of the major version? I ask this because one of the arguments to IFPainter.drawText() has been changed from int[] to int[][] in the recent complex scripts merge. In other words, are the IF public APIs to be considered part of the formal public FOP API that is subject to version control rules? Do we have a precise list of which APIs are (or should be) subject to such rules? Jeremias Maerki
Re: A proposal to change the configuration and deployment of FOP
On Tue, Apr 3, 2012 at 1:54 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Glenn, I see the IF API as an advanced use case for FOP. I've realized from the beginning that the IF might have to mature over time and that requires changes. My main concern in the whole discussion is stability for the large majority of FOP's users who just rely directly or indirecly (in the case of XML editors and such) on relatively easy upgrades, especially if FOP can one day be released more often (with an easier release process). Just a thought loosely related to this: maybe we should introduce a version attribute on the root element to indicate the version of IF XML format so people can deal more easily with that. good idea; i will add Maybe there should be a registry of FOP's APIs and the stability policy for each. ditto On 02.04.2012 17:15:58 Glenn Adams wrote: On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: There must be a really, really good reason to change the frontmost public API of FOP in a backwards-incompatible way. Changing the API will cause considerable work for all users when they upgrade. We must not do that on a whim. Would you consider a minor, but substantive technical change to the IF APIs, specifically, to IFPainter, to require a revision of the major version? I ask this because one of the arguments to IFPainter.drawText() has been changed from int[] to int[][] in the recent complex scripts merge. In other words, are the IF public APIs to be considered part of the formal public FOP API that is subject to version control rules? Do we have a precise list of which APIs are (or should be) subject to such rules? Jeremias Maerki
DO NOT REPLY [Bug 3824] MIF option with tables
https://issues.apache.org/bugzilla/show_bug.cgi?id=3824 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #4 from Glenn Adams gl...@skynav.com 2012-04-03 20:32:26 UTC --- MIF output format is no longer maintained -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 9379] MIF Renderer generates incorrect MIF code
https://issues.apache.org/bugzilla/show_bug.cgi?id=9379 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #3 from Glenn Adams gl...@skynav.com 2012-04-03 20:32:58 UTC --- MIF output format is no longer maintained -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48393] FOP should provide SVG DTD
https://issues.apache.org/bugzilla/show_bug.cgi?id=48393 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Glenn Adams gl...@skynav.com 2012-04-03 20:36:49 UTC --- needs more detail in problem description -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 38862] No ImageReader for this type of image
https://issues.apache.org/bugzilla/show_bug.cgi?id=38862 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-03 20:47:09 UTC --- please provide a test input FO file, an output PDF file (if any), and console output (if any); otherwise this bug will be moved to resolved+invalid -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 35948] pre-patch for FOrayFont adaptation to Fop
https://issues.apache.org/bugzilla/show_bug.cgi?id=35948 --- Comment #12 from Glenn Adams gl...@skynav.com 2012-04-03 20:58:26 UTC --- vincent, should this bug remain open? is the proposed patch still needed? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52398] build fails (fop-1_0)
https://issues.apache.org/bugzilla/show_bug.cgi?id=52398 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 37116] ESC POS Renderer
https://issues.apache.org/bugzilla/show_bug.cgi?id=37116 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #14 from Glenn Adams gl...@skynav.com 2012-04-03 21:02:28 UTC --- lack of consensus to patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52398] build fails (fop-1_0)
https://issues.apache.org/bugzilla/show_bug.cgi?id=52398 John Poole jlpool...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Comment #1 from John Poole jlpool...@gmail.com 2012-04-03 22:16:37 UTC --- This issue was changed to RESOLVED and works for me without any comment. I do not understand why the status has been changed without comment. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 52398] build fails (fop-1_0)
https://issues.apache.org/bugzilla/show_bug.cgi?id=52398 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-03 23:24:52 UTC --- (In reply to comment #1) This issue was changed to RESOLVED and works for me without any comment. I do not understand why the status has been changed without comment. no comment was needed since WORKSFORME speaks for itself; i do not encounter a build error when building from tag fop-1_0 (see output below); if you have new information that warrants reopening this bug, then please do so; otherwise, i am again moving to resolved... bash-3.2$ svn info Path: . Working Copy Root Path: /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0 URL: http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0 Repository Root: http://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1309184 Node Kind: directory Schedule: normal Last Changed Author: vhennebert Last Changed Rev: 1141997 Last Changed Date: 2011-07-01 11:25:44 -0600 (Fri, 01 Jul 2011) bash-3.2$ ant -version Apache Ant(TM) version 1.8.2 compiled on October 14 2011 bash-3.2$ javac -version javac 1.6.0_29 bash-3.2$ uname -a Darwin sn-ga-01.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 bash-3.2$ ant all Buildfile: /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build.xml init-avail: [echo] --- Apache FOP 1.0 [1999-2010] [echo] See build.properties and build-local.properties for additional build settings [echo] Apache Ant(TM) version 1.8.2 compiled on October 14 2011 [echo] VM: 20.4-b02-402, Apple Inc. [echo] JAVA_HOME: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home [echo] JAI Support PRESENT [echo] JCE Support PRESENT [echo] JUnit Support PRESENT [echo] XMLUnit Support PRESENT [snip] resourcegen: [mkdir] Created dir: /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/codegen-classes [javac] /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build.xml:354: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 3 source files to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/codegen-classes [copy] Copying 2 files to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/codegen-classes [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/accessibility/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/afp/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/area/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/fo/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/fo/flow/table/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/fonts/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/layoutmgr/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/layoutmgr/inline/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/render/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/render/bitmap/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/render/pcl/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/render/pdf/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/render/ps/event-model.xml [eventResourceGenerator] Event model written to /users/glenn/Work/xmlgraphics/fop/tags/fop-1_0/build/gensrc/org/apache/fop/render/rtf/event-model.xml [eventResourceGenerator] Event model written to
Re: A proposal to change the configuration and deployment of FOP
Yes, if you changed IF on me I'd need to know. I embed postscript commands in headers and page sequences. That said - if you are talking the java side of it versus the file format itself that doesn't affect me (but of course it may others) Thanks Martin --- Martin Edge --- On 04/04/2012, at 5:54 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: Glenn, I see the IF API as an advanced use case for FOP. I've realized from the beginning that the IF might have to mature over time and that requires changes. My main concern in the whole discussion is stability for the large majority of FOP's users who just rely directly or indirecly (in the case of XML editors and such) on relatively easy upgrades, especially if FOP can one day be released more often (with an easier release process). Just a thought loosely related to this: maybe we should introduce a version attribute on the root element to indicate the version of IF XML format so people can deal more easily with that. Maybe there should be a registry of FOP's APIs and the stability policy for each. On 02.04.2012 17:15:58 Glenn Adams wrote: On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: There must be a really, really good reason to change the frontmost public API of FOP in a backwards-incompatible way. Changing the API will cause considerable work for all users when they upgrade. We must not do that on a whim. Would you consider a minor, but substantive technical change to the IF APIs, specifically, to IFPainter, to require a revision of the major version? I ask this because one of the arguments to IFPainter.drawText() has been changed from int[] to int[][] in the recent complex scripts merge. In other words, are the IF public APIs to be considered part of the formal public FOP API that is subject to version control rules? Do we have a precise list of which APIs are (or should be) subject to such rules? Jeremias Maerki
Re: A proposal to change the configuration and deployment of FOP
On Tue, Apr 3, 2012 at 5:26 PM, Martin Edge martin.e...@intellimail.com.auwrote: Yes, if you changed IF on me I'd need to know. I embed postscript commands in headers and page sequences. That said - if you are talking the java side of it versus the file format itself that doesn't affect me (but of course it may others) The recent complex scripts patch changed both the IFPainter API and the IF schema in minor, but substantive ways. [1][2] [1] http://www.mail-archive.com/fop-dev@xmlgraphics.apache.org/msg12614.html [2] http://www.mail-archive.com/fop-dev@xmlgraphics.apache.org/msg14721.html
