Re: Building from current TRUNK fails

Hi Jan > On 26 Jul 2016, at 22:15, Jan Tosovsky wrote: > > Dear All, > > I've updated local copy to the current (mavenized) version and I am unable > build (Oracle JDK 1.8) the FOP Core project: > (1) testAES256() fails with > java.lang.IllegalStateException: java.security.InvalidKeyException:

Re: FOP change-bar support

Hi Tom > On 22 Jul 2016, at 23:34, Furst,Thomas wrote: > > Hi Andreas, > > I am new to attempting to be a part of FOP development. Where can I learn > more about how to apply a patch? I imagine I need to get the source download, > do I just update the file(s) outlined in the patches at the gi

Re: FOP change-bar support

Hi Tom > On 20 Jul 2016, at 21:13, Furst,Thomas wrote: > > I use FOP to publish XML for technical manual content. Do so, there are times > where we need to indicate where a change has been applied to the document. I > know the FO tags exist, just that FOP does not currently support this markup

Re: [VOTE] Merge from xmlgraphics/fop/branches/maven to trunk

Hi Checked out the branch and ran the Maven install build in IDEA without issues. Looks good on my end, so +1 from me. Cheers Andreas > On 13 Mar 2016, at 04:13, Glenn Adams wrote: > > I would like to start a vote on merging from xmlgraphics/fop/branches/maven > [1] to trunk [2]. Please resp

Re: [jira] [Commented] (FOP-2540) Enhance TTF/OTF support beyond Windows

