[jira] [Created] (FOP-2576) FOP does not use configuration option hyphenation-base
Simon Pepping created FOP-2576: -- Summary: FOP does not use configuration option hyphenation-base Key: FOP-2576 URL: https://issues.apache.org/jira/browse/FOP-2576 Project: FOP Issue Type: Bug Components: unqualified Affects Versions: 2.1 Reporter: Simon Pepping Priority: Minor FOP 2.1 does not use the configuration option hyphenation-base. Instead it uses the option base. Places in the code: FopConfParser.configure, FopConfParser.setHyphPatNames: hyphenation-dir is not used. Instead, base-dir is used. FopFactoryBuilder has no method setHyphenationBaseURI. The stack Hyphenator.getUserHyphenationTree → Hyphenator.getHyphenationTreeStream → InternalResourceResolver.getResource → InternalResourceResolver.resolveFromBase clearly resolves from the base URI. The option hyphenation-base is documented at http://xmlgraphics.apache.org/fop/2.1/configuration.html, Summary of the General Configuration Options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2569) Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146539#comment-15146539 ] Simon Pepping commented on FOP-2569: Regarding ant's failure to report failure of the compile-hyphenation target: Current situation: Report failure for compile-hyphenation, but continue to build and exit with success. This is misleading. Desired: Upon a failure of compile-hyphenation, continue to build but exit with a failure and an appropriate message. Is this possible in ant? Possible solution: Add a fail condition to compile-hyphenation: >diff build.xml~ build.xml 447a448,454 > > NOTE: > ** > * One or more hyphenation patterns could not be compiled! * > * Please check the output above for relevant messages. * > ** > This makes the build fail if there are hyphenation pattern files in /hyph which cannot be compiled. This happens for target compile-hyphenation and all its dependent targets, specifically jar-hyphenation, package and all. If someone wants to build regardless of failures to compile hyphenation patterns, just do not have such patterns in the /hyph directory. > Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre > Fix For: 1.1 > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2569) Exception in thread "main" java.lang.StackOverflowError at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244)
[ https://issues.apache.org/jira/browse/FOP-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146508#comment-15146508 ] Simon Pepping commented on FOP-2569: The recursion at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) is correct, but it requires more stack size. Fix: >diff build.xml~ build.xml 184c184 < --- > This fix does not address the problem that ant fails to report the failure to compile the hyphenation patterns. > Exception in thread "main" java.lang.StackOverflowError at > org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > -- > > Key: FOP-2569 > URL: https://issues.apache.org/jira/browse/FOP-2569 > Project: FOP > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mathieu Malaterre > Fix For: 1.1 > > > fop + offo is broken since release 2.0 (and 2.1). It used to be possible to > build fop-hyph.jar using fop 1.1. Please resurrect a working hyph building > mechanism. > Here is what it states: > $ /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Xss512k -classpath > /home/mathieu/debian/fop/fop-2.1/build/classes > org.apache.fop.hyphenation.SerializeHyphPattern > /home/mathieu/debian/fop/fop-2.1/hyph > /home/mathieu/debian/fop/fop-2.1/build/classes/hyph > Processing /home/mathieu/debian/fop/fop-2.1/hyph/sa.xml > Exception in thread "main" java.lang.StackOverflowError > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > [...] > at org.apache.fop.hyphenation.TernaryTree.insert(TernaryTree.java:244) > See thread: > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201602.mbox/%3CCA%2B7wUszWN2PdZY_t_Kgn0E4eatL7CUQswOWj9XC%3Dg9GDdgsyXw%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Documentation of new testing tools
Mehdi has recommended himself to the FOP team by taking new initiatives, such as Junit4 and Jacoco. But where is the documentation? See e.g. the wiki page HowToCreateLayoutEngineTests: Does that still apply? How do I know what jacoco is and how to run it? Should I just be in the know? Please, consider adding and updating documentation of new and renewed build and test tools. Simon
Account mehdi created
Mehdi, The account mehdi has been created. I suppose you received a communication with the password. You are now a member of the xmlgraphics and xmlgraphics-fop groups, which grants you write access to the fop, commons and site repositories. Note that you must use the https protocol for your access to the repositories to enable writing. Success as a FOP developer, Simon Pepping
Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed
It is not a good idea to fetch xml.xsd from W3C each time. Put it in the sources and if necessary use a catalog. xml.xsd is already available at src/documentation/intermediate-format-ng/xml.xsd. Simon On Thu, Nov 10, 2011 at 08:27:53AM +, Jeremias Maerki wrote: > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at gene...@gump.apache.org. > > Project xml-fop-test has an issue affecting its community integration. > This issue affects 1 projects, > and has been outstanding for 61 runs. > The current state of this project is 'Failed', with reason 'Build Failed'. > For reference only, the following projects are affected by this: > - xml-fop-test : XSL-FO (Formatting Objects) processor > > > Full details are available at: > http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error messages) were > provided: > -INFO- Failed with reason build failed > -INFO- Project Reports in: > /srv/gump/public/workspace/xml-fop/build/test-reports >
Re: Merge branch Temp_ComplexScripts into trunk
I will not apply this patch. I will no longer be available to shepherd this project in FOP. Somebody else must take over this role. Simon On Sun, Nov 06, 2011 at 09:14:20PM -0700, Glenn Adams wrote: > Simon, > > I have created a patch [1] that, if applied to trunk as described in [2], > effectively merges the Temp_ComplexScript branch (updated with changes from > recent trunk commits) plus one bug fix for bidi content inside > fo:static-content. > > [1] http://issues.apache.org/bugzilla/attachment.cgi?id=27906 > [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c46 > > Attached to this message is the captured session of the steps I took in > creating this patch. > > I've verified that all junits pass, and no new checkstyle warnings are > introduced. There remain two new findbug warnings, however, introduced in > recent changes to the trunk, which I did not attempt to fix. Otherwise, a > build and test run are clean.
Re: Merge branch Temp_ComplexScripts into trunk
Ideally, the merge is performed in subversion. Earlier I noted that that gives a large number of document and tree conflicts. I do not have time to resolve them. If no team member picks this task up, a patch from Glenn is a good alternative solution. Glenn, can you attach it to the Bugzilla report? Can you indicate how you proceeded, and how you guarantee that the patch has the same result as a merge in Subversion? Simon Pepping On Sat, Oct 29, 2011 at 09:02:42AM +0800, Glenn Adams wrote: > Let me know how I may most expeditiously accomplish this work. In the mean > time, I will prepare a patch against trunk from the Temp_CS branch, which I > imagine Simon will be the one to apply. > > G. >
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Seven committers voted. There were five +1 votes and no -1 votes. There
was one -0.9 vote and one -0 vote.
According to the Project Charter three +1 ('yes' votes) with no -1
('no' votes or vetoes) are needed to approve a significant code
change. Therefore the proposal to merge the Temp_ComplexScripts branch
into trunk has been accepted.
Thank you for voting. I acknowledge that Vincent and Peter are not
convinced of the wisdom of this decision. I hope we can all move
forward with this new situation.
Simon
On Tue, Oct 25, 2011 at 10:31:43AM +0200, Simon Pepping wrote:
> With his latest patch, Glenn Adams wrote:
>
> With this latest patch I am satisfied that there is sufficient testing and
> stability in the CS branch to support its merger into trunk. Therefore, I
> request that such a merge be accomplished after applying patch 5 to the CS
> branch.
>
> ... snip ...
>
> Note that there remains work to be done on CS support, including adding
> support for:
>
>- additional scripts
>- additional output formats
>
> At present, support is provided for:
>
>- Arabic, Hebrew, and Devanagari Scripts
>- PDF output format
>
> I expect that additional support for other scripts and formats will be added
> over time, either by myself, or other members of the community. However, the
> absence of support for all complex scripts and all output formats should not
> be a deterrent to active use of the support already present. It is now a
> good time to broaden the user community of the CS features, and the best way
> to do that is to bring it into the trunk at this time.
>
> End of quote
>
> Following this request, I herewith propose to merge the branch
> Temp_ComplexScripts into trunk, and launch a formal vote.
>
> I vote positive: +1
>
> For the rules of voting about code commits, see the project charter,
> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>
> Simon Pepping
Re: Merge Request - Temp_ComplexScripts into Trunk
> > > Ninth, spending time changing variable names is a waste of time when I > > could > > > be working on adding support for other scripts. > > > > So someone else is going to have to waste all that time converting those > > names into more readable ones. That’s a bit unfair, isn’t it? > > > > I would advise against anyone wasting their time by changing my names. > Indeed, I will likely react very negatively to such an attempt. What you > want to do in your code is your business, but don't imagine you are going to > start rewriting my code to meet your style. Or at least don't do so if you > wish me to be a part of this team. > > I would take such an action as a direct affront. This is a big no. At the moment you hand in your code to FOP, it belongs to the community. Anyone can touch it. That is where team membership kicks in. Team members trust each other not to do bad things to the code. > > If in the indefinite future I am not working on this code, then feel free to > change it as you like. In the mean time, I'd appreciate a little respect. Respect yes, but not touching it, no. Simon Pepping
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
The vote runs for three days, and will end on Friday 28 October 2011 at 18:00h UTC. Simon Pepping On Tue, Oct 25, 2011 at 10:31:43AM +0200, Simon Pepping wrote: > > Following this request, I herewith propose to merge the branch > Temp_ComplexScripts into trunk, and launch a formal vote. > > For the rules of voting about code commits, see the project charter, > article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
[VOTE] Merge branch Temp_ComplexScripts into trunk
With his latest patch, Glenn Adams wrote: With this latest patch I am satisfied that there is sufficient testing and stability in the CS branch to support its merger into trunk. Therefore, I request that such a merge be accomplished after applying patch 5 to the CS branch. ... snip ... Note that there remains work to be done on CS support, including adding support for: - additional scripts - additional output formats At present, support is provided for: - Arabic, Hebrew, and Devanagari Scripts - PDF output format I expect that additional support for other scripts and formats will be added over time, either by myself, or other members of the community. However, the absence of support for all complex scripts and all output formats should not be a deterrent to active use of the support already present. It is now a good time to broaden the user community of the CS features, and the best way to do that is to bring it into the trunk at this time. End of quote Following this request, I herewith propose to merge the branch Temp_ComplexScripts into trunk, and launch a formal vote. I vote positive: +1 For the rules of voting about code commits, see the project charter, article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter. Simon Pepping
Re: Merge Request - Temp_ComplexScripts into Trunk
On Mon, Oct 24, 2011 at 09:05:34PM +0800, Glenn Adams wrote: > Sixth, I am going to be maintaining this code. If anyone has a problem with > specific code during a merge or regression, they merely need ask me. That is a big no. There will always be a moment when someone else must or wants to work on this code. FOP code cannot depend on a single person, it must be maintainable by other developers. Simon
Re: Merge Request - Temp_ComplexScripts into Trunk
I am pleased to learn that you are also in need of this new functionality. I share some of Vincent and Peter's concerns about technical points of the code. On the other hand, this is the only implementation of complex scripts we have, created by Glenn, in the style of Glenn. It is an initial implementation, and it is normal that it requires further work, maybe even design changes to make it more flexible. Does keeping it in a branch make that further work easier? Merging it into trunk will enhance its visibility, and make it available to more users. Simon On Thu, Oct 20, 2011 at 02:02:10PM +0100, Chris Bowditch wrote: > On 19/10/2011 19:32, Simon Pepping wrote: > > Hi Simon, > > I think you misunderstood my mail. I don't want to stop the merge. I > simply thought it was an appropriate time to discuss some concerns > that Vincent and Peter had identified. You are preaching to the > converted about the need for supporting Complex scripts. It is an > urgent requirement for us too. > > If we don't discuss our concerns over the code now, then when do we > discuss it? > > Vincent and Peter will be replying to this thread shortly and will > outline their primary concerns then. > > Thanks, > > Chris >
Re: Merge Request - Temp_ComplexScripts into Trunk
On Thu, Oct 20, 2011 at 02:53:54PM +0100, Vincent Hennebert wrote:
> Here are the sizes of some new files:
> 1075 src/java/org/apache/fop/fonts/GlyphSequence.java
> 1089 src/java/org/apache/fop/fonts/GlyphProcessingState.java
> 1269
> src/codegen/unicode/java/org/apache/fop/text/bidi/GenerateBidiTestData.java
> 2034 src/java/org/apache/fop/layoutmgr/BidiUtil.java
> 3449 test/java/org/apache/fop/complexscripts/util/TTXFile.java
>
> This latter one contains more than 50 field
> declarations, and the Handler.startElement method alone is more than
> 1800 lines long.
>
> Also, the o.a.f.fonts.truetype.TTFFile class has now grown to
> 5502 lines. That’s 3 times its original size which was already too big.
> I regularly find myself looking at bits of this class, and I would be
> unable to do so on a 5500 line class.
I agree that these are undesirably long.
> I don’t think it needs to be explained why big classes are undesirable?
>
> Also, most files disable Checkstyle checks, the most important ones
> being line length and white space. Many files have too long lines which
> makes it a pain to read through, having to horizontally scroll all the
> time. We agreed on a certain coding style in the project and it would be
> good if new code could adhere to it.
I agree that this is not in compliance with the code style of the FOP
project.
> Speaking of variable names, here is a method picked from
> o.a.f.fonts.GlyphSequence:
> /**
> * Merge overlapping and abutting sub-intervals.
> */
> private static int[] mergeIntervals ( int[] ia ) {
> int ni = ia.length;
> int i, n, nm, is, ie;
> // count merged sub-intervals
> for ( i = 0, n = ni, nm = 0, is = ie = -1; i < n; i += 2 ) {
> int s = ia [ i + 0 ];
> int e = ia [ i + 1 ];
> if ( ( ie < 0 ) || ( s > ie ) ) {
> is = s;
> ie = e;
> nm++;
> } else if ( s >= is ) {
> if ( e > ie ) {
> ie = e;
> }
> }
> }
> int[] mi = new int [ nm * 2 ];
> // populate merged sub-intervals
> for ( i = 0, n = ni, nm = 0, is = ie = -1; i < n; i += 2 ) {
> int s = ia [ i + 0 ];
> int e = ia [ i + 1 ];
> int k = nm * 2;
> if ( ( ie < 0 ) || ( s > ie ) ) {
> is = s;
> ie = e;
> mi [ k + 0 ] = is;
> mi [ k + 1 ] = ie;
> nm++;
> } else if ( s >= is ) {
> if ( e > ie ) {
> ie = e;
> }
> mi [ k - 1 ] = ie;
> }
> }
> return mi;
> }
>
It could be refactored as follows:
/**
* Merge overlapping and abutting sub-intervals.
* @param inputArray The array to be merged
*/
private static int[] mergeIntervals ( int[] inputArray ) {
int numMerge = 0;
// count merged sub-intervals
for ( int i = 0, iCurrent = -1, iNext = -1; i < inputArray.length; i += 2 )
{
int current = inputArray [ i + 0 ];
int next = inputArray [ i + 1 ];
if ( ( iNext < 0 ) || ( current > iNext ) ) {
iCurrent = current;
iNext = next;
numMerge++;
} else if ( current >= iCurrent ) {
if ( next > iNext ) {
iNext = next;
}
}
}
int[] returnArray = new int [ numMerge * 2 ];
// populate merged sub-intervals
for ( int i = 0, numMerge2 = 0, iCurrent = -1, iNext = -1; i <
inputArray.length; i += 2 ) {
int current = inputArray [ i + 0 ];
int next = inputArray [ i + 1 ];
int numMerge2Square = numMerge2 * 2;
if ( ( iNext < 0 ) || ( current > iNext ) ) {
iCurrent = current;
iNext = next;
returnArray [ numMerge2Square + 0 ] = iCurrent;
returnArray [ numMerge2Square + 1 ] = iNext;
numMerge2++;
} else if ( current >= iCurrent ) {
if ( next > iNext ) {
iNext = next;
}
returnArray [ numMerge2Square - 1 ] = iNext;
}
}
return returnArray;
}
Many variables are now limited in scope to the loops. Only numMerge
and returnArray are visible outside the loop. The names make it
somewhat clearer what the code does (if I guessed the names right).
BTW Is there a requirement that the length of the input array is even?
If not, inputArray [ i + 1 ] will raise an exception if i == n-1.
So, yes, I agree with your objections against the actual format of the
code.
Simon
Re: Merge Request - Temp_ComplexScripts into Trunk
Jonathan, Obviously, FOP's strongest supporters over the past years do not require this new functionality. FOP needs the additional support of new stakeholders of this new functionality. Could your teams test it on their documents and report their findings to the fop-user email list? Simon Pepping On Wed, Oct 19, 2011 at 03:20:40PM -0400, Jonathan Levinson wrote: > We -- at InterSystems -- deploy an application that runs in upwards of 40 > countries, using many of the languages for which complex script support is > required. > > We definitely need complex script support. It is a requirement for us.
Re: Merge Request - Temp_ComplexScripts into Trunk
Over the past ten years computing has pervaded life in all its facets, and spread over the world. As a consequence computing is now used in all languages and all scripts. When I open my devanagari test file in emacs, it just works. When I open it in firefox, it just works. The same when I open it in LibreOffice Writer. I am sure that, if I would open it in *the* *Word* processor, it would just work. When I process the file with FOP, it does not work. With the complex scripts functionality, it works, dependent on the use of supported or otherwise suitable fonts. (That is true for all above applications, but apparently those come configured with my system.) So what does a person do who believes in the XML stack to maintain his documentation, and wants to send his documents in Hindi to his customers? See that XSL-FO with FOP is not a suitable solution for him because Hindi uses a complex script? FOP needs the complex scripts functionality to remain a player in the global playing field. This is for me the single overarching consideration to want this functionality in FOP's trunk code, and in, say, half a year in a release. All other considerations are minor, unless one wants to claim that this code will block FOP's further development and maintenance in the coming years. Of course, not everybody needs this functionality, and there is a fear of increased maintenance overhead. But the question is: For whom do we develop FOP? Also for the large part of the world that uses complex scripts? With the development of the complex scripts functionality, Glenn Adams and his sponsor Basis Technologies have created a new reality, which is not going to go away. If this functionality does not end up in FOP, it will probably live on elsewhere. If the FOP team is fine with that, say no to the merge request, and feel comfortable with a trusted niche application. Simon Pepping On Wed, Oct 19, 2011 at 09:50:24AM +0100, Chris Bowditch wrote: > On 18/10/2011 19:55, Simon Pepping wrote: > >I merged the ComplexScripts branch into trunk. Result: > > Hi Simon, > > As well of the question of how to do the merge there is also the > question should we do the merge? Of course this is a valuable > feature to the community, and Glenn has invested a lot of time in > its development but is it truely production ready? I asked Vincent > to take a look at the branch earlier in the year as it's a feature > we also need, but he had several concerns that have not be > adequately answered. Take a look at comment #30; > https://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c30 > > I'm not sure why Vincent describes it as a "brief look" because he > spent several days on it. I also asked Peter to take a look and he > had similar concerns. 2 or 3 letter variable names are a barrier for > any committer wanting to maintain this code and I don't think it is > a sufficient argument to say that a pre-requisite to maintaining > this code is to be a domain expert. I would hope that any > experienced committer with a debugger should be able to solve some > bugs. Obviously certain problems will require domain expertise, but > the variables names are a key barrier to being able to maintain this > code. > > I realise my comments might be a little controversial and I don't > mean any disrespect to Glenn or his work (which is largely > excellent), but we should at least discuss these topics before the > merge is completed.
Re: Merge Request - Temp_ComplexScripts into Trunk
I merged the ComplexScripts branch into trunk. Result: --- Merging r981451 through r1185769 into '.': Summary of conflicts: Text conflicts: 58 Tree conflicts: 126 Most tree conflicts are probably an artifact of subversion. See >svn info lib/xmlgraphics-commons-1.5svn.jar|tail -n 4 Tree conflict: local add, incoming add upon merge Source left: (file) https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.5svn.jar@981450 Source right: (file) https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ComplexScripts/lib/xmlgraphics-commons-1.5svn.jar@1185769 This will cause quite some work. I also merged trunk into ComplexScripts. Result: --- Merging r1177231 through r1185780 into '.': Summary of conflicts: Text conflicts: 2 Tree conflicts: 2 I resolved the text conflicts easily. Again the tree conflicts were not real conflicts. Both merges should result in the same code: trunk + ComplexScripts. I did not commit the merge of trunk into ComplexScripts to the repository. I do not think it would facilitate merging ComplexScripts into trunk. Simon On Sat, Oct 15, 2011 at 06:17:49PM +0800, Glenn Adams wrote: > With this latest patch, I am satisfied that there is sufficient testing and > stability in the CS branch to support its merger into trunk. Therefore, I > request that such a merge be accomplished after applying patch 5 to the CS > branch as described below.
Re: [VOTE] to include the Mockito framework
I understand that Mockito facilitates true unit testing of specific pieces of code. That is a good facility to have. +1 Simon On Thu, Oct 13, 2011 at 04:38:46PM +0100, Peter Hancock wrote: > I would like to launch a vote to include the Mockito framework and her > dependencies in to FOP for unit testing. > > Some reasons for introducing a framework for mocking and stubbing, and > Mockito in particular, have briefly been expressed [1] and patches > have been provided [2] ... [4] that depend upon Mockito. > > Unit testing in FOP often proves difficult because it can be very hard > to factor out dependencies: to run a piece of FOP code often requires > substantial configuration. > Mockito can go a long way in helping us here, and may even encourage > us to write more unit tests! > > [1] http://markmail.org/message/zobrtzanojpkfysa > [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50483 > [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=50391 > [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=46962 > > +1 here. > > Peter
ICLA of Mehdi Houshmand is on file
Mehdi Houshmand's ICLA is now on file with the ASF. I take this opportunity to remind you that all code in our and other ASF repositories must have been donated to the ASF under a Contributor's License Agreement. This allows the ASF to claim that the code was 'Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements' (see the header on our source files). For contributions of a more than trivial size and content the contributor must have filed an ICLA with the ASF. You can find the list of non-committers who filed an ICLA at the web page http://people.apache.org/committer-index.html#unlistedclas. Committers who commit a patch from a non-committer contributor should check this. In addition, the contribution must have been clearly donated to the ASF, e.g. by attaching it to a bug report in Bugzilla. Therefore, pulling code from a Git repository creates an unclear situation and is not (yet) an allowed method to obtain a contribution to the ASF. Best, Simon
Re: svn commit: r1177251 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/BasicLink.java layoutmgr/inline/InlineLayoutManager.java pdf/PDFFactory.java
On Thu, Sep 29, 2011 at 10:18:54AM -, phanc...@apache.org wrote: > Author: phancock > Date: Thu Sep 29 10:18:53 2011 > New Revision: 1177251 > > URL: http://svn.apache.org/viewvc?rev=1177251&view=rev > Log: > Fix FO tree hierarchy: BasicLink shouldn't inherit from Inline Why? A basic-link is an inline object which generates inline areas. Simon
Re: svn commit: r1177228 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: afp/fonts/CharactersetEncoder.java afp/ptoca/PtocaBuilder.java fonts/MultiByteFont.java render/java2d/InstalledFontCollect
Please, use our source code quality control tools. Simon On Thu, Sep 29, 2011 at 08:58:13AM -, spepp...@apache.org wrote: > Author: spepping > Date: Thu Sep 29 08:58:12 2011 > New Revision: 1177228 > > URL: http://svn.apache.org/viewvc?rev=1177228&view=rev > Log: > Various small fixes > > Modified: > > xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts/CharactersetEncoder.java > xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/ptoca/PtocaBuilder.java > xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/MultiByteFont.java > > xmlgraphics/fop/trunk/src/java/org/apache/fop/render/java2d/InstalledFontCollection.java > > xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSImageHandlerGraphics2D.java
Re: Revision 1175754 introduces a findbugs error
I will fix it. It is a good habit to run findbugs. This error means that CIDFont.getDefaultWidth() is not overwritten in MultiByteFont, and that therefore MultiByteFont.getDefaultWidth() returns the wrong value. Can there be a test that reveals such an error? Simon On Wed, Sep 28, 2011 at 08:53:26PM +0100, mehdi houshmand wrote: > Hi, > > This is my fault, I think this was a merge conflict here, it should be > MultiByteFont.getDefaultWidth(). > > My apologies. > > Mehdi > > On 28 September 2011 20:38, Simon Pepping wrote: > > Revision 1175754 introduces a significant findbugs error: > > > > VERY confusing to have methods > > org.apache.fop.fonts.MultiByteFont.getdefaultwidth() and > > org.apache.fop.fonts.CIDFont.getDefaultWidth() > > > > Simon > >
Revision 1175754 introduces a findbugs error
Revision 1175754 introduces a significant findbugs error: VERY confusing to have methods org.apache.fop.fonts.MultiByteFont.getdefaultwidth() and org.apache.fop.fonts.CIDFont.getDefaultWidth() Simon
Re: buildbot failure in ASF Buildbot on fop-trunk
I filed an issue for infrastructure at https://issues.apache.org/jira/browse/INFRA-3969. Simon On Mon, Sep 26, 2011 at 08:00:08AM +, build...@apache.org wrote: > The Buildbot has detected a new failure on builder fop-trunk while building > ASF Buildbot. > Full details are available at: > http://ci.apache.org/builders/fop-trunk/builds/380 > > Buildbot URL: http://ci.apache.org/ > > Buildslave for this Build: ceres_ubuntu > > Build Reason: The Nightly scheduler named 'fopNightly' triggered this build > Build Source Stamp: [branch None] HEAD > Blamelist: > > BUILD FAILED: failed svn > > sincerely, > -The Buildbot > > >
Re: Fop's build process
Upgrading the test setup to JUnit4 is fine with me. The current options to run single tests and to disable tests are useful; a new test setup should keep those options. Otherwise any simplification and improvement of the test system is fine with me. Simon On Fri, Sep 23, 2011 at 04:16:03PM +0800, Glenn Adams wrote: > i would suggest you simply create a new target that invokes tests in the > fashion you propose; however, i would not want to replace the current > targets with this new target, or at least not do so without considerable > usage having passed; > > i personally like having different targets, particularly when creating new > tests or debugging regressions in tests, since that allows me to effectively > subset the tests from command line based on which targets i select; > > On Fri, Sep 23, 2011 at 3:57 PM, mehdi houshmand wrote: > > > Hi Guys, > > > > Since there's been overwhelming support for this, I'll throw another > > thought out there for people to consider. While looking at these > > tests, it seems logical to me to change the way FOP invokes the JUnit > > tests, so that rather than invoking test-suites, the build.xml, > > invokes ALL classes that match the regex "*TestCase.java". > > > > The benefit of this would be that if someone forgets to add a unit > > test to a test suite, the test is still invoked, but more importantly, > > it would greatly simplify the build.xml. This would also mean that the > > layout/area tree/IF test-suites will have to change to take advantage > > of the JUnit4 parametrised test system. But that's not difficult to > > do, and quite frankly I don't like that they depend on so many obscure > > system parameters, I appreciate that that's the only way to > > parametrise tests in JUnit3, but this gives us an opportunity to > > improve it. This also has the added benefit that people can run these > > tests in their IDE without having to inject system parameters.
Re: Maintaining the list of contributors
On Wed, Sep 14, 2011 at 02:13:16PM +0200, Jeremias Maerki wrote: > You're right. I think there's a lot of inconsistency here. So, why not > keep it VERY simple? > > 1. Wipe the team page clean. > 2. Add a paragraph with a alphabetically sorted, comma-separated list of > names of contributors (without mail addresses, includes committers). The > listing would be regardless of the amount of work on FOP. If need be, > the committers in bold. > 3. Add a link to > http://people.apache.org/committers-by-project.html#xmlgraphics-fop > (which, unfortunately, doesn't contain the list of committers before the > move from CVS to SVN). This list only contains the current committers, not past ones. I prefer the list of inactive committers to stay. Committers are not just a special type of contributors; they manage FOP's source code repository. > 4. Possibly restore the note about FOP's founder. > > No more active or inactive contributors/committers (is he still active? > is he not?...). Every committer makes sure that the names of Committers are made inactive according to the rules in the project charter. The PMC Chair applies those rules. I did that during the past year. > contributors make it to the contributor list. We know who the candidates > for committership are from our daily work. I think that would increase > fairness and maintainability of the team list. And it allows to remove > all author tags and comments in a fair way. If any committer thinks that > the amount of recognition for the project is important, we can always > add a link to the Ohloh page of FOP which does a much better job at > telling who contributed how much and when. > > That an idea? I like the list of contributors, because subversion and bugzilla do not easily reveal that information. Simon
Re: compliance documentation : support of 'format' property
On Wed, Aug 24, 2011 at 09:04:08PM -0600, Glenn Adams wrote: > The 'format' property is only partially supported, where it is limited to > the following values: > > format : 0*1|a|A|i|I > > Perhaps someone could update > http://xmlgraphics.apache.org/fop/compliance.html#fo-property-numberstring-sectionto > change from yes to partial, with the following comment: > > Only '0*1', 'a', 'A', 'i', 'I' values supported. Done. Simon
Re: Publishing the web site
When publishing the commons web site I noticed that the failure of subversion checkout and checkin is due to the broken links in the build process. So we need to find a way to fix those. Simon On Tue, Aug 23, 2011 at 04:13:50PM +0200, Simon Pepping wrote: > I find publishing the web site a pain. Forrest has two broken links: > > [java] X [0] favicon.ico BROKEN: No > pipeline matched request: favicon.ico > [java]at - > file:/fsd/source/apache-forrest-0.8/main/webapp/./sitemap.xmap:606:76 > > [java] X [0] compliance.pdf BROKEN: > internal-destination or external-destination must be specified in basic-link > > and ends in an error: > > [java] Java Result: 1 > [echo] > [echo] Copying broken links file to site root. > [echo] > [copy] Copying 1 file to /fsd/source/xml-fop/build/forrest-docs > [echo] Oops, something broke > [copy] Copying 1 file to /fsd/source/xml-fop/build/forrest/log > > There is no subversion checkout, no addition and removal of files, and > no subversion checkin. I do have my account name in > ../deploy.svn.settings as value="spepping"/>. > > How can I fix these various problems? > > Simon
Publishing the web site
I find publishing the web site a pain. Forrest has two broken links: [java] X [0] favicon.icoBROKEN: No pipeline matched request: favicon.ico [java] at - file:/fsd/source/apache-forrest-0.8/main/webapp/./sitemap.xmap:606:76 [java] X [0] compliance.pdf BROKEN: internal-destination or external-destination must be specified in basic-link and ends in an error: [java] Java Result: 1 [echo] [echo] Copying broken links file to site root. [echo] [copy] Copying 1 file to /fsd/source/xml-fop/build/forrest-docs [echo] Oops, something broke [copy] Copying 1 file to /fsd/source/xml-fop/build/forrest/log There is no subversion checkout, no addition and removal of files, and no subversion checkin. I do have my account name in ../deploy.svn.settings as . How can I fix these various problems? Simon
Update junit on Gump [was: Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]
You can raise an issue in JIRA for project GUMP: https://issues.apache.org/jira/browse/GUMP. Simon On Tue, Aug 16, 2011 at 11:40:33AM +0100, Vincent Hennebert wrote: > > Now I’m not too sure how to get JUnit upgraded. Should I send a mail to > general at gump.apache.org, or builds at apache.org, or raise an issue? > Apparently the former, but this list seems to be the project’s dev list. > > Thanks, > Vincent
Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed
On Wed, Aug 10, 2011 at 02:33:05PM +0100, Vincent Hennebert wrote:
> On 10/08/11 12:56, Jeremias Maerki wrote:
> > junit-compile-java:
> > [mkdir] Created dir:
> > /srv/gump/public/workspace/xml-fop/build/test-classes
> > [mkdir] Created dir:
> > /srv/gump/public/workspace/xml-fop/build/test-gensrc
> > [mkdir] Created dir:
> > /srv/gump/public/workspace/xml-fop/build/test-reports
> > [javac] Compiling 169 source files to
> > /srv/gump/public/workspace/xml-fop/build/test-classes
> > [javac]
> > /srv/gump/public/workspace/xml-fop/test/java/org/apache/fop/pdf/FileIDGeneratorTestCase.java:39:
> > cannot find symbol
> > [javac] symbol : constructor
> > TestSuite(java.lang.Class[],java.lang.String)
> > [javac] location: class junit.framework.TestSuite
> > [javac] TestSuite suite = new TestSuite(new Class[] {
> > [javac] ^
>
> Does anyone understand what is going on here? I can’t imagine that the
> JUnit version running on Gump is too old, this constructor has been
> existing since at least 2006.
I do, after a long search. Gump uses
/srv/gump/packages/junit3.8.1/junit.jar, see
http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/gump_work/build_xml-fop_xml-fop-test.html.
In that version the constructor does not exist, see
http://www.junit.org/junit/javadoc/3.8.1/junit/framework/TestSuite.html.
This is the first and only time that FOP code uses this constructor.
So, yes, you need to extend your imagination. Time for Gump to upgrade
to version 3.8.2.
Simon
Stop this infighting [was: Re: svn commit: r1151195 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFSubSetFile.java status.xml]
Stop this infighting, please. We all have our strong and weak points. Stop attacking each other on real or perceived weak points. Cooperate with each other and complement each other in a positive atmosphere. Simon On Thu, Jul 28, 2011 at 12:59:52PM +0100, Vincent Hennebert wrote: > On 27/07/11 13:39, Jeremias Maerki wrote: > > On 27.07.2011 12:09:58 Vincent Hennebert wrote: > >> There is basic housekeeping that ought to be done IMO: > >> > >> On 26/07/11 19:28, jeremias wrote: > >>> Author: jeremias > >>> Date: Tue Jul 26 18:28:07 2011 > >>> New Revision: 1151195 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=1151195&view=rev > >>> Log: > >>> Fixed a bug in TTF subsetting where a composite glyph could get remapped > >>> more than once resulting in garbled character. > >>> > >>> Modified: > >>> > >>> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFSubSetFile.java > >>> xmlgraphics/fop/trunk/status.xml > >>>
Re: should complex script features be enabled or disabled by default?
At the moment probably most users do not use complex scripts in FOP. But by giving FOP complex scripts functionality, we hope to expand the user base and their FOP usage, so that in the future maybe most users will use complex scripts in FOP. I am in favour of enabling complex scripts by default. Simon On Tue, Jul 19, 2011 at 07:50:58AM -0400, Eric Douglas wrote: > Good call. You'll get more questions enabling it by default if most people > don't need it and it has a significant performance impact. > "Why is this new version so much slower?" > To my users, applications not crashing is the number one priority. > Performance is number two. > > > -Original Message- > From: Pascal Sancho [mailto:pascal.san...@takoma.fr] > Sent: Tuesday, July 19, 2011 4:08 AM > To: fop-dev@xmlgraphics.apache.org > Subject: Re: should complex script features be enabled or disabled by default? > > Hi Glenn, > > IMHO, the default setting should depend on how much it affects the > performances. > Can you give an approximative impact? > > > Le 19/07/2011 03:40, Glenn Adams a écrit : > > I'm adding a feature to allow enable/disable of complex script > > features (bidi, complex char to glyph mapping) at runtime, using > > either (or both) command line option and config file element; the > > question I have is whether to enable or disable by default? > > > > If enabled by default, those who don't use complex scripts or don't > > want advanced typography features in non-complex scripts will incur a > > minor performance penalty. > > > > If disabled by default, then those users who use complex scripts or > > want advanced typography features in non-complex scripts will need to > > do something special to enable this support. > > > > What does the group think? I don't have a strong preference either way. > > > > G. > > > > -- > Pascal
Re: Testing Complex Scripts
I do not have Windows7, but I found those fonts, and they work fine. OpenType seems to be very much a Microsoft game. Linux vendors seem not to move along with MS. Do other font vendors? Simon On Wed, Jun 22, 2011 at 01:25:04PM -0600, Glenn Adams wrote: > Microsoft changed the Indic script processing logic around 2008, and newer > fonts provide both old 'deva' (now deprecated) and new 'dev2' tables. > Apparently the older font you accessed does not. I have not tested against > older fonts that do not support the new 'dev2' semantics. > > I have listed the fonts that I have verified to work at > http://skynav.trac.cvsdude.com/fop/wiki/SupportedFonts. At present, the > script detection logic is returning 'dev2' when Devanagari is detected. You > can override this by using script='deva'; however, I have not explicitly > tested the Devanagari code against the older logic yet. > > Compare [1] (May 2008) versus [2] (March 2002) for further reference. >
Indic Script processing
Glenn, I studied the OpenType spec. With that knowledge I assumed, perhaps naively, that for all OT fonts a correct rendering can be obtained by following the directives in the tables in the font. The code of the ComplexScripts branch provides specific processing of each Indic font (until now Devanagari). The main action seems to be that each word is first syllabized and then each syllable is separately submitted to the substitution code. Do I understand correctly that the font tables alone do not allow one to achieve a correct rendering, and that it is necessary to understand the syllabic structure of the text? Simon
Testing Complex Scripts
I tested the latest code in the branch ComplexScripts with a font called Lohit-Devanagari, version 2.4.5, copyright Red Hat, license GPLv2, file lohit_hi.ttf, Debian package ttf-devanagari-fonts. Fontforge shows that the font has 2 GPOS tables and a large number of GSUB tables. I was not successful. The result showed for the first word first the vocal R, before the left margin, then within the margin Pa, then Virama, then Tha, Va, II. I tried to get more info. These are some observations: MultiByteFont.performPositioning returns null, because GlyphPositioningTable.position returns false, because GlyphPositioningTable has no matching lookups; and are defined, is requested. MultiByteFont.performSubstitution returns the unmodified CharSequence because GlyphSubstitutionTable has no matching lookups; and are defined, where XXX takes on many values, e.g. abvs, akhn, blwf, blws, half, etc.; is requested. GlyphDefinitionTable.reorderCombiningMarks reorders the glyphlist from [90, 115, 85, 125, 101, 112] to [115, 90, 125, 85, 101, 112] (glyphs 2 and 4 are typed as combining marks). In MultiByteFont.reorderCombiningMarks this leads to a reordered CharSequence, from [92A, 943, 925, 94D, 935, 940] to [943, 92A, 94D, 925, 935, 940]. The result in the pdf file as described above reflects this reordering. Eclipse renders the original CharSequence as पृथ्वी, which is the expected outcome, and the reordered one as ृप्थवी, which is not expected. So the reordering seems counterproductive. I hope this is useful. Simon
Re: DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support
On Fri, Jun 10, 2011 at 08:44:11PM +, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 > > --- Comment #33 from Glenn Adams 2011-06-10 20:44:11 UTC > --- > I believe this is a side-effect of Simon's incremental merges from trunk into > the Temp_ComplexScripts branch. I'm doing my work in my dev repo at > git://github.com/skynavga/fop.git, from which I irregularly post a new patch > for merger into Temp_ComplexScripts. I've got a couple of bugs I'm working on, > after which I expect to submit a new patch before the end of June. I see I made this error when resolving a remaining tree conflict in the merge. When I removed ViewPort, I failed to check the compilation again. Simon
Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed
On Tue, Jun 07, 2011 at 10:05:24PM +0200, Andreas L. Delmelle wrote:
> On 07 Jun 2011, at 17:43, Vincent Hennebert wrote:
>
> > I’m a bit at a loss to understand why Gump has suddenly started to throw
> > this error. The tests run fine on my local copy, both with a Sun and an
> > OpenJDK jvm. Could that be that the version of the Xerces library used
> > by Gump is not up-to-date? But then, why would that have worked before?
> > Any ideas?
>
> Puzzles me as well. At first, I suspected the problem might just be that Gump
> uses a more up-to-date Xerces than the one distributed with FOP. We still
> have 2.7.1 in the lib directory, while the latest available release is 2.11.
> Then again, that version was released over 6 months ago...?
>
> >[junit] java.lang.reflect.InvocationTargetException
> >[junit] Caused by: java.lang.ExceptionInInitializerError
> >[junit] at
> > org.apache.fop.intermediate.AbstractIFTestCase.(AbstractIFTestCase.java:80)
> >[junit] at
> > org.apache.fop.intermediate.IntermediateFormatTestSuite.suite(IntermediateFormatTestSuite.java:63)
> >[junit] Caused by: org.xml.sax.SAXParseException: InvalidRegex: Pattern
> > value '\((solid|dotted|dashed|double|groove|ridge|inset|outset),.+)' is not
> > a valid regular expression. The reported error was: 'Wrong character.'.
>
>
> Could this point to a quirk in util.regex, or its use in the XML Schema
> implementation in the version of Open JDK that Gump is compiling with?
> At any rate, the starting '\(' does indeed seem to be an invalid escape
> sequence (Shouldn't it be '\\(' if it needs to match a literal bracket?)
> It is present as-is, on our end in
> src/documentation/intermediate-format-ng/fop-intermediate-format-ng-datatypes.xsd.
> I am not an XML Schema expert, but that pattern does seem to be odd. Not
> sure why the leading backslash is needed...
>
> That file hasn't changed in over 2 years, though. :-/
'\(' in the pattern is valid and indicates a literal '('. The pattern
as a whole is invalid, but in lax validation the final ')' is ignored.
The value in the test is '(solid,#00,5000)', and the valid pattern
for it is '\(...\)'. In lax validation the final ')' is subsumed in
the pattern '.+'.
I believe that gump uses current builds of Xerces, and it seems that
the validation in Xerces has been made stricter.
I committed a fix.
Simon
Re: svn commit: r1088973 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFLogicalStructureHandler.java
I would rather have a more collaborative tone than your gratefulness. Simon On Tue, Apr 05, 2011 at 12:14:41PM +0100, Vincent Hennebert wrote: > Along with the other ones, that makes a lot of mistakes in just a few > commits. I’d be grateful if you could double-check your changes before > committing. > > Thanks, > Vincent
Move to inactive FOP committer status
Dear former FOP committer, On the FOP web pages you are listed as an active committer to FOP. Since you have not been active for more than 3 months, we will proceed to move you to the list of inactive committers. See the project charter, http://wiki.apache.org/xmlgraphics/ProjectCharter, section 8.5. Please, react within 72 hours if you feel that this move is incorrect. We thank you for your contributions to FOP. Should you wish to become active again, then you are welcome to do that at any time. Regards, On behalf of the XML Graphics PMC, Simon Pepping, PMC chairman
Re: FindBugs exclusion policy proposal
As before, I will generally not fix findbugs errors or warnings in contributions by other people. I will fix findbugs errors or warnings in code that I write, or code changes that I make. Note that the use of the findbugs code analysis tool is not a policy of the FOP project, and that consequently FOP committers are not bound to use findbugs and fix its errors or warnings. Simon On Thu, Feb 24, 2011 at 04:57:57PM -0800, Glenn Adams wrote: > I think the existing exclusions should be left in trunk, and that no new > ones should be permitted in (or should be fixed immediately). If you do as > you suggest below, then the list of findbugs errors will just continue to > grow because nobody will pay attention to them. > > We are at a known, stable point, we do have some exclusions that we know > need fixing, and we can do that as time permits; but let's keep it that way > and not backpedal by allowing in new ones. > > G. > > On Thu, Feb 24, 2011 at 8:40 AM, Andreas Delmelle < > andreas.delme...@telenet.be> wrote: > > > > > 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' > > exclusions just to make the warnings go away. Following the same reasoning, > > we could define thousands of CheckStyle suppressions, instead of encouraging > > people to do it correctly. > > > > I do not have a problem with looking into those issues, if no one else has > > the time and/or motivation, although that will not always happen > > _immediately_. > > > > The general idea is good, but I am wondering, given the circumstances, if > > we had not better invert the approach: keep the warnings alive in trunk, and > > add exclusions for them only in the branch. > > That way, devs who are not involved in the branch but do use FB, will be > > constantly reminded that those issues should be looked into. For the > > maintainer(s) of the branch, if the exclusion is properly commented, it can > > serve as an indication that the warning originated in trunk and has nothing > > to do with their changes. Should a genuine bug result from it, and it turns > > out to hamper the development on the branch, it can then be raised as a > > priority issue on this list. > > > > Ultimately, it is still a worthwhile goal to eliminate all of the warnings, > > but we also have to be realistic enough to admit that that will not happen > > overnight. > > > > > > WDYT? > > > > Regards, > > > > Andreas > > --- > > > >
Re: junit tests in nightly builds
On Wed, Feb 23, 2011 at 01:10:10PM -0700, Glenn Adams wrote: > Right now the nightly build is our CI process. That is a development-centric point of view. The nightly build is definitely not a CI process. It is a service to the users, which must not be interrupted by development concerns. If a reliable application can be built, it must be built and delivered. Simon
Re: junit tests in nightly builds
On Wed, Feb 23, 2011 at 01:15:34AM -0700, Glenn Adams wrote: > OK, understand on the junit headless issue. For checkstyle/findbugs it would > be useful to fail the nightly build if they do not pass. I will investigate > the necessary changes to enable this option, which I hope can be adopted. I would not agree. Nightly builds are a courtesy to the user. It would be good if we could guarantee that the builds pass the junit tests. But it is not relevant to the user whether they pass checkstyle and findbugs rules. These tests address the issue of code quality, not of application quality. Simon > On Wed, Feb 23, 2011 at 12:55 AM, Simon Pepping wrote: > > > On Tue, Feb 22, 2011 at 11:25:20AM -0700, Glenn Adams wrote: > > > I notice also that the nightly build target does not run all the junit > > > tests. It would be better if it run all of them plus checkstyle and > > > findbugs. > > > > Many junit tests require a display. Nightly builds are run in a > > headless configuration, hence I had to disable many junit tests. At > > nightly builds there is no one to check checkstyle and findbugs errors > > and warnings; therefore there is no point in running them. > > > > Simon > >
junit tests in nightly builds [was: Re: Solving FindBugs issue]
On Tue, Feb 22, 2011 at 11:25:20AM -0700, Glenn Adams wrote: > I notice also that the nightly build target does not run all the junit > tests. It would be better if it run all of them plus checkstyle and > findbugs. Many junit tests require a display. Nightly builds are run in a headless configuration, hence I had to disable many junit tests. At nightly builds there is no one to check checkstyle and findbugs errors and warnings; therefore there is no point in running them. Simon
Re: Solving FindBugs issues
On Tue, Feb 22, 2011 at 07:15:17PM +, Vincent Hennebert wrote: > On 22/02/11 07:24, Simon Pepping wrote: > > Not all FOP developers are willing to use findbugs. I hid the findbugs > > errors as a courtesy to those FOP developers who do use findbugs, so > > they can check their own code based on a clean slate. > > I agree that ignoring all the existing issues at the time FindBugs was > set up was necessary, but now that FindBugs is in place I don’t think we > want to blindly ignore its output any more. Again, some of the issues > raised after the recent commits seem valid and ought to be fixed. > > Can we revert commit 1071912 and re-consider the issues one-by-one > before ignoring them? Yes, you can. My position is as follows: I do merging of trunk into complexscripts as a service to the Complex Scripts project. I see existing findbugs errors and warnings. I do not have time nor interest to fix those. So I hide them so that others can run findbugs on their code from a clean slate. I add a new, appropriately labeled section to the findbugs exclusion file so that you and others can do as you suggest. I will do this again and again, no matter how many emails are written about the subject. And I would prefer it if no emails about it were written. They bother me and they discourage me to continue doing any services for FOP. It is much more encouraging to see that some of us pick up the findbugs error report and use it to make code improvements. Simon > > FOP's history has left us with a very large number of existing > > findbugs errors. It makes no sense to comment on that; it is a fact of > > life. FOP's code first of all does a good job at being a successful, > > heavily used FO processor. Only after that comes the question of a > > clean code base. > > > > That said, of course every FOP developer and every FOP user is welcome > > to evaluate and possibly remedy one or more findbugs errors. For > > precisely that reason I put comments in the exclusion file, so one can > > see which errors have been simply hidden and which have been truely > > evaluated. > > > > Simon > > Thanks, > Vincent > > > > On Mon, Feb 21, 2011 at 06:15:13PM +, Vincent Hennebert wrote: > >> Hi, > >> > >> 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. > >> > >> Vincent > >> > >> > >> On 18/02/11 08:18, spepp...@apache.org wrote: > >>> Author: spepping > >>> Date: Fri Feb 18 08:18:04 2011 > >>> New Revision: 1071912 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=1071912&view=rev > >>> Log: > >>> Fixing checkstyle errors and hiding fingbugs errors > >>> > >>> Modified: > >>> xmlgraphics/fop/trunk/findbugs-exclude.xml > >>> > >>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java > >>> > >>> Modified: xmlgraphics/fop/trunk/findbugs-exclude.xml > >>> URL: > >>> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/findbugs-exclude.xml?rev=1071912&r1=1071911&r2=1071912&view=diff
Re: Assertions in junit tests [was: Re: Solving FindBugs issue]
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 > chosen here, but adding an assert statement in the code avoids the warning as > well *and* has the benefit of being visible exactly at the spot in the code > where it applies. Seemed like the more proper way to handle this. 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? Simon
Re: Solving FindBugs issue
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 errors where a clean ant build does not. It makes findbugs seem fickle. I just tested it. With 'ant clean findbugs' I get 0 errors and warnings. With eclipse clean and build project, I get 23 low priority warnings. Simon On Mon, Feb 21, 2011 at 12:58:06PM -0700, Glenn Adams wrote: > The current trunk shows no warnings during ANT compile. Please make > reference to the current trunk/HEAD as 1.0 is published and history at this > time. > > It's a different matter with certain IDEs, e.g., Eclipse, which set their > warning levels to a more sensitive level than the ANT build. > > Although it would be nice to eliminate such additional warnings, it is not > as high priority IMO as ensuring that new compile, checkstyle, or findbugs > warnings/errors do not appear during ANT builds. At the same time, warnings > that do appear should not automatically be excluded without careful, manual > review. > > G. > > On Mon, Feb 21, 2011 at 12:49 PM, 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. > > 1.5 shows thousands of warnings, 1.6 shows more. > > Some of the warnings are quirky (raw type list?), some are just wasteful > > (dead code? Local variable never referenced?). > > If there's code which is actually incorrect logic it needs to be fixed. > > If there's code which is just incomplete logic, maybe setting something > > up for a future improvement someone wanted to add, that should be > > removed and placed in a separate to do list document.
Re: Solving FindBugs issues
Not all FOP developers are willing to use findbugs. I hid the findbugs errors as a courtesy to those FOP developers who do use findbugs, so they can check their own code based on a clean slate. FOP's history has left us with a very large number of existing findbugs errors. It makes no sense to comment on that; it is a fact of life. FOP's code first of all does a good job at being a successful, heavily used FO processor. Only after that comes the question of a clean code base. That said, of course every FOP developer and every FOP user is welcome to evaluate and possibly remedy one or more findbugs errors. For precisely that reason I put comments in the exclusion file, so one can see which errors have been simply hidden and which have been truely evaluated. Simon On Mon, Feb 21, 2011 at 06:15:13PM +, Vincent Hennebert wrote: > Hi, > > 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. > > Vincent > > > On 18/02/11 08:18, spepp...@apache.org wrote: > > Author: spepping > > Date: Fri Feb 18 08:18:04 2011 > > New Revision: 1071912 > > > > URL: http://svn.apache.org/viewvc?rev=1071912&view=rev > > Log: > > Fixing checkstyle errors and hiding fingbugs errors > > > > Modified: > > xmlgraphics/fop/trunk/findbugs-exclude.xml > > > > xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java > > > > Modified: xmlgraphics/fop/trunk/findbugs-exclude.xml > > URL: > > http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/findbugs-exclude.xml?rev=1071912&r1=1071911&r2=1071912&view=diff
Re: svn commit: r1071282 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AlignmentContext.java
Vincent and Andreas,
Thanks. I did not realize that Andreas' commit reverted an earlier
change by Vincent.
Simon
On Fri, Feb 18, 2011 at 07:23:41PM +0100, Andreas Delmelle wrote:
> 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 did in rev. 1035610. That’s what made me think
> > that it really was an accidental change and that there would be no
> > problem with me fixing it.
>
> Sorry, my bad. I noticed the change too, but did not look closely enough...
> I agree that the abbreviated identifiers are way too cryptic, and using the
> full name is much better.
>
> The reason I left it in, was that it was also a correction:
> buf.append("...").append(str) is generally considered better practice than
> buf.append("..." + str).
Re: svn commit: r1071282 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AlignmentContext.java
Vincent,
Please, do not revert other committers' changes. Discuss them if you
have objections.
Simon
On Wed, Feb 16, 2011 at 03:19:29PM -, vhenneb...@apache.org wrote:
> Author: vhennebert
> Date: Wed Feb 16 15:19:29 2011
> New Revision: 1071282
>
> URL: http://svn.apache.org/viewvc?rev=1071282&view=rev
> Log:
> Reverted changes accidentally made to toString in rev. 1071048
>
> Modified:
>
> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AlignmentContext.java
>
> Modified:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AlignmentContext.java
> URL:
> http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AlignmentContext.java?rev=1071282&r1=1071281&r2=1071282&view=diff
> ==
> ---
> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AlignmentContext.java
> (original)
> +++
> xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AlignmentContext.java
> Wed Feb 16 15:19:29 2011
> @@ -507,11 +507,11 @@ public class AlignmentContext implements
> /** {@inheritDoc} */
> public String toString() {
> StringBuffer sb = new StringBuffer(64);
> -sb.append("ah=").append(areaHeight);
> -sb.append(" lp=").append(lineHeight);
> -sb.append(" ap=").append(alignmentPoint);
> -sb.append(" ab=").append(alignmentBaselineIdentifier);
> -sb.append(" bs=").append(baselineShiftValue);
> +sb.append("areaHeight=" + areaHeight);
> +sb.append(" lineHeight=" + lineHeight);
> +sb.append(" alignmentPoint=" + alignmentPoint);
> +sb.append(" alignmentBaselineID=" + alignmentBaselineIdentifier);
> +sb.append(" baselineShift=" + baselineShiftValue);
> return sb.toString();
> }
Re: svn commit: r1067533 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/BlockStackingLayoutManager.java
I am pleased that you undertake this kind of cleanup work in the
layout engine. It is very useful that you try to make this piece of
code more accessible.
Simon
On Sun, Feb 06, 2011 at 12:18:15AM +0100, Andreas Delmelle wrote:
> 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/BlockStackingLayoutManager.java
>
> In preparation of decommissioning its StackingIter, I noticed I had some
> minor cleanups ready for this class. Checking closer, the code was still way
> too messy for my taste, so I went further --and further... Quite far,
> actually, so a bit of explanation needed in case someone goes looking for
> code that I removed.
>
> I noticed there was quite a lot of code that, in fact, was never, ever used.
> It seemed like an experiment from Luca, that likely should have been kept in
> a branch instead of being committed to the trunk in an incomplete state. All
> it did here was confuse people, in a class which is quite heavily used.
> I first spent quite some time cleaning up commented log.debug() statements in
> the method createUnitElements(), then decided to check where the method was
> called, and found it was only used in one place, in getChangedKnuthElements():
>
> > -/* estensione: conversione complessiva */
> > -/*LF*/ if (bpUnit > 0) {
> > -/*LF*/ storedList = returnedList;
> > -/*LF*/ returnedList = createUnitElements(returnedList);
> > -/*LF*/ }
>
> Now, that bpUnit member is written *only* in BlockLayoutManager and
> BlockContainerLayoutManager, where it is set to 0 in the initialize() method.
> In effect, the method was unused, so I decided to bite the bullet and remove
> it.
>
> Additionally, given the above, I have also removed similar references to this
> bpUnit member in other places, which eliminates some conditional branches. I
> have not yet removed the variable itself, since it is still read in a few
> subclasses.
>
>
> Regards,
>
> Andreas
> ---
>
junit error in BitmapImageUtilTestCase
I get a junit failure in BitmapImageUtilTestCase: Testcase: testConvertToMono(org.apache.fop.util.BitmapImageUtilTestCase): FAILED expected:<0[1010100]0001000101010101> but was:<0[001000100010001]0001000101010101> junit.framework.ComparisonFailure: expected:<0[1010100]0001000101010101> but was:<0[001000100010001]0001000101010101> at org.apache.fop.util.BitmapImageUtilTestCase.assertPixels(BitmapImageUtilTestCase.java:105) at org.apache.fop.util.BitmapImageUtilTestCase.testConvertToMono(BitmapImageUtilTestCase.java:97) Simon
Re: svn commit: r1066275 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: KnuthPossPosIter.java PositionIterator.java
On Wed, Feb 02, 2011 at 01:02:47AM +0100, Andreas Delmelle wrote: > 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, the current situation struck me as slightly > awkward. > I am unsure of the original intentions when it was implemented, but the fact > is that we now have five PositionIterator subclasses, four of which override > the abstract getPos() and getLM() methods to do exactly the same thing... > Proposed alternative? Make PositionIterator non-abstract, provide default > implementations for getPos() and getLM(), and use the type directly, instead > of those scattered StackingIter inner classes in the LMs which are basically > copies of each other. Sounds good to me. Simon > Other suggestions to clean this up a bit? > > Regards, > > Andreas > --- >
Re: [VOTE] Merge FOP color branch into trunk
You are right. I got confused by various issues in my tools. The jar file was built by 'ant jar-main'. This target includes all cruft that is present in the build directory. The build files could do with an includes attribute in the jar task. Simon On Mon, Jan 31, 2011 at 09:12:10PM +0100, Jeremias Maerki wrote: > Hi Simon > > Huh? What revision are you looking at? I've merged Trunk into Temp_Color > on January 18 (http://svn.apache.org/viewvc?rev=1060241&view=rev) > copying the XGC.jar unchanged from Trunk. Temp_Color is long working > against java2d.color and is compiling just fine like that. Looking at > the XGC.jar in Trunk OTOH, it contains some junk in the root directory > and test classes further down the hierarchy. If anything we need to > rebuild the XGC.jar from Trunk and do another merge into Temp_Color. > Something must have gone wrong during the compilation of that JAR. > > http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=log&pathrev=1060241 > > I'll look at your other points shortly. Thanks for the review.
Re: Subversion merge or GIT merge?
Hi Peter, On Sun, Jan 30, 2011 at 12:16:04PM +, Peter Hancock wrote: > Would the decision to move from SVN to another VCS be in the hands of > the wider ASF community? The central repository is owned by the ASF and a decision to move is in the hands of the Apache Software Foundation membership. > Discussions about migrating from SVN to GIT are often held on > infrastructure-...@apache.org and I imagine it is only a matter of > time before this happens across the projects, and with sensible > consideration. I do not read infrastructure-...@apache.org, but I think that it is mainly a technical list, devoted a.o. to the development of the GIT front end to the ASF subversion repository. The political and legal issues of GIT vs. subversion are discussed on other lists. > GIT certainly makes the creation and merging of branches easier to > manage and this is just one of many features that FOP developers would > gain from a switch to GIT or another DVCS (Distributed VCS). Another > aspect of particular interest to contributors without committer status > is that a DVCS gives every developer first class version control of > their local development workflow, something that is not possible using > SVN alone. > Combining both SVN and GIT can get you a long way but as long as SVN > is the central VCS there will remain a steep learning curve required > to contribute effectively to FOP, and no satisfactory way of > addressing the issue of submitting patches: Currently, contributors > are encouraged to submit SVN compatible diffs to a Bugzilla issue, > however this format does not contain the richness of information > potential contained within a series local GIT commits. Submitting a > GIT generated diff preserves the original workflow, but then defers > the responsibility of handling the GiT SVN bridge onto the committer, > further adding a layer of complexity to a job that the time stretched > few currently struggle to keep on top of! The advantages, disadvantages, benefits and risks of GIT vs subversion have been discussed on the ASF email lists at length. I want to reiterate that for the ASF it is important that contributors _push_ the code which they want to contribute to an ASF project under their Contributor License Agreement. It cannot be _pulled_ by a committer. That is the main problem for the ASF in using a Distributed VCS. Legally it would be OK to submit a GIT patch. It might be useful to submit such a patch if you had agreed with a committer that they are willing to deal with your GIT patch. > I find GIT an indispensable tool and encourage all members of this > community to investigate GIT, or perhaps other next generation DVCS > (Distributed VCS), and see how they may help on both an individual and > collaborative basis. > > Pete Thanks for your considerations. Simon
Re: Subversion merge or GIT merge?
On Sat, Jan 29, 2011 at 02:08:29PM -0800, The Web Maestro wrote: > Are you saying you think we should consider: > a) moving from SVN to GIT I was careful not to make that suggestion. Such a move implies much more than merging. This has been discussed in the ASF and was rejected for now. The most important issue is the possibility to pull anyone's code changes. Apache projects must have a good overview of the provenance of their code; all code contributions must fall under a Copyright License Agreement with the ASF. It is not yet clear how that can be achieved with GIT. Every committer can decide for himself to use GIT via Apache's GIT mirror at https://github.com/apache/fop or http://git.apache.org/, and commit via git-svn. See http://www.apache.org/dev/git.html and http://wiki.apache.org/general/GitAtApache. As always, every committer must make sure that he commits his own code or code which was contributed to the ASF, via patches in bugzilla. > b) using GIT as a timesaver for conflicts? That is up to every developer himself. I just note the possibility to do so, and my good experience with it. Simon > Clay > > Sent from my iPhone > > On Jan 29, 2011, at 12:24 PM, Simon Pepping wrote: > > > I read in the literature that GIT and Mercurial merge would be very > > much better at resolving possible conflicts than subversion. Today I > > tested this with the merge of the Temp_Color branch into trunk. > > > > In GIT I used the GIT repository at https://github.com/apache/fop. The > > merge of Temp_Color resulted in one conflict, in status.xml. The > > conflict was presented precisely, and was easily resolved. > > > > The merge in Subversion resulted in the following: > > > > Summary of conflicts: > > Text conflicts: 16 > > Property conflicts: 1 > > Tree conflicts: 68 > > > > The many tree conflicts were files that were removed in the branch and > > trunk or added in both. Obviously they were caused by the merges of > > trunk into Temp_Color earlier. > > > > After the merge in GIT I got no compilation errors. I got three > > failures in the junit tests, which were also present in the branch. I > > investigated a few cases which gave a conflict in subversion. They > > were resolved correctly in GIT. > > > > This merge result is a huge time saver, and I thought I should let you > > know. > > > > Simon > > > > On Wed, Jan 19, 2011 at 11:56:34AM +0100, 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. > >> > >> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color > >> > >> +1 from me, obviously. > >> > >> Jeremias Maerki > >>
Re: [VOTE] Merge FOP color branch into trunk
I noticed that the XGC jar file in the Temp_Color branch differs from the current state of the XGC code in an important aspect for the Temp_Color branch: A number of classes, e.g. ColorWithAlternatives, have been moved from package java2d to java2d.color. I think that that change must be made in the Temp_Color branch before the merge. If not, the change must be made at the moment when the XGC jar file is updated, which is not a good moment. That changes my vote to -1 for the moment, until this change has been made. Simon On Sat, Jan 29, 2011 at 09:06:58PM +0100, Simon Pepping wrote: > I paid a little attention to the conditions determining the type of > ColorSpace, and came up with some questions: > > GraphicsSetProcessColor(Color color): Would it be possible to > implement and use ColorSpace.getNumComponents() instead of hard coding > the number of components here? > > GraphicsSetProcessColor.writeToStream and > PtocaBuilder.setExtendedTextColor: Ideally the data written out are > contained in the ColorSpace class instead of being contained in this > method for all types of ColorSpace; are they not? > > These are only minor points. Apart from the junit problems signalled > in my earlier email, I am in favour of merging this work into trunk: > +1. > > Thanks for this work. > > Simon > > On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote: > > I get three failures on the color branch junit tests: > > > > java version "1.6.0_18" > > OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) > > OpenJDK Server VM (build 16.0-b13, mixed mode) > > OS: GNU/Linux (Debian testing) > > > > [echo] Apache Ant version 1.8.0 compiled on March 11 2010 > > [echo] VM: 16.0-b13, Sun Microsystems Inc. > > > > [junit] Testcase: > > testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED > > [junit] expected:<255.0> but was:<250.0> > > > > [junit] Testcase: > > testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED > > [junit] expected:<255.0> but was:<253.0> > > > > [junit] Testcase: > > color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): > > FAILED > > [junit] org.custommonkey.xmlunit.Diff > > [junit] [different] Expected number of child nodes '14' but was '13' - > > comparing at > > /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to > > at > > /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] > > > > Simon > > > > On Wed, Jan 19, 2011 at 11:56:34AM +0100, 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. > > > > > > https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color > > > > > > +1 from me, obviously. > > > > > > Jeremias Maerki > > >
Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]
I read in the literature that GIT and Mercurial merge would be very much better at resolving possible conflicts than subversion. Today I tested this with the merge of the Temp_Color branch into trunk. In GIT I used the GIT repository at https://github.com/apache/fop. The merge of Temp_Color resulted in one conflict, in status.xml. The conflict was presented precisely, and was easily resolved. The merge in Subversion resulted in the following: Summary of conflicts: Text conflicts: 16 Property conflicts: 1 Tree conflicts: 68 The many tree conflicts were files that were removed in the branch and trunk or added in both. Obviously they were caused by the merges of trunk into Temp_Color earlier. After the merge in GIT I got no compilation errors. I got three failures in the junit tests, which were also present in the branch. I investigated a few cases which gave a conflict in subversion. They were resolved correctly in GIT. This merge result is a huge time saver, and I thought I should let you know. Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, 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. > > https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color > > +1 from me, obviously. > > Jeremias Maerki >
Re: [VOTE] Merge FOP color branch into trunk
I paid a little attention to the conditions determining the type of ColorSpace, and came up with some questions: GraphicsSetProcessColor(Color color): Would it be possible to implement and use ColorSpace.getNumComponents() instead of hard coding the number of components here? GraphicsSetProcessColor.writeToStream and PtocaBuilder.setExtendedTextColor: Ideally the data written out are contained in the ColorSpace class instead of being contained in this method for all types of ColorSpace; are they not? These are only minor points. Apart from the junit problems signalled in my earlier email, I am in favour of merging this work into trunk: +1. Thanks for this work. Simon On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote: > I get three failures on the color branch junit tests: > > java version "1.6.0_18" > OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) > OpenJDK Server VM (build 16.0-b13, mixed mode) > OS: GNU/Linux (Debian testing) > > [echo] Apache Ant version 1.8.0 compiled on March 11 2010 > [echo] VM: 16.0-b13, Sun Microsystems Inc. > > [junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase): > FAILED > [junit] expected:<255.0> but was:<250.0> > > [junit] Testcase: > testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED > [junit] expected:<255.0> but was:<253.0> > > [junit] Testcase: > color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): > FAILED > [junit] org.custommonkey.xmlunit.Diff > [junit] [different] Expected number of child nodes '14' but was '13' - > comparing at > /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to > at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] > > Simon > > On Wed, Jan 19, 2011 at 11:56:34AM +0100, 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. > > > > https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color > > > > +1 from me, obviously. > > > > Jeremias Maerki > >
Re: [VOTE] Merge FOP color branch into trunk
I get three failures on the color branch junit tests: java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) OpenJDK Server VM (build 16.0-b13, mixed mode) OS: GNU/Linux (Debian testing) [echo] Apache Ant version 1.8.0 compiled on March 11 2010 [echo] VM: 16.0-b13, Sun Microsystems Inc. [junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:<255.0> but was:<250.0> [junit] Testcase: testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:<255.0> but was:<253.0> [junit] Testcase: color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): FAILED [junit] org.custommonkey.xmlunit.Diff [junit] [different] Expected number of child nodes '14' but was '13' - comparing at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, 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. > > https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color > > +1 from me, obviously. > > Jeremias Maerki >
OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]
I take this discussion to express my worries that FOP needs to create its own support for fonts, among which Open Type Fonts. FOP's core task is the layout and printing of FO files. If FOP could rely on good font libraries, that would make our code base so much smaller and our development tasks so much easier. If I am not mistaken, Firefox does a fairly good job at representing Indic scripts. Do they use a generally available library? Are there no such libraries? Or do I see the issue wrong? Regards, Simon On Tue, Jan 18, 2011 at 04:11:54PM -0700, Glenn Adams wrote: > That is a better question, but one I cannot answer, as I have not looked > into the CFF support issue. Perhaps another DEV would care to respond. > > On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic wrote: > > > On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams wrote: > > > > > > On Tue, Jan 18, 2011 at 3:41 PM, Ivan Ristic > > wrote: > > >> > > >> On Tue, Jan 18, 2011 at 9:27 PM, Glenn Adams wrote: > > >> > What do you mean by "fully"? If you are referring to the OpenType > > GDEF, > > >> > GSUB, GPOS support, then work is already underway to add that > > >> > functionality. > > >> > See the following for further info: > > >> > http://people.apache.org/~spepping/ > > >> > http://wiki.apache.org/xmlgraphics-fop/ComplexScripts
Re: DO NOT REPLY [Bug 50590] New: function fop_exec() doesn't work in fop.js launcher
Wow, on the last day of the fourth year after I committed this script, it is proven that someone actually uses it. (I do not use it myself since I never work on MS Windows.) I have always considered JScript a much smarter solution than the shell in windows. But the world is not waiting for smart solutions. :( Simon On Sat, Jan 15, 2011 at 11:58:42AM -0500, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=50590 > >Summary: function fop_exec() doesn't work in fop.js launcher >Product: Fop >Version: 1.0 > Platform: PC > Status: NEW > Severity: minor > Priority: P2 > Component: general > AssignedTo: fop-dev@xmlgraphics.apache.org > ReportedBy: sergey...@gmail.com > > > There is a small typo in the function fop_exec() in JScript startup file. A > symbol '+' is missing there.
Re: The base of relative URIs in fop.xconf
Done. Simon On Tue, Jan 11, 2011 at 07:40:59PM +0100, Simon Pepping wrote: > On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: > > Hi, > > > > When configuring the base directory using the fop.xconf relative urls > > are based on the working directory, and not the fop.xconf. > > This contradicts the URI specification as pointed out in > > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html > > I hate it when applications show this bug. I was not aware that FOP > suffers from it. The problem must be solved as soon as possible. > > > Can anyone suggest a robust way of achieving this scenario, given the > > current limitations of FOP, or should I fix this bug? > > It would be wonderful if you can provide a fix. > > Simon
Re: The base of relative URIs in fop.xconf
On Tue, Jan 11, 2011 at 10:55:25AM +, Peter Hancock wrote: > Hi, > > When configuring the base directory using the fop.xconf relative urls > are based on the working directory, and not the fop.xconf. > This contradicts the URI specification as pointed out in > http://old.nabble.com/Re%3A-Problem-with-custom-fonts-p10013042.html I hate it when applications show this bug. I was not aware that FOP suffers from it. The problem must be solved as soon as possible. > Can anyone suggest a robust way of achieving this scenario, given the > current limitations of FOP, or should I fix this bug? It would be wonderful if you can provide a fix. Simon
Re: DO NOT REPLY [Bug 48380] ClassCastException when using fox:widow-content-limit
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? Simon On Wed, Jan 05, 2011 at 02:01:55PM -0500, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=48380 > > --- Comment #2 from Andreas L. Delmelle 2011-01-05 > 14:01:49 EST --- > Created an attachment (id=26460) > --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26460) > proposed patch to ElementListUtils.java > > Apologies for the late response... > > I noticed the issue did not occur with fox:orphan-content-limit, since that > triggers a call to ElementListUtils.removeLegalBreaksFromEnd(), which was > equipped to deal with SpaceElements, contrary to the method > removeLegalBreaks(), where the exception was thrown. > Seems like the implementations of both methods were meant to be analogous, but > got out of alignment. > Proposal is to fix this by merging the implementations into one private > method, > as they were almost identical anyway (apart from 3-4 lines, which can be > handled rather gracefully through conditionals). > For now, the proposed fix does not alter the behavior in any way, except by > avoiding the potential ClassCastException, although it did get me wondering > whether the treatment of spaces is always correct here... > Think: consecutive/adjoining spaces with a different precedence value, and > whether it is correct to just add the space's optimum width. Theoretically, it > seems possible that we leave in a break-opportunity that turns out (= after > space-resolution) to leave less content before the break than the constraint > specifies, because we counted 2 spaces here, of which only one is retained in > the eventual output (?) > > -- > 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: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On Fri, Jan 07, 2011 at 02:44:13PM +0100, Jeremias Maerki wrote: > I think so. The use of "#" is mostly historical due to lack of Unicode > support initially. At least I believe so. The first fonts were WinAnsi > only. IMO, it makes sense to make that transition. However, for > single-byte fonts, we might still need to use "#". Not sure. Then it might be better to use '?', which many tools use for that purpose. Let us put that on our wish list. It is not part of the fix for this bug report. Simon > On 07.01.2011 14:17:42 Simon Pepping wrote: > > On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 > > > > > > --- Comment #4 from Andreas L. Delmelle 2011-01-07 > > > 07:31:03 EST --- > > > > > > Very right indeed. > > > 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. > > > Treating them as regular alphabetic characters seems to be safe enough > > > for the > > > time being. > > > > Would it not be better to use character FFFD, 'Replacement Character', > > ?, for this?
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On Fri, Jan 07, 2011 at 02:38:49PM +0100, Andreas Delmelle wrote: > 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. > >> Treating them as regular alphabetic characters seems to be safe enough for > >> the > >> time being. > > > > Would it not be better to use character FFFD, 'Replacement Character', > > �, for this? > > Interesting. In the context of linebreaking, that comes down to basically the > same thing. > > U+FFFD has linebreak class 'AI' or 'Ambiguous', which is currently also > converted to 'Alphabetic' as part of the initial conversions. > > Are you suggesting that we substitute the codepoint in the actual text > content (rather than leave it there, and further rely on the default > treatment of 'missing glyphs')? 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? Really replacing the character in the text would go very far. A missing glyph is usually dependent on the chosen font, while the character itself is quite valid. In this case, however, the character itself is invalid, in the sense that the code point has not been assigned to a character in Unicode. (The bug report calls 1F7E a Greek extended character, but the Unicode chart for Greek extended characters, http://www.unicode.org/charts/PDF/U1F00.pdf, shows no character assignment for this code point.) That means that it does not even have properties, such as a linebreaking class. Using class 'Ambiguous' seems the right solution for that problem. Simon
Re: [Bug 50471] Greek Extended character throwing ArrayIndexOutOfBoundException.
On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=50471 > > --- Comment #4 from Andreas L. Delmelle 2011-01-07 > 07:31:03 EST --- > > Very right indeed. > 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. > Treating them as regular alphabetic characters seems to be safe enough for the > time being. Would it not be better to use character FFFD, 'Replacement Character', �, for this? Simon
Re: Patch for large memory usage inside o.a.f.r.p.PDFDocumentHandler
I implemented your suggestion in revision 1052214. Thanks. In order to omit keeping any reference, you might implement a command line option. Alternatively, you might implement scanning the fo tree to check if any page references are used. However, this would only work if there is only one page sequence in the fo file. There is no way to know that during processing, since FOP processes one page sequence at a time, without looking forward in the fo file. Other than LaTeX, FOP implements a one-time process including page references. The price seems to be the use of memory to keep the necessary data if any reference would occur. Simon On Wed, Dec 22, 2010 at 06:59:08PM +0200, Alexios Giotis wrote: > Hi fop-dev, > > In one of my use cases, I create a PDF file having about 2 pages from FOP > intermediate format. I imagined this as a streaming process (e.g. read a page > in FOP_IF, write it to PDF and release memory) with the exception of caching > of images. In reality, by analyzing a heap dump taken with the > -XX:+HeapDumpOnOutOfMemoryError parameter on a production server, I found out > that o.a.f.r.p.PDFDocumentHandler keeps for every page a reference to be used > for bookmarks & outlines. In my case, the retained heap size of every page > is about 150kb. If you multiply this with the number of pages, the memory > usage is large. Even worse, on my production server I have 10 threads > creating 20k page documents in parallel. > > Attached is a patch against the latest revision 1051938 of trunk that > considerably reduces the memory usage by keeping only a String pdfPageRef > instead of the full org.apache.fop.pdf.PDFReference object. This was possible > because from the object we only need to get that string. Ideally, I would > like not to keep at all the page references if bookmarks & outlines are not > used. Or at least, keep it only for the pages that are indeed referenced. Is > this possible ? If so, do you have any hints for this ? > > If further optimizations are not possible or complex, then I guess I will > just open an issue and attach this patch. I hope you agree with the addition > of generics on the Map declaration and with the change of "new Integer()" to > "Integer.valueOf())" (findbugs performance warning).
Re: A question about working on apache fop
Hi Martin and Roland, The FOP team is pleased to accept contributions to FOP, large and small. Contributions are best submitted as a patch attached to an issue in our bug tracking system bugzilla, http://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop. If you plan a larger contribution, such as the one you intend to develop, it is useful to create a single bugzilla issue, and attach subsequent patches to it. We will create a Subversion branch for your project, to which we will add your patches. We will also keep the branch up to date with respect to the main code (Subversion trunk), so that integration of your contributions with the main code is tested automatically. Our ant build system allows one to test the code with junit, checkstyle, and findbugs tests. We encourage contributors to run those tests. We also encourage them to create and submit test cases for their new functionality or feature and bug fixes. The use of a subversion branch allows you to submit an early implementation to FOP, and discard it later. In view of the complexity of the work, it may be useful to create design documents first, along with theoretical considerations about the algorithms used. You may publish these in your own web space, but you may also use FOP's wiki, http://wiki.apache.org/xmlgraphics-fop/DeveloperPages, for that purpose. The code in our subversion repository is automatically synchronized in a git repository, git://git.apache.org/fop.git or https://github.com/apache/fop. See also http://wiki.apache.org/general/GitAtApache. For larger contributions, the Apache Software Foundation (ASF) wishes to have a contributor license of all copyright owners (authors or their employers) of the submitted code, see http://www.apache.org/licenses/#clas. See also 'How can I contribute?', http://xmlgraphics.apache.org/fop/dev/faq.html#faq-N1000D. See also some parts of 'Guide for new committers', http://www.apache.org/dev/new-committers-guide.html. This enables the ASF to release the code under the Apache license version 2. All contributions must go via patches at bugzilla, so that it is clear that you submitted them under your contributor license with the ASF. Therefore, if you would maintain a public git branch or a public branch in another distributed VC system, we would not pull directly from it. Your first steps would be anything you need to do to arrive at your first submitted patch: design, code, test, submit. You could open a bugzilla issue early if you wish. You could create a wiki page for your project and add design documents to it. We hope to see your contributions to FOP, to the benefit of all its users. Best, Simon Pepping On Tue, Dec 21, 2010 at 04:40:11PM +0100, Roland Schwarz wrote: > Dear developers, dear members of the Project Management, > > we work on a research project called "XML-Print" at the University of > Trier, Germany. The idea is to implement (or improve) a XML to PDF > typesetter with an easy-to-use GUI which helps humanists to publish > their critical editions, dictionaries etc. It will be part of the > toolkit "TextGrid Lab" which is a long-term project to develop a general > framework containing different tools for collaborative work on digital > documents (http://www.textgrid.de/en/startseite.html). > > Having looked at existing approaches FOP seems to be a stable and > promising base to build on. However there are some features missing > either not yet implemented in FOP itself or even not defined in XSL-FO 1.1. > > We therefore would have to implement features based on XSL-FO 1.1, but > also on the requirements for XSL-FO 2.0 as described in > http://www.w3.org/TR/xslfo20-req/. > > Among others we are especially interested in some elements mentioned in > the current design draft like > > - marginalia (2.2.3) > - side-by-side flows (2.2.6) > - line numbering (2.2.7.1) ** > - cross references (2.2.8) > > ** The line numbering will also involve some more complex issues, not > only a simple line numbering of every n-th line. For example there could > be interactions between line numbers and marginalia, which have to be > considered in the typesetting process. > > > We would also have to design and implement new layout features currently > not mentioned in any seen XSL-FO design draft like the usage of a > complex bibliographic apparatus or a grid typesetting feature. There are > also requirements for complex footnotes, which may lead to an extension > of the currently available footnote mechanism in the XSL-FO standard. > > At the current point in our work we wonder how we can use the current > status of FOP, how we can embed our work into future releases and last > but not least, give some work back to the community. One developer would > work full-time on FOP for at least one year. > > Furthermore
Design Notes for Extensible Stylesheet Language (XSL) 2.0 Draft Published
Design Notes for Extensible Stylesheet Language (XSL) 2.0 Draft Published, see http://www.w3.org/News/2010#entry-8981. Simon
Re: DO NOT REPLY [Bug 38880] Right border on fo:inline missing when hyphenate=true
That is a lot of bugs solved. Thanks for looking through the bug reports. Simon On Sun, Dec 19, 2010 at 09:36:16AM -0500, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=38880 > > Matthias Reischenbacher changed: > >What|Removed |Added > > Status|ASSIGNED|RESOLVED > Resolution||DUPLICATE > > --- Comment #3 from Matthias Reischenbacher 2010-12-19 > 09:36:11 EST --- > > > *** This bug has been marked as a duplicate of bug 49870 *** >
Re: 2 failures in unit tests
Fixed in r1042150, Simon On Fri, Dec 03, 2010 at 08:44:58PM +0100, Simon Pepping wrote: > There are two failures in the unit tests: > > junit-layout-standard: > [junit] Testcase: > kerning_1_on.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): > Caused an ERROR > [junit] Expected XPath expression to evaluate to '36420', but got '40020' > (XPath: //flow/block[1]/block[1]/lineArea/inlineparent/@ipd) > > junit-layout-hyphenation: > [junit] Testcase: > block_hyphenation_kerning.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): > Caused an ERROR > [junit] Expected XPath expression to evaluate to '17230', but got '32709' > (XPath: //flow/block[1]/lineArea[1]/text[1]/@twsadjust) > > Simon
2 failures in unit tests
There are two failures in the unit tests: junit-layout-standard: [junit] Testcase: kerning_1_on.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): Caused an ERROR [junit] Expected XPath expression to evaluate to '36420', but got '40020' (XPath: //flow/block[1]/block[1]/lineArea/inlineparent/@ipd) junit-layout-hyphenation: [junit] Testcase: block_hyphenation_kerning.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): Caused an ERROR [junit] Expected XPath expression to evaluate to '17230', but got '32709' (XPath: //flow/block[1]/lineArea[1]/text[1]/@twsadjust) Simon
Welcome back into FOP activity
Hi Andreas, Welcome back into FOP activity. Simon On Thu, Nov 25, 2010 at 04:31:38PM -0500, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=38264 > > Andreas L. Delmelle changed: > >What|Removed |Added > > Status|ASSIGNED|RESOLVED > Resolution||FIXED > > --- Comment #13 from Andreas L. Delmelle 2010-11-25 > 16:31:26 EST ---
Re: new findbug errors
Glenn, One note: You introduced findbugs as a tool, and you created the findbugs target in the build file. Simon On Fri, Nov 19, 2010 at 08:28:09AM -0700, Glenn Adams wrote: > Thanks! You say: > > "I note that we have not accepted findbugs as a tool of the project. I > think that not all developers are a fan of the tool." > > Is there an alternative, and equally or more effective tool that is > acceptable to more developers, e.g., PMD? If there is, then perhaps we > should migrate to it? If not, then perhaps we should make findbugs a "tool > of the project". Since there has been a "findbugs" target in build.xml for a > while (at least it was there when I started on the project), it seems like > it is in some way a "tool of the project". > > In any case, I believe we should make regular use of findbugs or a suitable > alternative, and that no commit should occur without verifying that no new > errors/warnings are being introduced.
Re: new findbug errors
I committed an exclusion filter that suppresses all existing findbug warnings (966). I generated it from the findbugs xml report. Then I moved all NM_CONFUSING out of the automatically generated block. When you get a new findbugs warning, you may 1. resolve it; 2. leave it unresolved, and add it to the exclusion filter, with comment; 3. leave it unsolved, and add it to the automatic block of the exclusion filter. I note that we have not accepted findbugs as a tool of the project. I think that not all developers are a fan of the tool. The main template of the xslt script that generated the exclusion filter is as follows: Listing the method 'equals' does not work Listing the field does not work; this makes the filter apply to all masked fields Neither method nor field Simon On Wed, Nov 17, 2010 at 07:24:43PM +0100, Simon Pepping wrote: > I will take care of this. I am now squashing the easier > findbugs-reported bugs/problems. Then I will add the remaining ones to > the exclusion file, such that those that are really excluded can be > distinguished from those which have not yet been examined.
Re: svn commit: r1036179 [1/2] - in /xmlgraphics/fop/trunk
I will revert the renaming of public methods. It was not a good idea. Sorry for the noise. Simon On Thu, Nov 18, 2010 at 05:03:34PM +0100, Simon Pepping wrote: > It breaks org.krysalis.barcode4j.fop.BarcodeXMLHandler: getNamespace > -> getNameSpace (from render.xml.XMLXMLHandler.getNamespace -> > getNameSpace > > On Thu, Nov 18, 2010 at 04:42:44PM +0100, Simon Pepping wrote: > > render.AbstractGenericSVGHandler.getNamespace -> getNameSpace > > render.intermediate.extensions.AbstractAction.setID -> setId > > render.intermediate.extensions.AbstractAction.getID -> getId > > render.intermediate.extensions.AbstractAction.hasID -> hasId > > render.intermediate.extensions.AbstractAction.getIDPrefix -> getIdPrefix > > render.intermediate.extensions.URIAction.getIDPrefix -> getIdPrefix > > render.XMLHandler.getNamespace -> getNameSpace > > render.ps.PSImageFormResource.getImageURI -> getImageUri > > render.xml.XMLXMLHandler.getNamespace -> getNameSpace > > render.afp.AFPRendererImageInfo.getURI -> getUri > > fonts.type1.PFMFile.getPostscriptName -> getPostScriptName > > tools.TestConverter.setBaseDir -> setBasedir > > tools.anttasks.Fop.setUserconfig -> setUserConfig > > tools.anttasks.Fop.getUserconfig -> getUserConfig() > > tools.anttasks.Fop.setFofile -> setFoFile > > tools.anttasks.Fop.getFofile -> getFoFile > > tools.anttasks.Fop.setThrowexceptions -> setThrowExceptions > > tools.anttasks.Fop.getThrowexceptions -> getThrowExceptions > > apps.PageSequenceResults.getID -> getId > > fo.FOText.getBaseLineShift -> getBaselineShift > > cli.CommandLineOptions.getFOFile -> getFoFile > > cli.CommandLineOptions.getXMLFile -> getXmlFile > > cli.CommandLineOptions.getXSLFile -> getXslFile > > > > On Wed, Nov 17, 2010 at 09:29:06PM +0100, Simon Pepping wrote: > > > On Wed, Nov 17, 2010 at 07:45:31PM -, spepp...@apache.org wrote: > > > > Author: spepping > > > > Date: Wed Nov 17 19:45:27 2010 > > > > New Revision: 1036179 > > > > > > > > URL: http://svn.apache.org/viewvc?rev=1036179&view=rev > > > > Log: > > > > findbugs-reported bug squashing; 959 bugs left (findbugs 1.3.9) > > > > > > findbugs reports naming problems in public methods, such as setters > > > and getters. I resolved those problems. But in doing so, in principle > > > I am changing the public API. I do not think that every public method > > > is really in use by other applications. Let me know when I go too far > > > in those changes, harming applications that depend on fop. > > > > > > Simon > > >
Re: svn commit: r1036179 [1/2] - in /xmlgraphics/fop/trunk
It breaks org.krysalis.barcode4j.fop.BarcodeXMLHandler: getNamespace -> getNameSpace (from render.xml.XMLXMLHandler.getNamespace -> getNameSpace On Thu, Nov 18, 2010 at 04:42:44PM +0100, Simon Pepping wrote: > render.AbstractGenericSVGHandler.getNamespace -> getNameSpace > render.intermediate.extensions.AbstractAction.setID -> setId > render.intermediate.extensions.AbstractAction.getID -> getId > render.intermediate.extensions.AbstractAction.hasID -> hasId > render.intermediate.extensions.AbstractAction.getIDPrefix -> getIdPrefix > render.intermediate.extensions.URIAction.getIDPrefix -> getIdPrefix > render.XMLHandler.getNamespace -> getNameSpace > render.ps.PSImageFormResource.getImageURI -> getImageUri > render.xml.XMLXMLHandler.getNamespace -> getNameSpace > render.afp.AFPRendererImageInfo.getURI -> getUri > fonts.type1.PFMFile.getPostscriptName -> getPostScriptName > tools.TestConverter.setBaseDir -> setBasedir > tools.anttasks.Fop.setUserconfig -> setUserConfig > tools.anttasks.Fop.getUserconfig -> getUserConfig() > tools.anttasks.Fop.setFofile -> setFoFile > tools.anttasks.Fop.getFofile -> getFoFile > tools.anttasks.Fop.setThrowexceptions -> setThrowExceptions > tools.anttasks.Fop.getThrowexceptions -> getThrowExceptions > apps.PageSequenceResults.getID -> getId > fo.FOText.getBaseLineShift -> getBaselineShift > cli.CommandLineOptions.getFOFile -> getFoFile > cli.CommandLineOptions.getXMLFile -> getXmlFile > cli.CommandLineOptions.getXSLFile -> getXslFile > > On Wed, Nov 17, 2010 at 09:29:06PM +0100, Simon Pepping wrote: > > On Wed, Nov 17, 2010 at 07:45:31PM -, spepp...@apache.org wrote: > > > Author: spepping > > > Date: Wed Nov 17 19:45:27 2010 > > > New Revision: 1036179 > > > > > > URL: http://svn.apache.org/viewvc?rev=1036179&view=rev > > > Log: > > > findbugs-reported bug squashing; 959 bugs left (findbugs 1.3.9) > > > > findbugs reports naming problems in public methods, such as setters > > and getters. I resolved those problems. But in doing so, in principle > > I am changing the public API. I do not think that every public method > > is really in use by other applications. Let me know when I go too far > > in those changes, harming applications that depend on fop. > > > > Simon > >
Re: svn commit: r1036179 [1/2] - in /xmlgraphics/fop/trunk
render.AbstractGenericSVGHandler.getNamespace -> getNameSpace render.intermediate.extensions.AbstractAction.setID -> setId render.intermediate.extensions.AbstractAction.getID -> getId render.intermediate.extensions.AbstractAction.hasID -> hasId render.intermediate.extensions.AbstractAction.getIDPrefix -> getIdPrefix render.intermediate.extensions.URIAction.getIDPrefix -> getIdPrefix render.XMLHandler.getNamespace -> getNameSpace render.ps.PSImageFormResource.getImageURI -> getImageUri render.xml.XMLXMLHandler.getNamespace -> getNameSpace render.afp.AFPRendererImageInfo.getURI -> getUri fonts.type1.PFMFile.getPostscriptName -> getPostScriptName tools.TestConverter.setBaseDir -> setBasedir tools.anttasks.Fop.setUserconfig -> setUserConfig tools.anttasks.Fop.getUserconfig -> getUserConfig() tools.anttasks.Fop.setFofile -> setFoFile tools.anttasks.Fop.getFofile -> getFoFile tools.anttasks.Fop.setThrowexceptions -> setThrowExceptions tools.anttasks.Fop.getThrowexceptions -> getThrowExceptions apps.PageSequenceResults.getID -> getId fo.FOText.getBaseLineShift -> getBaselineShift cli.CommandLineOptions.getFOFile -> getFoFile cli.CommandLineOptions.getXMLFile -> getXmlFile cli.CommandLineOptions.getXSLFile -> getXslFile On Wed, Nov 17, 2010 at 09:29:06PM +0100, Simon Pepping wrote: > On Wed, Nov 17, 2010 at 07:45:31PM -, spepp...@apache.org wrote: > > Author: spepping > > Date: Wed Nov 17 19:45:27 2010 > > New Revision: 1036179 > > > > URL: http://svn.apache.org/viewvc?rev=1036179&view=rev > > Log: > > findbugs-reported bug squashing; 959 bugs left (findbugs 1.3.9) > > findbugs reports naming problems in public methods, such as setters > and getters. I resolved those problems. But in doing so, in principle > I am changing the public API. I do not think that every public method > is really in use by other applications. Let me know when I go too far > in those changes, harming applications that depend on fop. > > Simon >
Re: buildbot failure in ASF Buildbot on fop-trunk
Should be fixed now. Simon On Thu, Nov 18, 2010 at 08:00:27AM +, build...@apache.org wrote: > The Buildbot has detected a new failure of fop-trunk on ASF Buildbot. > Full details are available at: > http://ci.apache.org/builders/fop-trunk/builds/68 > > Buildbot URL: http://ci.apache.org/ > > Buildslave for this Build: ceres_ubuntu > > Build Reason: The Nightly scheduler named 'fopNightly' triggered this build > Build Source Stamp: HEAD > Blamelist: > > BUILD FAILED: failed compile > > sincerely, > -The Buildbot >
Re: svn commit: r1036179 [1/2] - in /xmlgraphics/fop/trunk
On Thu, Nov 18, 2010 at 11:25:10AM +, Vincent Hennebert wrote: > Hi Simon, > > On 17/11/10 20:29, Simon Pepping wrote: > > On Wed, Nov 17, 2010 at 07:45:31PM -, spepp...@apache.org wrote: > >> Author: spepping > >> Date: Wed Nov 17 19:45:27 2010 > >> New Revision: 1036179 > >> > >> URL: http://svn.apache.org/viewvc?rev=1036179&view=rev > >> Log: > >> findbugs-reported bug squashing; 959 bugs left (findbugs 1.3.9) > > > > findbugs reports naming problems in public methods, such as setters > > and getters. I resolved those problems. But in doing so, in principle > > I am changing the public API. I do not think that every public method > > is really in use by other applications. Let me know when I go too far > > in those changes, harming applications that depend on fop. > > Good work, thanks for that. There are a few renamings that I’m not sure > I agree with, though: > > • an ID is written ID, all upper case. Id is something else [1] that > I believe is outside the scope of FOP ;-) > So I would keep the names setID and getID, and not rename them into > setId/getId. Affected classes are o.a.f.apps.PageSequenceResults, > o.a.f.render.intermediate.extensions.AbstractAction and > o.a.f.render.intermediate.extensions.URIAction > > [1] http://www.thefreedictionary.com/ID > > • likewise, URI is an acronym that’s always written upper case, and > I think that should remain so. FWIW, the Java standard library uses > names like toURI, toURL, etc. Affected classes are > o.a.f.render.afp.AFPRendererImageInfo and > o.a.f.render.ps.PSImageFormResource > > • namespace is not theoretically an English word but its use has been so > pervasive (in the W3C Namespaces recommendation, to start with), that > I would keep it like this. Affected classes are > o.a.f.render.XMLHandler and descendants. Findbugs reports inconsistencies in naming. That means that there is Id and ID, Uri and URI, NameSpace and Namespace, in the Fop code. I chose for the starting capital with lc as a pattern, but I do not have a strong preference. Simon
Re: svn commit: r1036179 [1/2] - in /xmlgraphics/fop/trunk: ./ examples/embedding/java/embedding/ src/java/org/apache/fop/afp/ src/java/org/apache/fop/afp/modca/ src/java/org/apache/fop/apps/ src/java
On Wed, Nov 17, 2010 at 07:45:31PM -, spepp...@apache.org wrote: > Author: spepping > Date: Wed Nov 17 19:45:27 2010 > New Revision: 1036179 > > URL: http://svn.apache.org/viewvc?rev=1036179&view=rev > Log: > findbugs-reported bug squashing; 959 bugs left (findbugs 1.3.9) findbugs reports naming problems in public methods, such as setters and getters. I resolved those problems. But in doing so, in principle I am changing the public API. I do not think that every public method is really in use by other applications. Let me know when I go too far in those changes, harming applications that depend on fop. Simon
Re: new findbug errors
I will take care of this. I am now squashing the easier findbugs-reported bugs/problems. Then I will add the remaining ones to the exclusion file, such that those that are really excluded can be distinguished from those which have not yet been examined. Simon On Tue, Nov 16, 2010 at 09:41:00AM -0700, Glenn Adams wrote: > I notice a few new findbugs errors creeping into trunk. Please try to run > the findbugs target before commiting in order to fix any newly introduced > bugs. Here are the new ones I see: > > > Bug type MS_SHOULD_BE_FINAL (click for > details) > > In class org.apache.fop.render.rtf.rtflib.rtfdoc.RtfTextrunField > org.apache.fop.render.rtf.rtflib.rtfdoc.RtfTextrun.logAt > RtfTextrun.java:[line 57] > > > Bug type DM_NUMBER_CTOR (click for details) > > In class org.apache.fop.render.rtf.rtflib.rtfdoc.RtfTextrunIn > method > org.apache.fop.render.rtf.rtflib.rtfdoc.RtfTextrun.addParagraphBreak()Called > method new Integer(int)Should cal\ > l Integer.valueOf(int) insteadAt RtfTextrun.java:[line 304] > > > Bug type DLS_DEAD_LOCAL_STORE (click for > details) > > In class org.apache.fop.render.rtf.rtflib.rtfdoc.RtfTextrunIn > method > org.apache.fop.render.rtf.rtflib.rtfdoc.RtfTextrun.addString(String)Local > variable named rAt RtfTextrun.java:[\ > line 274] > > After fixing the above three, there should remain 1048 errors/warnings > reported by findbugs in trunk. It would be nice if we could eliminate all of > these (either by fixing or by adding exclusions to findbugs-exclude.xml), as > it is much easier to check for new ones if there are none to start with. > > Regards, > Glenn
Re: svn commit: r1036000 - in /xmlgraphics/fop/trunk/lib: xmlgraphics-commons-1.4.jar xmlgraphics-commons-1.5svn.jar
Note that, in order to have all junit tests succeed in headless mode, we also require a new Batik jar with the patch of bug 42408. Until that has been released, we have 5 failures in headless mode. Simon On Wed, Nov 17, 2010 at 12:39:54PM -, spepp...@apache.org wrote: > Author: spepping > Date: Wed Nov 17 12:39:54 2010 > New Revision: 1036000 > > URL: http://svn.apache.org/viewvc?rev=1036000&view=rev > Log: > Update XGC library to pull in the fix for headless junit tests, bug 50253 > > Added: > xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.5svn.jar (with props) > Removed: > xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4.jar
Re: svn commit: r1035276 - /xmlgraphics/fop/trunk/test/java/org/apache/fop/fonts/EncodingModeTest.java
Oops. Sorry, sloppy work on my part. Simon On Mon, Nov 15, 2010 at 01:52:58PM -, jerem...@apache.org wrote: > Author: jeremias > Date: Mon Nov 15 13:52:58 2010 > New Revision: 1035276 > > URL: http://svn.apache.org/viewvc?rev=1035276&view=rev > Log: > Added missing license header.
Re: svn commit: r1003845 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/Hyphenator.java
On Sat, Oct 02, 2010 at 05:48:07PM -, spepp...@apache.org wrote: > Author: spepping > Date: Sat Oct 2 17:48:07 2010 > New Revision: 1003845 > > URL: http://svn.apache.org/viewvc?rev=1003845&view=rev > Log: > Remove unused methods from Hyphenator; this leaves a utility class > > Modified: > xmlgraphics/fop/trunk/src/java/org/apache/fop/hyphenation/Hyphenator.java > When I wanted to add configurability for hyphenation pattern file names, I had to analyse the callers of a lot of Hyphenator methods, to see if they needed access to the configuration. It turned out that several methods were never called from within FOP. Even the Hyphenator constructor is not called from within FOP, so that there never is a Hyphenator object in FOP. I removed these methods because it facilitates working on FOP's code, and saves a lot of time. Of course, there is a remote possibility that these public methods are used by an external application, but that is so remote as to be beyond my horizon. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Complex Chained Contextual Substitution (GSUB) and Positioning (GPOS) Example
Ah, yes, our own TTFReader. Its output says it all. A selection from the diff: >diff simpo.out.txt simpo-GA.out.txt 6,8c6,8 < Reading 15 dir tables < dir tables: [loca, post, DSIG, glyf, fpgm, hmtx, hhea, prep, GSUB, cvt , OS/2, cmap, name, head, maxp] < flags: 8 - 1000 --- > Reading 21 dir tables > dir tables: [loca, post, DSIG, glyf, fpgm, hmtx, GPOS, hhea, prep, GSUB, > GDEF, hdmx, cvt , gasp, name, OS/2, cmap, VDMX, LTSH, head, maxp] > flags: 24 - 11000 11c11 < Number of glyphs in font: 414 --- > Number of glyphs in font: 473 14c14 < Number of horizontal metrics: 414 --- > Number of horizontal metrics: 473 and most importantly: 31c31 < 1 0 0 5 Version 5.00 --- > 1 0 0 5 Version 5.92 43c43 < 3 1 1033 5 Version 5.00 --- > 3 1 1033 5 Version 5.92 plus a long listing of tables which are not in version 5.00. I think you should reflect this version on your Trac site. I see on the web that v 5.92 is distributed with Windows 7. I do not have that. Simon On Fri, Sep 24, 2010 at 09:13:50AM +0800, Glenn Adams wrote: > If you want to see what FOP thinks is in the font, then you can use the > TTFReader application with the -d option, e.g., > > > > > > > > > > > > > > > > > > > > > > Which for Simplified Arabic 5.0 produces the output shown in the attached > file. -- Simon Pepping home page: http://www.leverkruid.eu
Re: Complex Chained Contextual Substitution (GSUB) and Positioning (GPOS) Example
Glenn, If you want to make your progress visible to more users, and invite them to test this, then 1. It may be useful to cross-post this to fop-users. 2. To make a binary distribution available of the code. I could build a binary distribution, but I cannot post it on my ASF page; I could post it on your Trac site. OTOH, why do you not (yet) submit a patch? Then I could do both easily. Simon On Tue, Sep 21, 2010 at 11:30:41PM +0800, Glenn Adams wrote: > Attached is a sample input FO, output IF, and output PDF example showing the > functioning of complex chained contextual glyph substitution and glyph > positioning operations, now available on my working dev branch at git:// > github.com/skynavga/fop.git. > > The GDEF (glyph definition) table is now supported as well in order to > correctly process the IgnoreBase, IgnoreLigatures, IgnoreMarks lookup flags > according to font defined glyph classes. > > Regards, > Glenn -- Simon Pepping home page: http://www.leverkruid.eu
Re: Complex Chained Contextual Substitution (GSUB) and Positioning (GPOS) Example
Glenn, Thanks. I tried it, and again it did not work for me. I installed fontforge, and looked into the font. It is 'Simplified Arabic', version 5, but it does not have GPOS tables. I took it from my Windows Vista installation. A font downloaded from cooltext on the web is almost identical. Simon On Tue, Sep 21, 2010 at 11:30:41PM +0800, Glenn Adams wrote: > Attached is a sample input FO, output IF, and output PDF example showing the > functioning of complex chained contextual glyph substitution and glyph > positioning operations, now available on my working dev branch at git:// > github.com/skynavga/fop.git. > > The GDEF (glyph definition) table is now supported as well in order to > correctly process the IgnoreBase, IgnoreLigatures, IgnoreMarks lookup flags > according to font defined glyph classes. > > Regards, > Glenn -- Simon Pepping home page: http://www.leverkruid.eu
Re: Nightly snapshots
On Tue, Sep 21, 2010 at 07:46:07PM +0800, Glenn Adams wrote: > Do these snapshots include the successful running of junit tests? Or are > they merely the result of compilation without any testing? The build process includes some junit tests, viz. those that can be run successfully in a headless environment. See the ant target 'nightly-build'. The other junit tests will be included as soon as they can be run in a headless environment. I understand that the resolution of bug 42408 against Batik which you submitted, would solve that problem. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Nightly snapshots
I am pleased to inform you that every night a snapshot of Apache FOP's main development code (a.k.a. fop trunk) is built. These snapshots are aimed at users who want to try out the newest features but are not used to building Apache FOP themselves. The snapshots can be found at http://ci.apache.org/projects/xmlgraphics/fop/snapshots/. We hope that they are useful. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Nightly builds requested
The nightly builds are almost there. Simon Gavin wrote: Take a look at http://ci.apache.org/projects/xmlgraphics/fop/snapshots/ and let me know what you think, it's based on your Forrest build site but is not built by Forrest. A script generates it daily after the daily snapshots have been produced. JAI support has also been added so that should be fine, see http://ci.apache.org/builders/fop-trunk/builds/6/steps/compile/logs/stdio for results of the build. Simon wrote: That looks good. I edited the download page, and added details. It is attached. I decided to leave out the Forrest-generated documentation, as explained in the download page. On Wed, Aug 18, 2010 at 03:46:21PM +0200, Simon Pepping wrote: > This is to inform you that I requested the creation of nightly (or > perhaps weekly) builds of FOP. I think this will benefit users who > want to use a snapshot of trunk, but have problems with build > tools. Let me know if you are opposed to this. Details from JIRA: > > Simon > > Create nightly snapshot builds for download of Apache FOP > - > > Key: INFRA-2936 > URL: https://issues.apache.org/jira/browse/INFRA-2936 > Project: Infrastructure > Issue Type: Task > Security Level: public (Regular issues) > Components: Buildbot > Environment: Ant build. Sun JVM (the project uses the > sun-private JPEG codec). Forrest if we add > documentation. >Reporter: Simon Pepping -- Simon Pepping home page: http://www.leverkruid.eu
Re: gsub/gpos opentype table functions
Thanks for this explanation. I tried it with the code from your git
branch, with mixed results. Simplified Arabic is a Windows font, so I
had to get it from there. My output with this font is not as nicely
positioned as yours. I also tried other fonts on my machine with the
first arabic block (Mark to Base, first line). With some fonts I had a
nice result. With other fonts I got each of the four characters on a
separate line, with no diacritical marks. With one font, FreeSerif, I
got an exception:
java.lang.UnsupportedOperationException: unsupported device table
delta format: 0
I can send you the generated pdf file if you wish.
Is saving space in the if file important enough to devise a compressed
notation? You could also simply list the tuples in the attribute
value, e.g. dp="{ 0, 0, 0, 0 } { 5600, 1952, -6432, 0 } { 0, 0, 0, 0 }
{ 608, -9664, -6400, 0 } { 0, 0, 0, 0 }", which would make
understanding of the code to interpret it easier.
Regards, Simon
On Sun, Sep 12, 2010 at 11:42:37AM +0800, Glenn Adams wrote:
> For those following the work on complex script support, attached is a sample
> showing a combination of GSUB (glyph substitution) and GPOS (glyph position)
> table functions operating on Arabic text as produced by FOP 1.0 with complex
> script features enabled:
>
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: Nightly builds requested
I added an ant target 'nightly-build'. It removes the build directory
and the directory nightly in the top-level directory (which would be
left-overs from earlier builds), and then creates
fop-${DSTAMP}-bin.tar.gz and fop-${DSTAMP}-bin.zip. These two files
should end up in the download area for users. If possible, the file
build/fop.jar should also be copied to the download area.
Ideally the builds should be done with JAI support present in the JVM,
but that is not necessary. This build avoids any junit tests which
require an X display, and therefore can be done in a headless setup.
Simon
On Mon, Aug 30, 2010 at 09:39:09AM +0200, Simon Pepping wrote:
> A test run of a nightly build was made with ant, default target. It
> failed in the junit tests. The stdout log is here:
> http://ci.apache.org/builders/fop-trunk/builds/0/steps/compile/logs/stdio. The
> errors seem to be solely due to the headless configuration.
>
> I want the target 'dist-bin' to be run, but that will fail in the same
> way. Including the junit tests for a nightly build has the nice
> consequence that a successful build has passed the tests. Because I
> hope that nightly builds are useful for users who do not want to build
> themselves, this guarantee is useful.
>
> How can the tests be run successfully in a headless configuration?
>
> There will also not be hyphenation and JAI support, but the log file
> indicates no problems due to those features.
>
> Simon
>
> On Wed, Aug 18, 2010 at 03:46:21PM +0200, Simon Pepping wrote:
> > This is to inform you that I requested the creation of nightly (or
> > perhaps weekly) builds of FOP. I think this will benefit users who
> > want to use a snapshot of trunk, but have problems with build
> > tools. Let me know if you are opposed to this. Details from JIRA:
> >
> > Simon
> >
> > Create nightly snapshot builds for download of Apache FOP
> > -
> >
> > Key: INFRA-2936
> > URL: https://issues.apache.org/jira/browse/INFRA-2936
> > Project: Infrastructure
> > Issue Type: Task
> > Security Level: public (Regular issues)
> > Components: Buildbot
> > Environment: Ant build. Sun JVM (the project uses the
> > sun-private JPEG codec). Forrest if we add
> > documentation.
> >Reporter: Simon Pepping
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
--
Simon Pepping
home page: http://www.leverkruid.eu
offo in maven [was: Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support]
On Thu, Sep 09, 2010 at 08:07:01AM +0800, Craig Ringer wrote: > > That's how I'm dealing with the offo hyphenation files, which don't > seem to be in any convenient maven repo. I just download the jar and > push it into my local repository (~/.m2, effectively download > cache). As they don't change much I pretty much did it once and > forgot about it - the dependency is "just there" in all my builds as > and when required now. > > It all sounds like a lot of hassle - but honestly, in practice it's > not. Some learning is definitely required, but is well worth it. I'm > never, ever, ever going back to wrangling a lib/ dir full of mixed > direct and transitive dependencies from several different 3rd party > libraries again. I found offo in maven central: http://repo1.maven.org/maven2/net/sf/offo/fop-hyph/1.2/. I did not put it there. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
I think I mean something different. When XGC adds something new and FOP uses that, a new XGC jar file must be used by builds. We do that by having a new jar file in /lib, typically called xmlgraphics-commons-1.5-svn.jar (which may be updated a few times during development of the next release). How would that be handled by the maven build? Would it require the deployment of a snapshot to Maven central? And would the version number in the pom file be updated? Simon On Wed, Sep 08, 2010 at 05:13:07PM +0800, Glenn Adams wrote: > If I understand you correctly, the answer is no. The file maven/pom.xml in > the patch explicitly references revision 1.7 of the batik artifacts. So any > use of upward revisions of those artifacts would require updating the > pom.xml file to reflect use of a newer revision. > > At present, I worked around the headless problem (testWMF) by specifying > java.awt.headless as false in the pom.xml configuration for those test > suites that invoke testWMF. Of course, that also means that the this patch > will fail those tests when invoked on a truly headless platform. > > Does that answer your query? Or are you asking if I can adjust the > configuration to make automatic use of snapshot updates? > > Regards, > Glenn > > On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping wrote: > > > Does this build system require us to deploy snapshots of > > xmlgraphics-commons and batik to the maven repository, whenever we use > > snapshot versions in our lib directory? We do routinely for xgc, and > > we may need to do so for batik if the headless problem is fixed (see > > https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13). -- Simon Pepping home page: http://www.leverkruid.eu
Re: TODO tag
//TODO is unstructured. @todo fits into an existing syntax, viz. that of javadoc tags. Output in javadocs can be suppressed by '-tag todo:X'. My preference is therefore a javadoc tag, @todo. But I am not going to make a case of this. +0. Simon On Wed, Sep 08, 2010 at 12:02:29PM +0100, Vincent Hennebert wrote: > Ok, let me summarise this: > > ??? a @[asf.]todo tag marginally improves the formatting of a javadoc > comment > ??? nobody really likes the idea of using a namespaced version of todo > (@asf.todo) > ??? it is possible to tweak Checkstyle and the javadoc command to enable > the use of @todo > > That said: > ??? todo statements generally have little to do (sic) in a javadoc comment > anyway > ??? TODO keywords are easily indexable by modern IDEs > > Jeremias recommends the Felix way: using //TODO comments below the > javadoc. I???m also strongly in favour of this convention. OTOH, if I???m > correct nobody strongly feels that @todo tags are necessary. > > So I think we have a consensus: > ??? from now on we stop using @todo in favour of the Felix convention; > ??? we will progressively remove TODO statements from javadoc comments and > move them below in their own Java // comments > ??? I remove the definition of the custom tag from build.xml > > Let me know if I missed anything. -- Simon Pepping home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Does this build system require us to deploy snapshots of xmlgraphics-commons and batik to the maven repository, whenever we use snapshot versions in our lib directory? We do routinely for xgc, and we may need to do so for batik if the headless problem is fixed (see https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13). Simon On Sat, Sep 04, 2010 at 06:42:56AM -0400, bugzi...@apache.org wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881 > > --- Comment #1 from Glenn Adams 2010-09-04 06:42:53 EDT --- > Created an attachment (id=25986) > --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25986) > Patch to add maven build support. > > This patch has been verified against repository version 992575. -- Simon Pepping home page: http://www.leverkruid.eu
