Re: JIRA access
+1 On 24/05/2015 20:53, Glenn Adams wrote: I would not have any problem with that if the group wishes to do so. On Sun, May 24, 2015 at 1:37 PM, Clay Leeds the.webmaes...@gmail.com mailto:the.webmaes...@gmail.com wrote: Hi Glenn, Does it make sense to give all PMCs admin rights? IMHO committees could but we can draw the line somewhere. ;-) Cheers! Clay -- My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On May 24, 2015, at 10:34 AM, Glenn Adams gl...@skynav.com mailto:gl...@skynav.com wrote: I've added Andreas to the Committer role on both FOP and XGC. Also, I've added you (Luis) to the Administrator role on FOP and XGC. Someone besides me should be able to administrate these projects. On Sun, May 24, 2015 at 7:38 AM, Luis Bernardo lmpmberna...@gmail.com mailto:lmpmberna...@gmail.com wrote: You need to be added to one of the roles that is able to resolve issues before you can do that. For FOP and XGC only Glenn has admin rights. For BATIK both Glenn and I have. On 5/24/15 12:47 PM, Andreas Delmelle wrote: Hi Just wondering: Should I be able to set JIRA issues to 'Resolved' or assign them to myself, or does this require someone else (Glenn?) to provide me with the appropriate permissions first? If the latter, can you take care of this? Thanks! KR Andreas
[VOTE] Release XML Graphics FOP 2.0 (2nd attempt)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is a vote to release XML Graphics FOP 2.0. Findbugs is passing. Artifacts can be found there: https://people.apache.org/~ssteiner/fop-2.0 The release is signed with the key: https://people.apache.org/~ssteiner/KEYS The vote will end on 2/6/2015 +1 from me. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVZC+NAAoJEFuT8d98223qmbQQALDSXQIf+owqV/s/5eXfvSu3 EvzQtgu6RZEfL6TwZZX/iY3/7RtTF5OPz6b+i9QFpH2TN5fmLM7A720tK0IAjhB1 oU9RdKH4dakii7uRUOoolGVOAav0K0DDF1/3HSxf1Ys11CraRqKSGEnJH4WYI1Pv xvGgQvFpRP2oQm12jTcfx9rolqijDykboEH+uCUF+MzNSoFMo/W93Id4CLpskr3O /m+cNXz0YqUdwnsD/1HrzfauozLR/jDOWePj3OnOyw+CXzrtmtil7fytIHzg1YD3 B2t7+0InDVgEEqY94ojMXTGB9f/5iYfw/Gol4kg40o7H+9FXdO4YoduE5G7qEaKb k9QGwaN4DG74vIlB4DtCdJONI9ikgj6xDA8LV/e6XmpFcKEFmsk6HVgoRU9NKKyI jH+r4baa2tlR+cGJgeAr8SgjAQ3cf67ynRXBP74k9RPFATwCt5f+9GAVzV+Q/IDd LODw0S+2oKmI1lXPS5pLqeoeo7ccBPlI8rzqTd+9L0RqBQ5K7YmUI2ZngqU86NjV 1GC5R/caPd1kbnhS6alZAKDj5XAv26kHp/wtHPkKcsdBAcpQk+GjEC7UotD1s0VI B0Xja4VBxpUyLIp1jcDTkPe0JgXM7CqjY+Y40CCJeJSek2F/HpRy4QKJcZJYUW0v NM66eXRXoVEfVRrkwQqq =Xhjn -END PGP SIGNATURE-
Re: [VOTE] Release XML Graphics FOP 2.0 (2nd attempt)
+1 On 26/05/2015 09:33, Simon Steiner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is a vote to release XML Graphics FOP 2.0. Findbugs is passing. Artifacts can be found there: https://people.apache.org/~ssteiner/fop-2.0 The release is signed with the key: https://people.apache.org/~ssteiner/KEYS The vote will end on 2/6/2015 +1 from me. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVZC+NAAoJEFuT8d98223qmbQQALDSXQIf+owqV/s/5eXfvSu3 EvzQtgu6RZEfL6TwZZX/iY3/7RtTF5OPz6b+i9QFpH2TN5fmLM7A720tK0IAjhB1 oU9RdKH4dakii7uRUOoolGVOAav0K0DDF1/3HSxf1Ys11CraRqKSGEnJH4WYI1Pv xvGgQvFpRP2oQm12jTcfx9rolqijDykboEH+uCUF+MzNSoFMo/W93Id4CLpskr3O /m+cNXz0YqUdwnsD/1HrzfauozLR/jDOWePj3OnOyw+CXzrtmtil7fytIHzg1YD3 B2t7+0InDVgEEqY94ojMXTGB9f/5iYfw/Gol4kg40o7H+9FXdO4YoduE5G7qEaKb k9QGwaN4DG74vIlB4DtCdJONI9ikgj6xDA8LV/e6XmpFcKEFmsk6HVgoRU9NKKyI jH+r4baa2tlR+cGJgeAr8SgjAQ3cf67ynRXBP74k9RPFATwCt5f+9GAVzV+Q/IDd LODw0S+2oKmI1lXPS5pLqeoeo7ccBPlI8rzqTd+9L0RqBQ5K7YmUI2ZngqU86NjV 1GC5R/caPd1kbnhS6alZAKDj5XAv26kHp/wtHPkKcsdBAcpQk+GjEC7UotD1s0VI B0Xja4VBxpUyLIp1jcDTkPe0JgXM7CqjY+Y40CCJeJSek2F/HpRy4QKJcZJYUW0v NM66eXRXoVEfVRrkwQqq =Xhjn -END PGP SIGNATURE- - To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: general-h...@xmlgraphics.apache.org
Re: [VOTE] Release XML Graphics FOP 2.0 (2nd attempt)
+1 Cheers! Clay -- My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On May 26, 2015, at 1:33 AM, Simon Steiner simonsteiner1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is a vote to release XML Graphics FOP 2.0. Findbugs is passing. Artifacts can be found there: https://people.apache.org/~ssteiner/fop-2.0 The release is signed with the key: https://people.apache.org/~ssteiner/KEYS The vote will end on 2/6/2015 +1 from me. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVZC+NAAoJEFuT8d98223qmbQQALDSXQIf+owqV/s/5eXfvSu3 EvzQtgu6RZEfL6TwZZX/iY3/7RtTF5OPz6b+i9QFpH2TN5fmLM7A720tK0IAjhB1 oU9RdKH4dakii7uRUOoolGVOAav0K0DDF1/3HSxf1Ys11CraRqKSGEnJH4WYI1Pv xvGgQvFpRP2oQm12jTcfx9rolqijDykboEH+uCUF+MzNSoFMo/W93Id4CLpskr3O /m+cNXz0YqUdwnsD/1HrzfauozLR/jDOWePj3OnOyw+CXzrtmtil7fytIHzg1YD3 B2t7+0InDVgEEqY94ojMXTGB9f/5iYfw/Gol4kg40o7H+9FXdO4YoduE5G7qEaKb k9QGwaN4DG74vIlB4DtCdJONI9ikgj6xDA8LV/e6XmpFcKEFmsk6HVgoRU9NKKyI jH+r4baa2tlR+cGJgeAr8SgjAQ3cf67ynRXBP74k9RPFATwCt5f+9GAVzV+Q/IDd LODw0S+2oKmI1lXPS5pLqeoeo7ccBPlI8rzqTd+9L0RqBQ5K7YmUI2ZngqU86NjV 1GC5R/caPd1kbnhS6alZAKDj5XAv26kHp/wtHPkKcsdBAcpQk+GjEC7UotD1s0VI B0Xja4VBxpUyLIp1jcDTkPe0JgXM7CqjY+Y40CCJeJSek2F/HpRy4QKJcZJYUW0v NM66eXRXoVEfVRrkwQqq =Xhjn -END PGP SIGNATURE- - To unsubscribe, e-mail: general-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: general-h...@xmlgraphics.apache.org
Re: [VOTE] Release XML Graphics FOP 2.0 (2nd attempt)
+1. Thanks for all the work on FB fixes. On Tue, May 26, 2015 at 2:33 AM, Simon Steiner simonsteiner1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is a vote to release XML Graphics FOP 2.0. Findbugs is passing. Artifacts can be found there: https://people.apache.org/~ssteiner/fop-2.0 The release is signed with the key: https://people.apache.org/~ssteiner/KEYS The vote will end on 2/6/2015 +1 from me. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVZC+NAAoJEFuT8d98223qmbQQALDSXQIf+owqV/s/5eXfvSu3 EvzQtgu6RZEfL6TwZZX/iY3/7RtTF5OPz6b+i9QFpH2TN5fmLM7A720tK0IAjhB1 oU9RdKH4dakii7uRUOoolGVOAav0K0DDF1/3HSxf1Ys11CraRqKSGEnJH4WYI1Pv xvGgQvFpRP2oQm12jTcfx9rolqijDykboEH+uCUF+MzNSoFMo/W93Id4CLpskr3O /m+cNXz0YqUdwnsD/1HrzfauozLR/jDOWePj3OnOyw+CXzrtmtil7fytIHzg1YD3 B2t7+0InDVgEEqY94ojMXTGB9f/5iYfw/Gol4kg40o7H+9FXdO4YoduE5G7qEaKb k9QGwaN4DG74vIlB4DtCdJONI9ikgj6xDA8LV/e6XmpFcKEFmsk6HVgoRU9NKKyI jH+r4baa2tlR+cGJgeAr8SgjAQ3cf67ynRXBP74k9RPFATwCt5f+9GAVzV+Q/IDd LODw0S+2oKmI1lXPS5pLqeoeo7ccBPlI8rzqTd+9L0RqBQ5K7YmUI2ZngqU86NjV 1GC5R/caPd1kbnhS6alZAKDj5XAv26kHp/wtHPkKcsdBAcpQk+GjEC7UotD1s0VI B0Xja4VBxpUyLIp1jcDTkPe0JgXM7CqjY+Y40CCJeJSek2F/HpRy4QKJcZJYUW0v NM66eXRXoVEfVRrkwQqq =Xhjn -END PGP SIGNATURE-
Quick JIRA question
Hi all I recently discovered two JIRA issues logged against FOP that I think are actually one and the same issue in XGC (see: https://issues.apache.org/jira/browse/FOP-2343) I still have to verify locally that my proposed fix in XGC would fix the issue in FOP, but was wondering how to proceed. Does one usually a) create a new JIRA issue, against XGC, and then link the other two to that one, or b) reassign those issues to XGC (if that is even possible?) ? TIA! KR Andreas
[jira] [Assigned] (FOP-1488) [PATCH] orphans/widows not respected in some cases
[ https://issues.apache.org/jira/browse/FOP-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle reassigned FOP-1488: Assignee: Andreas L. Delmelle [PATCH] orphans/widows not respected in some cases -- Key: FOP-1488 URL: https://issues.apache.org/jira/browse/FOP-1488 Project: FOP Issue Type: Bug Components: unqualified Affects Versions: trunk Environment: Operating System: All Platform: All Reporter: Andrew McFarland Assignee: Andreas L. Delmelle Attachments: FOP-1488-code.patch, FOP-1488-test.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328_test.patch, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, widow.fo When I process the following fo, I get a PDF with a one-line widow at the start of the second page, even though widows for that fo:block is set to 4. ?xml version=1.0 encoding=ISO-8859-1? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=A4 fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:blockParagraph/fo:block fo:block widows=4 linefeed-treatment=preserve line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line line /fo:block /fo:flow /fo:page-sequence /fo:root -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Q - Internal API preference? (It started with a 'simple' TODO...)
Hi FOP devs and other interested parties, Apologies in advance for the rather long post... Note - If code structure and style is not your thing, feel free to ignore the whole post, otherwise, you may just want to go get a drink and some snacks, and bear with me. ;) A few weeks ago, as I started browsing the codebase to re-familiarize myself, I noticed a TODO in a comment in the layoutmgr.KnuthSequence class, decided to have a crack at resolving it, and... Well, after spending some hours reshuffling things, I have already triggered and dealt with enough cascading changes that I am seriously thinking about committing it all to a branch. One of the things that got me wondering is the extensive usage of the standard Java Collections API. Admitted, it's all very convenient to add new code for newcomers. It is relatively easy to donate patches if you are familiar with the basic Java API and have 'example' code blocks a few lines up or in the superclass... On the other hand, over time, as more and more new pieces got added, and these patterns got basically copy-pasted all over the place, I feel this convenience may have actually made the code *less* comprehensible overall. What I was thinking --and what may have prompted someone[*] else to put that TODO there in the first place-- is that the layout engine, internally, could be refactored to rely *entirely* upon KnuthSequences, in turn extracted as an interface. Explicitly avoid implementing or extending the List interface there, and instead, just create a basic AbstractKnuthSequence implementation that serves as a wrapper around a java.util.List, encapsulating all the List interactions into proprietary methods, rather than implementing the List interface itself. That way, the methods defined in the interface and the base class can be (re)designed and named such, that FOP's own code in the LayoutManagers may eventually become easier to read and follow (?) If properly implemented, *any* List implementation can be passed to the AbstractKnuthSequence constructor, rather than always using an ArrayList, as it does now (which currently makes it a not-so-good idea to use KnuthSequence across the board). Where we now have: List contents = new java.util.$ListType(); This would become: KnuthSequence contents = new $SequenceType( new java.util.$ListType() ); At the same time, that would also be virtually the only reference to the JCF, and the remainder of the method body would be written more in terms of the KnuthSequence interface. A Java 'dialect', if you will, that we then have complete control over. If deemed necessary, a KnuthSequence can still provide a List view of itself, although I would make it read-only (i.e. Collections.unmodifiableList()). Any mutations (writes) would be handled via either a restricted set of API methods, or via an Iterator or ListIterator... So far, the improvements in my sandbox are minimal, but definitely already noticeable. Changes are still very localised, though, as I have not yet gotten around to trying to change this in high-impact areas (like the main LayoutManager interface). I have, in the meantime, adapted all the inline level LMs to work exclusively with KnuthSequences, which seems to work pretty well. OTOH, I have not yet fully ironed out some measures I had to put in, to ease the transition, like making it possible for a KnuthSequence to behave like a ListElement, to be able to have a generic ListListElement backing the sequence. Not entirely sure how best to tackle that one. Current solution: extracted ListElement interface and implemented it in AbstractKnuthSequence. There seemed to be only a handful of places in the layoutmgr.inline package where a switch from the interface to the class was really necessary to get it all working, so perhaps there is a better way. The concept of nested sequence-elements just looked kind of cool, for now... Maybe we should keep them, just for that. ;) Now, before I move further towards the block level LMs, I thought I'd throw it out there, and see what comes back. Thoughts, anyone? Any strong preferences (for or against)? Positive/negative experiences with such stuff (encapsulating standard Java API calls in proprietary interfaces vs. just sticking to plain ol' standard Java)? Looking forward to your feedback, [*] I traced it back to a commit made by Adrian, but cannot be sure if he himself added it, or whether the comment was put there by Alexander Kiel who submitted the patch. http://svn.apache.org/viewvc?view=revisionrevision=825646 KR[**] Andreas [**] BTW, Clay pointed out to me off-list that this abbreviation may not be as common as I took it to be. For those wondering, it is short for Kind Regards, although Clay's suggestion of Keep it Real would also work for me. :)
[jira] [Updated] (FOP-2276) currentFObj is not updated if Throwable is thrown
[ https://issues.apache.org/jira/browse/FOP-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2276: - Attachment: FOP-2276.patch Attached a small patch proposal. Problem is, I currently do not immediately have an idea how to test whether this would really solve the issue... I would have to create a test case that somehow simulates this behaviour, i.e. forced throwing of a SAXException and attempt to continue processing. If anyone has ideas, even if very vague, feel free to speak up. currentFObj is not updated if Throwable is thrown - Key: FOP-2276 URL: https://issues.apache.org/jira/browse/FOP-2276 Project: FOP Issue Type: Bug Components: fo/unqualified Affects Versions: 1.1 Reporter: Daniel Dracott Assignee: Andreas L. Delmelle Attachments: FOP-2276.patch If an exception is thrown during org.apache.fop.fo.FOTreeBuilder.MainFOHandler.endElement(String, String, String), then the line currentFObj = currentFObj.getParent(); does not get executed. If the SAX event source decides to store the exception and continue, then subsequent endElement calls can generate SAXExceptions of the form: Caused by: org.xml.sax.SAXException: Mismatch: page-sequence (http://www.w3.org/1999/XSL/Format) vs. root (http://www.w3.org/1999/XSL/Format) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:338) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:181) ... Some implementations of javax.xml.transform.Transformer that we have used will attempt to perform further endElement calls in this way and the SAXException can hide the original Throwable, making diagnosis of problems difficult. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release XML Graphics FOP 2.0 (2nd attempt)
+1 from me, too. ... and, you are all very welcome. :) Andreas On 26 May 2015, at 15:31, Glenn Adams gl...@skynav.com wrote: +1. Thanks for all the work on FB fixes. On Tue, May 26, 2015 at 2:33 AM, Simon Steiner simonsteiner1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is a vote to release XML Graphics FOP 2.0. Findbugs is passing. Artifacts can be found there: https://people.apache.org/~ssteiner/fop-2.0 The release is signed with the key: https://people.apache.org/~ssteiner/KEYS The vote will end on 2/6/2015 +1 from me. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVZC+NAAoJEFuT8d98223qmbQQALDSXQIf+owqV/s/5eXfvSu3 EvzQtgu6RZEfL6TwZZX/iY3/7RtTF5OPz6b+i9QFpH2TN5fmLM7A720tK0IAjhB1 oU9RdKH4dakii7uRUOoolGVOAav0K0DDF1/3HSxf1Ys11CraRqKSGEnJH4WYI1Pv xvGgQvFpRP2oQm12jTcfx9rolqijDykboEH+uCUF+MzNSoFMo/W93Id4CLpskr3O /m+cNXz0YqUdwnsD/1HrzfauozLR/jDOWePj3OnOyw+CXzrtmtil7fytIHzg1YD3 B2t7+0InDVgEEqY94ojMXTGB9f/5iYfw/Gol4kg40o7H+9FXdO4YoduE5G7qEaKb k9QGwaN4DG74vIlB4DtCdJONI9ikgj6xDA8LV/e6XmpFcKEFmsk6HVgoRU9NKKyI jH+r4baa2tlR+cGJgeAr8SgjAQ3cf67ynRXBP74k9RPFATwCt5f+9GAVzV+Q/IDd LODw0S+2oKmI1lXPS5pLqeoeo7ccBPlI8rzqTd+9L0RqBQ5K7YmUI2ZngqU86NjV 1GC5R/caPd1kbnhS6alZAKDj5XAv26kHp/wtHPkKcsdBAcpQk+GjEC7UotD1s0VI B0Xja4VBxpUyLIp1jcDTkPe0JgXM7CqjY+Y40CCJeJSek2F/HpRy4QKJcZJYUW0v NM66eXRXoVEfVRrkwQqq =Xhjn -END PGP SIGNATURE-