> On 29 Nov 2015, at 15:28, Glenn Adams wrote: > > On Sun, Nov 29, 2015 at 3:05 AM, Andreas L. Delmelle (JIRA) > wrote: > > [ > https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030875#comment-15030875 >

Re: Build failed in Jenkins: xmlgraphics-fop #181

Heads-up: will look into this in more detail tonight. Andreas > On 26 Nov 2015, at 22:52, Apache Jenkins Server > wrote: > > See > > Changes: > > [adelmelle] Minor fixups: alter classpath for junit-transcoder-allinone to > avoid N

Re: IPDAdjust

> / >> Unfortunately, the original reporter did not take the time to reduce >> the example to a 'minimal' one. >> ... >> which makes it more difficult to pinpoint the cause. >> > > I am willing to reduce it a bit, but all next week I won't have an access to > my PC. No worries, I already got th

Re: Change bars status

Hi Jan > On 14 Jul 2015, at 22:40, Jan Tosovsky wrote: > > > Where exactly inline blocks are appended to the list and passed to the flow? That would be the LayoutManager.addAreas() implementations. I am still not familiar enough with the details of the patch, but if I had to guess, it seems

Re: Change bars status

Hi Jan > On 10 Jul 2015, at 23:05, Jan Tosovsky wrote: > >> https://issues.apache.org/jira/browse/FOP-1760 > > In the original patch there is used Vector for storing ChangeBars > collection. > > http://stackoverflow.com/questions/1386275/why-is-java-vector-class-consider > ed-obsolete-or-depr

Re: svn commit: r1690138 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontInfo.java

> On 09 Jul 2015, at 20:37, adelme...@apache.org wrote: > > Author: adelmelle > Date: Thu Jul 9 18:37:31 2015 > New Revision: 1690138 > > URL: http://svn.apache.org/r1690138 > Log: > Minor tweak: avoid using standard toString() for detailed diagnostics purposes Some background: The issues rela

Re: Change bars status

Hi Jan Thanks for your efforts so far in getting this moving forward! As to your question: > > Btw, what is preferred dummy text? Currently I use The Universal Declaration > of Human Rights (Article 1). Is it Ok? No real preference here. Your suggestion is OK. In general, in typesetting, a "l

Re: xercesImpl dependency

Hi Luis > On 25 Jun 2015, at 16:39, Luis Bernardo wrote: > > > Does anyone know why we have the xercesImpl jar in the lib directory? > Apparently we don't need it to compile and run the unit tests. This is unlike > xalan which we need for the unit tests. Good question... I am not 100% certai

Re: Change bars status

Hi Jan > On 07 Jun 2015, at 19:39, Jan Tosovsky wrote: > I've found some progress on 'change bar' support here > > https://issues.apache.org/jira/browse/FOP-1760 > > discussed further here: > > http://apache-fop.1065347.n5.nabble.com/Change-bars-support-in-FOP-td38134.h > tml > > There is me

Re: Unable to produce PDF using cmdline from trunk code

Hi Jan > > before reporting one issue I tried to test the trunk first, but any > conversion fails with the error below. I built FOP from sources using 'ant > package' and executing commands (Windows) > fop input.fo output.pdf > > Is this something to do with my build or FOP itself? The final jar

Re: FOP -> POI

Hi Jan, Matthias, > On 28 May 2015, at 21:29, Jan Tosovsky wrote: > > Hi Matthias, > > On 2015-05-27 Matthias Reischenbacher wrote: >> >> I know pptx a bit, because I had to implement an output channel based >> mainly on XSLT and a little bit of java (used mainly for zip >> compression). > >

Re: FOP -> POI

Hi Jan > On 27 May 2015, at 21:22, Jan Tosovsky wrote: > > On 2015-05-25 Andreas Delmelle wrote: >> >> it seems like it may just be possible to achieve something like >> this by means of FOP's Intermediate Formats[*], which can already >> be utilise

Re: [jira] [Issue Comment Deleted] (FOP-2469) [PATCH] auto table layout

FYI - Comment actually had nothing to do with the patch, so decided to remove it, so as to not let Gregor's fine work drown in unrelated ranting... > On 27 May 2015, at 21:07, Andreas L. Delmelle (JIRA) wrote: > > > [ > https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.ji

Re: Q - Internal API preference? (It started with a 'simple' TODO...)

Hi Glenn > On 27 May 2015, at 18:36, Glenn Adams wrote: > > One significant risk in a major rewrite of an important section is > regression. This is particularly true given the paucity of tests in FOP. You > will have to assume that such a rewrite is going to produce a number of > regressions

Re: Q - Internal API preference? (It started with a 'simple' TODO...)

> On 27 May 2015, at 01:59, Luis Bernardo wrote: > Hi Luis > > In my view any code that does more becomes more complex, not less > comprehensible. The same happens with FOP. Very true, indeed. I recall having argued that same point on this list in the past. "Doing more with less" is, IMO,

Re: [jira] [Updated] (FOP-2469) [PATCH] auto table layout

Hi Gregor Just a heads-up, if you're reading this: We (I) have not forgotten. :) Will probably have more time next week to have a closer look at your work. Thanks for updating the Wiki, BTW. That stuff is very valuable info! KR Andreas > On 27 May 2015, at 15:51, Gregor Berg (JIRA) wrote:

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.

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 starte

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 wrote: > > +1. Thanks for all the work on FB fixes. > > On Tue, May 26, 2015 at 2:33 AM, Simon Steiner > wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi, >> >> Thi

Re: FOP -> POI

> On 25 May 2015, at 21:16, Jan Tosovsky wrote: > Hi Jan > can you hypothetically imagine any way how to convert virtual page objects > to the office document structure? I actually I think of 'Slides' to PPTX > (XSLF) conversion. Very interesting question... Somewhat related, as I recall, a su

Re: JIRA access

> On 24 May 2015, at 15:38, Luis Bernardo 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. OK, thanks for the info. We'll wait for Glenn to wake up,

JIRA access

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

Re: Fix FB warnings (was: Re: [VOTE] Release XML Graphics FOP 2.0)

> On 23 May 2015, at 23:15, Andreas Delmelle > wrote: > FYI - High and medium priority warnings addressed in r1681384, and absent an > answer to my question, assumed the lazy approach there, for now. > > Will try to have a look at the low priority ones tomorrow. ..

Re: Build failed in Jenkins: xmlgraphics-fop #108

> On 23 May 2015, at 23:11, Apache Jenkins Server > wrote: > > See Hmm... Quite strange that this message had to pass through moderation. Oh no, it's that blasted Jenkins spambot, again! ;-) KR Andreas

Fix FB warnings (was: Re: [VOTE] Release XML Graphics FOP 2.0)

> On 22 May 2015, at 22:36, Andreas Delmelle > wrote: > Is the convention then to insert the commented annotation once for every > field or does it suffice to add one per class? > > I am fine with both. Just thought I'd ask before committing to trunk. FYI - H

Re: [VOTE] Release XML Graphics FOP 2.0

> On 22 May 2015, at 17:04, Andreas Delmelle > wrote: > > Hi Simon > >> On 22 May 2015, at 12:59, Simon Steiner wrote: >> >> We have an old branch with findbugs passing I was going to port this to >> trunk. I realise now Simon's remark may have

Re: [VOTE] Release XML Graphics FOP 2.0

> On 21 May 2015, at 22:20, Andreas Delmelle > wrote: > > FWIW - Those 17 'high' priority "Reliance on default encoding" warnings are > definitely worth checking out. So far, I think the handful that I already > looked at can be safely added to the

Re: [VOTE] Release XML Graphics FOP 2.0

Hi Simon > On 22 May 2015, at 12:59, Simon Steiner wrote: > > We have an old branch with findbugs passing I was going to port this to > trunk. OK, sure. That works for me too. > > Findbugs 3 requires java 7 so we shouldn’t move to that yet. > Oh, I realize we cannot move to that, due to the

Re: [VOTE] Release XML Graphics FOP 2.0

> On 21 May 2015, at 20:47, Andreas Delmelle > wrote: > > > @Simon - > To relieve you of some of the burden, I am definitely willing to assist with > combing through those. How do I proceed? Do I commit related changes directly > to trunk, so that you can merge th

Re: [VOTE] Release XML Graphics FOP 2.0

> On 21 May 2015, at 20:47, Andreas Delmelle > wrote: > > If everyone had committed to using it in the past, there would not be 143 > warnings to address right before the release... Correction: 124 warnings... Mixing up 167 - 124 = 43. :)

