Generating javadocs for fop ant task
I am having trouble automating an error free build of the javadocs
target in our build.xml. The problem is that I am using a RPM install
for ant (obviously I am talking Linux here). This places the ant.jar
file not into ${ant.home}/lib but into /usr/share/java. This means the
pathelement location=${env.ANT_HOME}/lib/ant.jar/ line in build.xml
will not find the ant.jar file.
Obviously ant.jar will be in the classpath as we are running ant at the
time. Any ideas how to get the ant.jar location from the ant invocation
classpath into the pathelement above?
Thanks
Manuel
Re: Generating javadocs for fop ant task
On Thu, 27 Oct 2005 03:03 pm, Mark C. Allman wrote:
Since you're using Linux, try a symbolic link (ln -s
/usr/share/java/ant.jar $ANT_HOME/lib/ant.jar )?
Mark, yes sure but that's not quite what I am after. The problem I want
to solve is to have a build.xml such that when users download the FOP
source distribution it will build without errors. To achieve that
build.xml must be able to find out where ant.jar lives for the javadocs
target. The current setup is broken for users who have ant installed
via RPM.
Manuel
-- Mark C. Allman
-- Allman Professional Consulting, Inc.
-- www.allmanpc.com http://www.allmanpc.com , 617-947-4263
BusinessMsg -- the secure, managed, 100% J2EE Enterprise IM plug-in
solution.
On Thu, 2005-10-27 at 18:46 +0800, Manuel Mall wrote:
I am having trouble automating an error free build of the javadocs
target in our build.xml. The problem is that I am using a RPM install
for ant (obviously I am talking Linux here). This places the ant.jar
file not into ${ant.home}/lib but into /usr/share/java. This means
the
pathelement location=${env.ANT_HOME}/lib/ant.jar/ line in
build.xml
will not find the ant.jar file.
Obviously ant.jar will be in the classpath as we are running ant at
the
time. Any ideas how to get the ant.jar location from the ant
invocation
classpath into the pathelement above?
Thanks
Manuel
Re: Generating javadocs for fop ant task
As I typed my last e-mail, I suspected that wasn't what you were looking for (it's trivial!).
Have you tried just adding the classpath as a pathelement instead of explicitly setting individual jars? I.e.,
pathelement path=${env.CLASSPATH} /
instead of
pathelement location=${env.ANT_HOME}/lib/ant.jar /
-- Mark C. Allman
-- Allman Professional Consulting, Inc.
-- www.allmanpc.com, 617-947-4263
BusinessMsg -- the secure, managed, 100% J2EE Enterprise IM plug-in solution.
On Thu, 2005-10-27 at 19:21 +0800, Manuel Mall wrote:
On Thu, 27 Oct 2005 03:03 pm, Mark C. Allman wrote:
Since you're using Linux, try a symbolic link (ln -s
/usr/share/java/ant.jar $ANT_HOME/lib/ant.jar )?
Mark, yes sure but that's not quite what I am after. The problem I want
to solve is to have a build.xml such that when users download the FOP
source distribution it will build without errors. To achieve that
build.xml must be able to find out where ant.jar lives for the javadocs
target. The current setup is broken for users who have ant installed
via RPM.
Manuel
-- Mark C. Allman
-- Allman Professional Consulting, Inc.
-- www.allmanpc.com http://www.allmanpc.com , 617-947-4263
BusinessMsg -- the secure, managed, 100% J2EE Enterprise IM plug-in
solution.
On Thu, 2005-10-27 at 18:46 +0800, Manuel Mall wrote:
I am having trouble automating an error free build of the javadocs
target in our build.xml. The problem is that I am using a RPM install
for ant (obviously I am talking Linux here). This places the ant.jar
file not into ${ant.home}/lib but into /usr/share/java. This means
the
pathelement location=${env.ANT_HOME}/lib/ant.jar/ line in
build.xml
will not find the ant.jar file.
Obviously ant.jar will be in the classpath as we are running ant at
the
time. Any ideas how to get the ant.jar location from the ant
invocation
classpath into the pathelement above?
Thanks
Manuel
signature.asc
Description: This is a digitally signed message part
DO NOT REPLY [Bug 36403] - table with cells padded with different widths cause ArrayIndexOutOfBounds exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36403.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36403
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2005-10-27 15:21 ---
(In reply to comment #2)
Attempting to shed some light on what's happening:
From the debug output, we can derive that TableStepper.getNextStep() has set
the variable
rowBacktrackForLastStep to true (line 513), which in turn leads to
TableStepper.getCombinedKnuthElementsForRowGroup() to decrease the activeRow
index (line 249).
Any subsequent call to TableStepper.getActiveRow() will result in an
AIOOBException.
Still looking for the exact reason why the backtrack-switch is flipped to
true. Jeremias is probably the
only one among us who knows what 'Mep!' means ;-)
Hehe. Actually, it should have been Meeep, meeep! because Roadrunner always
does a double mp! :-) I've replace the comment with a more verbose debug
message and added a few comments in an attempt to shed a little more light on
this.
I'm thinking: either the backtracking itself is out-of-place and shouldn't
happen, or the case where the
active row is the first one should be checked for.
FWIW: simply surrounding TableStepper line 513 with if (activeRow 0) { ...
} seems to resolve the
issue, but whether it suffices (i.e. is more than a quick dirty hack), that
I'm not sure about.
You were almost on course. There's an additional aspect here. This case should
actually cause that particular step to be skipped, because borders and padding
allocate more room than the actual step is long which would result in a conflict
situation. I solved this by forcing an INFINITE penalty after the skipped step.
I left a big error sign in there in case a break-before might ruin the fun
there. I'm not sure yet if that's possible at all and what would happen.
Analysis test case on the Wiki documenting a row backtrack situation:
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder2
Hand-written notes with details on the situation (not very verbose, I'm afraid):
http://people.apache.org/~jeremias/fop/NextStepAlgoNotes.pdf
Test case to check this case here:
table_bug36403.xml
(I could actually simplify the case documented in this bug here.)
SVN Revision of the fix:
http://svn.apache.org/viewcvs?rev=328868view=rev
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
fop.sh vs fop
While looking at building the fop distribution I noticed that the Ant project has switched (don't know when) from having ant.sh (for *nixes) and ant.bat (for Win) to ant (for *nixes) and ant.bat. This means the command to invoke the program is the same on Unix and Windows. Personally I like that change (never favored typing command.sh instead of just command) and suggest we make the same change for FOP. Also makes documentation simpler as the command line invocation is the same everywhere. +1 from me Manuel
DO NOT REPLY [Bug 37270] New: - IndexOutOfBoundsException due to absent table-cells
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37270 Summary: IndexOutOfBoundsException due to absent table-cells Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The following example posted someone on fop-users causes an IndexOutOfBoundsException in EffRow.getGridUnit (FOP Trunk): http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200510.mbox/browser -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: fop.sh vs fop
+0.5 as I'm not on Unix but if it makes people's life easier like this On 27.10.2005 15:58:45 Manuel Mall wrote: While looking at building the fop distribution I noticed that the Ant project has switched (don't know when) from having ant.sh (for *nixes) and ant.bat (for Win) to ant (for *nixes) and ant.bat. This means the command to invoke the program is the same on Unix and Windows. Personally I like that change (never favored typing command.sh instead of just command) and suggest we make the same change for FOP. Also makes documentation simpler as the command line invocation is the same everywhere. +1 from me Manuel Jeremias Maerki
DO NOT REPLY [Bug 37270] - IndexOutOfBoundsException due to absent table-cells
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37270 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-10-27 16:11 --- Test case added: http://svn.apache.org/viewcvs?rev=328880view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: svn commit: r328381 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/inline/ layoutmgr/inline/ render/ render/pdf/ render/xml/
I wrote: Manuel Mall wrote: There is no need to expose creation of the Space/Word areas directly to TextLayoutManager either. TextArea could easily expose an addWord and an addSpace method instead of the monolithic setText. In the end it probably boils down to me arguing that the setText logic currently in TextArea IMO should be in TextLayoutManager (and probably based on its data structures) because it is an operation closely coupled to layout and not to areas. Ok. Done: http://svn.apache.org/viewcvs.cgi?view=revrev=328882 I added a boolean attribute in SpaceArea that is true for adjustable spaces (at the moment it is not used, but I will fix it soon). At the moment the offset in SpaceArea and WordArea are unused, but this is how I think they could be used: if, because of the rounding in the adjustment computation, the applied adjustment is different than the needed one, the TextLM should distribute this difference (a few millipoints) among the SpaceAreas and / or WordAreas, setting their offset. The renderers will use this according to their own adjustment rule: for example the PDFRenderer would add it to the text adjustment if the character is multibyte. The offset could come in handy for the cjk support (bug 36977): in this case there are no adjustable spaces, and if text is justified all the difference between line width and unadjusted character width could be handled modifying the offsets of some special characters. Regards Luca
Re: fop.sh vs fop
On Oct 27, 2005, at 6:58 AM, Manuel Mall wrote: While looking at building the fop distribution I noticed that the Ant project has switched (don't know when) from having ant.sh (for *nixes) and ant.bat (for Win) to ant (for *nixes) and ant.bat. This means the command to invoke the program is the same on Unix and Windows. Personally I like that change (never favored typing command.sh instead of just command) and suggest we make the same change for FOP. Also makes documentation simpler as the command line invocation is the same everywhere. +1 from me Manuel +1 Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Position and order of pendingaftermarks
Jeremias, In the SpaceResolver constructor the pendingaftermarks are added to the start of first: first.addAll(0, breakPoss.getPendingAfterMarks()); I think they should be added to the end. Also I think the order of the pendingaftermarks in BreakElement is wrong, or they should be added to first in reverse order. This is a test case: fo:block space-after=10pt space-before=10pt background-color=#55 fo:block space-after=7pt space-before=7pt background-color=#55 fo:block space-after=5pt background-color=#656565 Some text. /fo:block fo:block space-before=4pt background-color=#757575 Some text. /fo:block /fo:block /fo:block Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Position and order of pendingaftermarks
Would you mind handling this yourself? Adding the test case, adding checks and possibly fixing the bug? I'm away tomorrow and the whole of next week and I'm only just cleaning up my stuff before I go to bed. I don't know how much time I'll have during the weekend to look into this. Thanks! On 27.10.2005 21:22:12 Simon Pepping wrote: Jeremias, In the SpaceResolver constructor the pendingaftermarks are added to the start of first: first.addAll(0, breakPoss.getPendingAfterMarks()); I think they should be added to the end. Also I think the order of the pendingaftermarks in BreakElement is wrong, or they should be added to first in reverse order. This is a test case: fo:block space-after=10pt space-before=10pt background-color=#55 fo:block space-after=7pt space-before=7pt background-color=#55 fo:block space-after=5pt background-color=#656565 Some text. /fo:block fo:block space-before=4pt background-color=#757575 Some text. /fo:block /fo:block /fo:block Jeremias Maerki