Re: [VOTE] Release XML Graphics FOP 2.0

Hi guys > On 21 May 2015, at 20:00, Glenn Adams wrote: > > I would prefer no findbugs warnings going into the release. I'm finding > more and more commercial uses of code have policies that require no > findbugs warnings. You can simply add entries to the findbugs-exclude.xml > file to disable t

Re: [VOTE] Release XML Graphics FOP 2.0

I forget whether this type of vote is for all committers or only the PMC, but saw Robert vote as well, so just to be sure +1 from me as well. Thanks, Simon! KR Andreas > On 21 May 2015, at 15:21, Simon Steiner wrote: > > Signed PGP part > Hi, > > This is a vote to release XML Graphics FO

Re: [jira] [Commented] (FOP-2469) [PATCH] auto table layout

On 19 May 2015, at 22:44, Luis Bernardo wrote: > > > Try now (it should work if your account is AndreasDelmelle). We had to put > some ACLs in place due to spam. Should work for Gregor too. Aah, I had a vague suspicion that it was something in that direction... I recall seeing those abuses in

Re: [jira] [Commented] (FOP-2469) [PATCH] auto table layout

On 19 May 2015, at 19:45, Andreas Delmelle wrote: > > If anyone on with the appropriate karma is reading this: Can you please > assist Gregor? If I should be able to help him out myself, please let me know > what I can/should do, so that I can take care of it myself. Thanks! >

Re: [jira] [Commented] (FOP-2469) [PATCH] auto table layout

Hi people, > On 19 May 2015, at 15:58, Gregor Berg (JIRA) wrote: > Concerning documentation: I tried to use the fop wiki (i.e. > https://wiki.apache.org/xmlgraphics-fop/AutoTableLayout), but I require > permissions to edit anything. Could you please grant me access to the wiki? > Account: Gre

Re: [jira] [Comment Edited] (FOP-2349) Inline elements with letter-spacing and custom font aren't correctly sized

> On 17 May 2015, at 22:52, Glenn Adams wrote: > > On Sun, May 17, 2015 at 1:29 PM, Andreas L. Delmelle (JIRA) > > wrote: > > ... > > IIUC, a correct fix would first need to determine how many characters that > > "mcs" array leads > > to in the output, in order to set the number of letter sp

Re: [jira] [Commented] (FOP-2349) Inline elements with letter-spacing and custom font aren't correctly sized

Hi Glenn > On 17 May 2015, at 15:28, Glenn Adams wrote: > > IIRC, I ran out of time to re-integrate LS support for the complex script > path, for which your QD fix will not work. Specifically, mcs.length doesn't > equal number of base glyphs, but also includes combining glyphs. Thanks for the

Re: svn commit: r1679676 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp: ./ fonts/ modca/ modca/triplets/ svg/ util/

Just a heads-up to anyone using JDK 1.8 who is unaware, and tries to run FOP's javadoc target: You will get a torrent of warnings and errors about malformed/illegal HTML all over the place. > On 16 May 2015, at 04:10, adelme...@apache.org wrote: > > Author: adelmelle > Date: Sat May 16 02:10:4

Re: Float implementation - no reference in status.xml?

> On 08 May 2015, at 18:58, Clay Leeds wrote: > > We are no longer using .xml files for documentation… > > You need to follow the instructions here: > > https://www.apache.org/dev/cms.html Thanks! Definitely some catching up to do here! Just tried it, and looks straightforward enough. Strange

Float implementation - no reference in status.xml?

Hi all Something that caught my eye: while browsing status.xml, I could not find a reference to the basic side-float implementation that was merged into trunk a while back. Maybe it’s just me, but this is precisely the kind of enhancement I would want to see advertised in a future release. Get

Re: [jira] [Updated] (FOP-1488) [PATCH] orphans/widows not respected in some cases

Hi Luis OK, I planned to test those rights tonight, so good to hear. Thanks! KR Andreas > On 05 May 2015, at 23:55, Luis Bernardo wrote: > > > Andreas, you should still have commit rights, and you are welcome to commit > the patches. > > On 5/2/15 10:56 PM, Andreas L. Delmelle (JIRA) wrot

Re: Row span and keep-togehther.within-page problem

On 21 Mar 2011, at 18:51, Andreas Delmelle wrote: > On 21 Mar 2011, at 17:50, Vincent Hennebert wrote: > > Hi Vincent, Matthias, > >> Looks like you pinpointed the problem, well done. I’ve just submitted >> a fix, please test with your real-life file. >> http://svn

Re: Row span and keep-togehther.within-page problem

On 21 Mar 2011, at 17:50, Vincent Hennebert wrote: Hi Vincent, Matthias, > Looks like you pinpointed the problem, well done. I’ve just submitted > a fix, please test with your real-life file. > http://svn.apache.org/viewvc?rev=1083863&view=rev Not sure if Matthias also sees this, but as I pointe

Re: Row span and keep-togehther.within-page problem

On 19 Mar 2011, at 22:22, Matthias Reischenbacher wrote: (Note: actually slightly off-topic for the users list... ;-)) > Today I had been looking at the same code as you and I found it odd that the > table keep condition is only taken into account inside > TableStepper.getCombinedKnuthElementsFor

Re: [VOTE] Non-standard implementation of fo:basic-link

On 09 Mar 2011, at 17:44, Vincent Hennebert wrote: > I’d like to launch a vote for the integration of the patch from > Bugzilla #50763 [1] into the Trunk. I saw the related message a few weeks ago, and am inclined to vote Yea, since I agree with the basics. FOP's current behavior is counter-intu

Re: reference-orientation on side regions

On 09 Mar 2011, at 00:04, Vincent Hennebert wrote: > Why?? Where in the spec is that interpretation of the term > ‘reference-area’ given? > > OTOH, in Section 4.2.2: “An area for which [the is-reference-area] trait > is true is called a reference-area.” Arrghh, too liberal interpretation from

Re: reference-orientation on side regions

On 08 Mar 2011, at 21:26, Vincent Hennebert wrote: > > A viewport-area /is/ a reference-area. See section 4.2.2. I think we're almost there. From that section: "A common construct is a viewport/reference pair. This is a viewport-area V and a block-area reference-area R, where R is the sole c

Re: reference-orientation on side regions

On 04 Mar 2011, at 12:25, Vincent Hennebert wrote: > On 03/03/11 20:18, Andreas Delmelle wrote: >> >> Let's assume that this refers to the default/normal situation. After all, we >> are quoting the _general_ fo:region-before definition (= where no deviating >>

Re: svn commit: r1079013 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/ test/layoutengine/standard-testcases/

On 08 Mar 2011, at 00:04, adelme...@apache.org wrote: > Author: adelmelle > Date: Mon Mar 7 23:04:03 2011 > New Revision: 1079013 > > URL: http://svn.apache.org/viewvc?rev=1079013&view=rev > Log: > b49835 Errm... Sorry about that. Forgot to add a proper comment. Regards Andreas

Re: OpenType CFF fonts…

On 03 Mar 2011, at 22:07, Alex Zepeda wrote: Hi Alex > Over the years I've kept an eye on the lists. Every year it seems like > someone's interested, and someone's willing. Right now I guess I don't know > if anyone is actively working on /proper/ CFF support. So hopefully I'm not > steppin

Re: reference-orientation on side regions

On 03 Mar 2011, at 21:18, Andreas Delmelle wrote: > > So, specifying reference-orientation="90" on the region rotates its > reference-area by 90 degrees from the page-reference-area. Correction: this is still the 1.0-way of looking at it. In 1.1, this would have to be

Re: reference-orientation on side regions

On 03 Mar 2011, at 13:08, Vincent Hennebert wrote: >> Unless ... the viewport is where the actual rotation takes place. >> IIC, the region-viewport's before-edge is still parallel to the >> page-reference-area's before edge. The before-edge of the >> region-reference-area, however, is the one t

Re: reference-orientation on side regions

On 03 Mar 2011, at 13:08, Vincent Hennebert wrote: >> >>> Unless, of course, I have completely missed the point, which might well >>> be the case. >> >> Only forgot to check the history/legacy --as did I when I filed bug #46826 > > Frankly, I’m not willing to look at the XSL-FO 1.0 Recommendati

Re: reference-orientation on side regions

On 02 Mar 2011, at 22:30, Andreas Delmelle wrote: > > The implementation of the (from-page-master) function itself seems like a > simple thing to add. Even someone who doesn't know FOP's codebase should be > able to figure it out in no more than one day... (n

Re: FindBugs exclusion policy proposal

Just to be clear: my main issue was with maintaining the auto-exclusion policy in the longer term. I do not question the past decisions, nor did I intend to point fingers (even if only implicitly). If I enervated anyone by bringing this up again, my apologies. The more general context is avoid

Re: reference-orientation on side regions

On 02 Mar 2011, at 21:30, Vincent Hennebert wrote: To answer the final question first: > Any thoughts? Yep! Well, not many, but /some/... BTW: there is also Bugzilla 46826, which is related to reference-orientation. It is currently treated as an inherited property, which is non-compliant and l

FindBugs exclusion policy proposal (was: Re: junit tests in nightly builds etc.)

No response to any of the posts in particular, just a general thought/proposal. I can appreciate that the ComplexScripts branch requires a clean FB report so that Glenn is not continuously sent on a wild goose chase. However, personally (and Vincent seems to agree), I do not favor 'blind' exclu

Re: Assertions in junit tests [was: Re: Solving FindBugs issue]

On 22 Feb 2011, at 19:25, Andreas Delmelle wrote: > One way to enable assertions I found so far, and that seems to work: > - use fork="true" on the target > - insert: in that target > > That seems to yield the expected behavior at first glance. Our junit targets >

Re: svn commit: r1073518 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/util/ColorUtil.java

On 22 Feb 2011, at 22:38, adelme...@apache.org wrote: > Author: adelmelle > Date: Tue Feb 22 21:38:28 2011 > New Revision: 1073518 > > @@ -402,7 +398,6 @@ public final class ColorUtil { > > /* Ask FOP factory to get ColorSpace for the specified ICC > profile source */ >

Re: Solving FindBugs issues

On 22 Feb 2011, at 21:50, Andreas Delmelle wrote: > ColorUtil seems to be somewhat of a can of worms... > If I judge correctly, for some (if not most) of the methods, there seems to > be no need for a try-catch block (?) Sorry, forgot RuntimeExceptions, of course, which are conve

Re: Solving FindBugs issues

On 22 Feb 2011, at 20:39, Andreas Delmelle wrote: > ... > --and so, I caved in started already... In PDFFactory, I have some conflicts to work out first, but the fix-up is rather simple there. In the respective methods, eliminate all unnecessary boxing and use explicit (double) casts

Re: Solving FindBugs issues

On 22 Feb 2011, at 20:15, Vincent Hennebert wrote: > > Can we revert commit 1071912 and re-consider the issues one-by-one > before ignoring them? +1 As far as I can see, the raised warnings are really not so challenging that they cannot be addressed right away. Implementing an equals() method,

Re: Assertions in junit tests [was: Re: Solving FindBugs issue]

On 22 Feb 2011, at 19:04, Andreas Delmelle wrote: > On 22 Feb 2011, at 08:50, Simon Pepping wrote: >> It would be nice if assertions were checked during the junit tests. >> However, when I set: , I get >> junit.framework.AssertionFailedError errors. How can this be done? &g

Re: Solving FindBugs issue

On 22 Feb 2011, at 08:34, Simon Pepping wrote: > When I build the project or part of it with Eclipse, and run findbugs > afterwards (with ant), I get a number of errors. Now I always make a > clean compile before running findbugs. I do not understand why Eclipse > builds would create findbugs erro

Re: Assertions in junit tests [was: Re: Solving FindBugs issue]

On 22 Feb 2011, at 08:50, Simon Pepping wrote: > On Mon, Feb 21, 2011 at 08:28:33PM +0100, Andreas Delmelle wrote: >> I saw one exclusion --unconfirmed cast-- that would seem to stem from my >> recent refactoring in the BlockStackingLMs. Not sure why an exclusion was >> ch

Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java]

On 21 Feb 2011, at 22:18, Vincent Hennebert wrote: > Did you remove the corresponding entry from the findbugs-exclude.xml > file before running FindBugs again? Locally, yes, and confirmed that the assert eliminated the warning. The exclusions file seems to be needing some more general cleanup, s

Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java]

On 21 Feb 2011, at 21:18, Eric Douglas wrote: > I always had trouble with the ant build. > Currently my ant build gets no errors and no warnings and creates fop.jar > though it tells me junit and xmlunit are not found. > Last time I put jars in my fop lib folder for junit and xmlunit it told me

Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java]

On 21 Feb 2011, at 20:49, Eric Douglas wrote: > I haven't looked at the trunk lately but 1.0 has a ton of warnings, at > least in my compile. > I don't know how much warnings have changed over the versions. > I think it was originally written to compile on Java 1.4 or maybe even > 1.3. Even lower

Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java]

On 21 Feb 2011, at 20:28, Andreas Delmelle wrote: > On 21 Feb 2011, at 19:15, Vincent Hennebert wrote: > >> If we solve issues raised by FindBugs by listing them in an ignore file, >> is there still a point to use FindBugs at all? >> >> It seems to me that some

Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java]

On 21 Feb 2011, at 19:15, Vincent Hennebert wrote: > If we solve issues raised by FindBugs by listing them in an ignore file, > is there still a point to use FindBugs at all? > > It seems to me that some of those issues deserve to be fixed. They seem > to point out genuine problems in the code.

Re: svn commit: r1071282 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AlignmentContext.java

On 18 Feb 2011, at 15:18, Vincent Hennebert wrote: >> >> Please, do not revert other committers' changes. Discuss them if you >> have objections. > > Well I believe I already do that, don’t I? > > In this case the change had no relation to the commit message, and was > actually reverting what I

Re: new checkstyle warnings, findbugs in trunk

On 15 Feb 2011, at 19:21, Glenn Adams wrote: > Please fix the 2 new checkstyle warnings and 9 new findbug errors in trunk. > In the future, please check and fix before committing. People, when are we going to vote Glenn a committer, so we can answer with three simple words/letters... DIY ;-) Ju

Re: svn commit: r1068509 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java

On 08 Feb 2011, at 19:32, adelme...@apache.org wrote: > Author: adelmelle > Date: Tue Feb 8 18:32:15 2011 > New Revision: 1068509 > > URL: http://svn.apache.org/viewvc?rev=1068509&view=rev > Log: > Elimination of code duplication in getNextKnuthElements() Finally managed to really factor out th

Re: svn commit: r1067665 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockContainerLayoutManager.java

On 06 Feb 2011, at 14:40, adelme...@apache.org wrote: > Author: adelmelle > Date: Sun Feb 6 13:40:31 2011 > New Revision: 1067665 > > URL: http://svn.apache.org/viewvc?rev=1067665&view=rev > Log: > Code cleanup: > - reduce code duplication in getNextKnuthElements() > - removed references to expe

Re: svn commit: r1067533 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java

On 05 Feb 2011, at 22:49, adelme...@apache.org wrote: > Author: adelmelle > Date: Sat Feb 5 21:49:58 2011 > New Revision: 1067533 > > URL: http://svn.apache.org/viewvc?rev=1067533&view=rev > Log: > Code cleanup > > Modified: > > xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockS

Re: The base of relative URIs in fop.xconf

On 04 Feb 2011, at 17:40, Glenn Adams wrote: > so if one specifies > > file:///../fop.xml If I understand correctly, while it does not violate the URI syntax, this would not be considered a relative URI either way. That is, java.net.URI will consider it absolute, because it has a scheme compo

Re: svn commit: r1066275 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: KnuthPossPosIter.java PositionIterator.java

On 02 Feb 2011, at 00:46, adelme...@apache.org wrote: > Author: adelmelle > Date: Tue Feb 1 23:46:38 2011 > New Revision: 1066275 > > URL: http://svn.apache.org/viewvc?rev=1066275&view=rev > Log: > Add type safety to PositionIterator + attempt at javadoc improvement Note: while going over this,

Re: [VOTE] Merge FOP color branch into trunk

On 01 Feb 2011, at 20:23, Jeremias Maerki wrote: > Looks perfect. Thanks! If it's not too much trouble, please "svn copy" > the ColorProfileUtil from FOP Trunk so we retain the history and > document where this came from. Done. All related changes committed to both XGC and FOP. Regards, Andrea

Re: [VOTE] Merge FOP color branch into trunk

On 01 Feb 2011, at 13:24, Jeremias Maerki wrote: > Hmm, I don't see how any cruft can accumulate in there. Main and test > classes are properly separated. jar-main only packs build/classes. > Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?), > we need to update the JAR any

Re: testing bug fixes - not!

On 24 Jan 2011, at 23:17, Glenn Adams wrote: Hi Glenn > Is there a reason why *all* bug fixes are not accompanied by one or more new > test cases that demonstrate the presence and absence of the bug before and > after the fix? Adding such test cases should be mandatory for all bug fix > commi

Re: svn commit: r1062901 [1/2] - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/area: ./ inline/

On 24 Jan 2011, at 19:06, adelme...@apache.org wrote: > Author: adelmelle > Date: Mon Jan 24 18:06:25 2011 > New Revision: 1062901 > > URL: http://svn.apache.org/viewvc?rev=1062901&view=rev > Log: > Bugzilla 50593: Mostly add type safety to various collections in the fop.area > package. Addition

Re: [VOTE] Merge FOP color branch into trunk

On 19 Jan 2011, at 11:56, Jeremias Maerki wrote: > I've cleaned up the color branch, tweaked a few things and did some more > testing. I'm happy with the current state, so I'm calling for a vote to > merge the current FOP color branch into trunk. No detailed review done here, but from what I did

Re: DO NOT REPLY [Bug 50590] New: function fop_exec() doesn't work in fop.js launcher

On 17 Jan 2011, at 19:23, Simon Pepping wrote: > Wow, on the last day of the fourth year after I committed this script, > it is proven that someone actually uses it. :-) Same thought arose here after checking when the file was last altered... Regards, Andreas ---

Re: svn commit: r1059389 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/area/AreaTreeHandler.java

On 15 Jan 2011, at 21:11, Andreas Delmelle wrote: > IDTracker keeps a Map of idLocations. Currently, this is a Map List>, which, IIC, means that the IDTracker now keeps a hard > reference to all PageViewports in the document (associated with the fo:root > id), regardless of whet

Re: svn commit: r1059389 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/area/AreaTreeHandler.java

On 15 Jan 2011, at 19:51, adelme...@apache.org wrote: > Author: adelmelle > Date: Sat Jan 15 18:51:36 2011 > New Revision: 1059389 > > URL: http://svn.apache.org/viewvc?rev=1059389&view=rev > Log: > Enable id on fo:root pt 3 - Signal processed id at end of document Note: While doing this, I did

Re: svn commit: r1050342 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/inline/InlineStackingLayoutManager.java test/layoutengine/standard-testcases/inline_hyphenation_border.xml

On 17 Dec 2010, at 11:57, spepp...@apache.org wrote: Hi Simon Very minor nit. Sorry to be so late with this, but I was just reviewing some of last month's commits and ran into this one: > Author: spepping > Date: Fri Dec 17 10:57:18 2010 > New Revision: 1050342 > > URL: http://svn.apache.org

Re: DO NOT REPLY [Bug 49186] Empty fo:inline objects with id attribute generate blank line

On 07 Jan 2011, at 20:13, Eric Douglas wrote: Hi > > A lot of people put xsl tags in line as you've done there with > white-space-treatment, but I think it's easier to read if you split them > out to their own tags. Actually, I was just writing plain FO (= what results after applying the XSLT).

Re: DO NOT REPLY [Bug 48380] ClassCastException when using fox:widow-content-limit

On 07 Jan 2011, at 17:03, Simon Pepping wrote: > Your patch seems OK to me. Even though the conditionals handle some > tricky navigation through the list, this is the best way to use the > similarities between the two methods. > > Will you apply it? Sure, will do! Regards Andreas

Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.

On 07 Jan 2011, at 14:58, Simon Pepping wrote: > I had not yet thought so far. I reflected on the use of '#' as the > replacement character for missing glyphs. Is that not particular to > FOP, and should we not conform to Unicode and use the Unicode > replacement character in such situations? OK

Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.

On 07 Jan 2011, at 14:17, Simon Pepping wrote: Hi Simon, > On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: >> So, if no one objects, I will apply the patch as proposed. FOP will no longer >> crash, but simply show a '#' for such unassigned codepoints in the output. >> Treatin

Re: ConcurrentModificationException error

On 10 Dec 2009, at 03:24, Anil Pinto wrote: Hi Anil (Didn't see a response for this one come in, so far on fop-us...@... Apologies if the reply comes a bit late.) > We have FOP (0.95) embedded in a multithreaded environment to create many > PDFs almost simultaneously. > > We hav been using t

Re: FOP and large documents: out of memory

re-instantiate the String instead. I was thinking something similar should be possible here, but if it is really that far out of FOP's control, then never mind. Regards Andreas Andreas Delmelle mailto:andreas.delmelle.AT.telenet.be ---

Re: FOP and large documents: out of memory

On 13 Jan 2010, at 21:27, Stephan Thesing wrote: Hi Stephan, > Since increasing the heap space does not always work (3 GB heap space was > required in one example), I need a better solution for this. > > 1. "-conserve" option > One alternative would be the "-conserve" option, which serializes

Re: svn commit: r652467 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/BlockContainer.java

width/height made the whole thing more consistent. So... > > Would you agree to put those lines back into the current trunk version ? I'd rather not, but will leave this up to other devs (who have been more active lately) Regards Andreas Delmelle ---

Re: Implementing Change bars

des in order to allow them to occur at the allowed places. For the answer to this, see the pointer I gave about 'isNeutralItem()'. That's basically ALL that really needs to be modified in FObj AFAICT. Regards, Andreas Delmelle mailto:andreas.delmelle.AT.telenet.be jab

Re: Implementing Change bars

be under the influence of multiple change bars, naturally. Indeed, and if no offset is specified the bars will be drawn over each other. I'll get back on your further ideas ASAP. Regards, Andreas Delmelle mailto:andreas.delmelle.AT.telenet.be jabber: mandr...@jabber.org skype: adlm0608 ---

  1   2   3   4   >