Bug report for Fop [2008/07/13]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende| | 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes | | 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code | |10379|New|Enh|2002-07-01|Improvement to FOP Classloader| |12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses| |12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to | |13586|New|Blk|2002-10-13|fop will not work on linux alpha because jre is br| |13734|New|Nor|2002-10-17|Hyphenation does not work correctly on long string| |14248|New|Enh|2002-11-05|51-page FO example, could be added to the samples | |14352|New|Enh|2002-11-07|It would be nice if FOP could be plugged into popu| |14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat| |14419|New|Enh|2002-11-10|Implement SourceResolver, Image Resolver | |14529|New|Nor|2002-11-13|SVG url references do not work| |14679|New|Enh|2002-11-19|Pluggable renderers | |14924|New|Nor|2002-11-28|Table disappears when it ends when the page ends | |15020|New|Enh|2002-12-03|Reuse of fo-tree | |16017|Opn|Nor|2003-01-13|Jpeg's and the PDF Serializer | |16130|New|Nor|2003-01-15|PS-Renderer emits lots of redundant moveto's | |16156|New|Nor|2003-01-16|0.20.5rc SVG example does not work| |16713|New|Nor|2003-02-03|Hyphenation error in tables | |17369|New|Nor|2003-02-25|Footnote duplication | |17380|New|Nor|2003-02-25|Batik Component will not recognize fe SVG elem| |17921|New|Nor|2003-03-12|Kerning is broken for standard fonts | |18292|New|Nor|2003-03-24|24 bit PNG not displayed correctly| |18801|New|Nor|2003-04-08|visibility property is not implemented | |19228|New|Blk|2003-04-22|[PATCH] Child LayoutContext is null in certain cir| |19341|Ver|Nor|2003-04-26|leader doesn't work since 0.20.5.rc2 | |19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl| |19717|New|Enh|2003-05-07|Lets add support for JimiClassesPro.zip to build.x| |19769|Ass|Enh|2003-05-08|Indefinite page size is not implemented | |20280|Ass|Enh|2003-05-27|text-align and text-align-last only partially impl| |20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur| |20827|New|Enh|2003-06-17|Derive other font styles and weights from normal T| |21265|Opn|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo| |21905|New|Nor|2003-07-26|large list-item-label bleeds into following block | |21982|New|Maj|2003-07-30|NullPointer Exception in LazyFont with embedded fo| |22450|New|Maj|2003-08-15|Unterminated iteration in JPEGReader class| |22627|Opn|Nor|2003-08-21|Update mirror/download page HEADER README (was [| |24148|New|Nor|2003-10-27|Kerning upsets text-align=end |
java.nio.CharBuffer
I noticed that Andreas used CharBuffer in his initial patch for #45390. I was curious about the performance implications, so I wrote a little micro-benchmark. The results: Sun Java 1.4.2_16: StringBuffer def: 6594 ms StringBuffer 1024: 6609 ms CharBuffer: 5250 ms Sun Java 1.5.0_14: StringBuffer def: 5375 ms StringBuffer 1024: 5375 ms CharBuffer: 5594 ms Sun Java 6.0_03: StringBuffer def: 2750 ms StringBuffer 1024: 2750 ms CharBuffer: 4719 ms Apache Harmony r618795: StringBuffer def: 4687 ms StringBuffer 1024: 4672 ms CharBuffer: 7766 ms So this is a single-threaded test. It might perform differently in a heavy multi-threading environment. Anyway, it looks it doesn't make much sense to use the CharBuffer instead of the more familiar StringBuffer for simple string concatenation. I'm sure there's a benefit in using CharBuffer in scenarios where nio can really show its muscles. Jeremias Maerki CharBufferSpeedTest.java Description: Binary data
Re: Barcode fonts not displaying correctly when generating PCL
Chris Bowditch wrote:
snip/
I understand that is what happens behind the scenes, but IMO it is
meaningless to the average user. I think it makes sense to change the
message to:
table too wide for available page width
or similar. Then the user knows what they have to adjust in their FO.
Rather than just moaning about a poor message I decided to fix it. I've
made a change locally, but I'm not 100% certain about the exact wording.
I've currently got:
{elementName} {{locator}} overflows available space in
inline-progression-dimension
I'm not 100% certain if this message always applies to IPD. I would
appreciate it if one of the other devs could confirm?
Thanks,
Chris
Re: Building FOP Trunk with Any - BUILD FAILED
I will test this out later today on my home PC. I get a different set of errors on different machines. In the mean time I ran a new svn check out (as you suggested) on my work PC and got the same original error message e.g. BUILD FAILED C:\foptrunk2\trunk\build.xml:353: java.io.IOException: java.io.FileNotFoundExcep tion: file:\C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xm l (The filename, directory name, or volume label syntax is incorrect) So its seems I have two different problems. I thought I might be doing something fundamentally wrong, but I was able to build FOP 0.94. As Jeremias suggested, I will try to download the trunk again from my home PC. I don't want to confuse the error reports from one machine to another as they appear to be different. Regards, Phil Jeremias Maerki-2 wrote: That's the exception I worked around in http://svn.apache.org/viewvc?rev=676307view=rev It shouldn't occur anymore in the latest FOP Trunk when Saxon is active. Did you only update EventProducerCollectorTask.java? Please update all of your working copy and please make sure it's a proper SVN checkout like I mentioned in one of my latest off-list mails. What happens if you do a new checkout and run that (starting from a green field)? - svn co https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/ - ant (Just for everyone's information: Phil sent me some log files and in one there was XHTML code in a Java file that contained the string viewvc so I told him I suspect that he's not working off a proper SVN working copy.) On 14.07.2008 00:59:05 bonekrusher wrote: Sure call me Phil :) I ran the svn update on the EventProducerCollectorTask.java file. Here is the stack after running ant: BUILD FAILED java.lang.NullPointerException at net.sf.saxon.event.ReceivingContentHandler.getNameCode(ReceivingConte ntHandler.java:404) at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingCont entHandler.java:277) at org.apache.fop.events.model.EventModel.toSAX(EventModel.java:96) at org.apache.fop.events.model.EventModel.writeXMLizable(EventModel.java :116) at org.apache.fop.events.model.EventModel.saveToXML(EventModel.java:133) at org.apache.fop.tools.EventProducerCollector.saveModelToXML(EventProdu cerCollector.java:202) at org.apache.fop.tools.EventProducerCollectorTask.execute(EventProducer CollectorTask.java:70) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExe cutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.Main.runBuild(Main.java:758) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) Andreas Delmelle-2 wrote: On Jul 13, 2008, at 19:34, bonekrusher wrote: Hi Bones (or can we just call you Phil ;-)) No spaces. Both trunk and Ant are as follows: c:\ant c:\fop_trunk I've just committed a small change to EventProducerCollectorTask.java that /might/ help... (?) Can you try to update your sandbox, run a clean build and report back on whether that changed anything? Thanks Andreas -- View this message in context: http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p18434967.html Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki -- View this message in context: http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p18442235.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Barcode fonts not displaying correctly when generating PCL
On 14.07.2008 11:20:09 Chris Bowditch wrote:
Chris Bowditch wrote:
snip/
I understand that is what happens behind the scenes, but IMO it is
meaningless to the average user. I think it makes sense to change the
message to:
table too wide for available page width
or similar. Then the user knows what they have to adjust in their FO.
Rather than just moaning about a poor message I decided to fix it. I've
made a change locally, but I'm not 100% certain about the exact wording.
I've currently got:
{elementName} {{locator}} overflows available space in
inline-progression-dimension
How about:
An fo:table is wider than the available room in
inline-progression-dimension. Adjusting end-indent based on
overconstrained geometry rules (XSL 1.1, ch. 5.3.4)
I'd like to have the hint about overconstrained geometry in there
because this condition is not strictly an overflow. It's just a
conflict of values which is resolved based on rules in the spec. It's
also just a warning, not an error.
I'm not 100% certain if this message always applies to IPD. I would
appreciate it if one of the other devs could confirm?
It's always about IPD, yes.
Thanks,
Chris
Jeremias Maerki
Re: Building FOP Trunk with Any - BUILD FAILED
bonekrusher wrote:
I will test this out later today on my home PC. I get a different set of
errors on different machines.
In the mean time I ran a new svn check out (as you suggested) on my work PC
and got the same original error message e.g.
BUILD FAILED
C:\foptrunk2\trunk\build.xml:353: java.io.IOException:
java.io.FileNotFoundExcep
tion:
file:\C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xm
l (The filename, directory name, or volume label syntax is incorrect)
So its seems I have two different problems. I thought I might be doing
something fundamentally wrong, but I was able to build FOP 0.94.
As Jeremias suggested, I will try to download the trunk again from my home
PC. I don't want to confuse the error reports from one machine to another
as they appear to be different.
Well, it's incorrect URL syntax. Presumably
${build.gensrc.dir}/org/apache/fop/events/event-model.xml
(see line 353) is being passed in as a file path, not a URL.
Put
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
In any case, it seems to be getting converted into a badly formed file:
URL within the ant task.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
Re: Barcode fonts not displaying correctly when generating PCL
Jeremias Maerki wrote: snip/ How about: An fo:table is wider than the available room in inline-progression-dimension. Adjusting end-indent based on overconstrained geometry rules (XSL 1.1, ch. 5.3.4) I'd like to have the hint about overconstrained geometry in there because this condition is not strictly an overflow. It's just a conflict of values which is resolved based on rules in the spec. It's also just a warning, not an error. Agreed. Thanks for the clarification. I'm not 100% certain if this message always applies to IPD. I would appreciate it if one of the other devs could confirm? It's always about IPD, yes. New english message now committed. No idea what the german version should be though :) Thanks, Chris
Re: java.nio.CharBuffer
On Jul 14, 2008, at 08:44, Jeremias Maerki wrote: I noticed that Andreas used CharBuffer in his initial patch for #45390. I was curious about the performance implications, so I wrote a little micro-benchmark. The results: snip / So this is a single-threaded test. It might perform differently in a heavy multi-threading environment. Anyway, it looks it doesn't make much sense to use the CharBuffer instead of the more familiar StringBuffer for simple string concatenation. I'm sure there's a benefit in using CharBuffer in scenarios where nio can really show its muscles. Yeah, it was OK for FOText, I think, but for the smaller portions, it's probably more overkill... I'll look into replacing what's unnecessary. nio.CharBuffer is very suitable if there's a lot of bulk get() and put () (like when removing leading white-space characters) While implementing it in FOText, I noticed that if you use CharBuffer.wrap(), you actually don't even create a new char array. You get a CharBuffer instance that is literally wrapped around a portion of the parameter char array). Unfortunately, this caused issues when I started shifting characters due to white-space-removal (as the char array was the very same one that the parser was using to store the chars from the source XML) I did a small test myself, before committing the changes, but that was more focused on CharSequence.charAt() and the difference in timing with simple index-based array fetches (for TextLayoutManager). In that case, the difference was really negligeable, even for millions of calls/fetches, I only got a few milliseconds difference in total. Cheers Andreas
Re: Building FOP Trunk with Any - BUILD FAILED
Peter,
Which file is this?
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
Phil
Peter B. West wrote:
bonekrusher wrote:
I will test this out later today on my home PC. I get a different set of
errors on different machines.
In the mean time I ran a new svn check out (as you suggested) on my work
PC
and got the same original error message e.g.
BUILD FAILED
C:\foptrunk2\trunk\build.xml:353: java.io.IOException:
java.io.FileNotFoundExcep
tion:
file:\C:\foptrunk2\trunk\build\gensrc\org\apache\fop\events\event-model.xm
l (The filename, directory name, or volume label syntax is incorrect)
So its seems I have two different problems. I thought I might be doing
something fundamentally wrong, but I was able to build FOP 0.94.
As Jeremias suggested, I will try to download the trunk again from my
home
PC. I don't want to confuse the error reports from one machine to
another
as they appear to be different.
Well, it's incorrect URL syntax. Presumably
${build.gensrc.dir}/org/apache/fop/events/event-model.xml
(see line 353) is being passed in as a file path, not a URL.
Put
echobasedir ${basedir} build.gensrc.dir ${build.gensrc.dir}/echo
immediately in front of line 352 to verify. It could be a mixed forward
and backslashed path.
In any case, it seems to be getting converted into a badly formed file:
URL within the ant task.
--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/
--
View this message in context:
http://www.nabble.com/Building-FOP-Trunk-with-Ant---BUILD-FAILED-tp18359419p18448657.html
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: java.nio.CharBuffer
On Jul 14, 2008, at 18:15, Andreas Delmelle wrote:
snip /
Just quickly ran Jeremias' test-app myself, and on Apple JVM (1.5),
the difference is +/-300ms for a million iterations, but not very
consistent. Sometimes StringBuffer operates slightly faster, other
times it's CharBuffer that wins. I guess the backing implementations
are very closely related anyway, so it's not all that surprising.
It would most definitely be a huge overkill if it is /only/ used for
simple String concatenation. In the context of catching SAX characters
() events, I think the penalty is bound to be limited (maybe even on
the contrary: see below). That is, I don't think I've ever seen a
parser that reports characters one at a time (which would make the
current implementation using CharBuffer very slow). Most SAX parsers
report the characters in reasonably large chunks (as much as possible).
Just for fun, make it:
...
private static final char[] prefix = {' ', 'm', 'y', 'V', 'a', 'l',
'u', 'e', '='};
...
public String runCharBuffer() {
CharBuffer buf = CharBuffer.allocate(1024);
for (int i = 0; i STEPS; i++) {
buf.put(prefix).put(Integer.toString(i).toCharArray());
}
return buf.rewind().toString();
}
...
On my end, this runs noticeably faster than when passing Strings
(almost 20%). When switching StringBuffer.append() to use char[]
parameters, it runs a tiny bit slower than with Strings... No idea if
this also holds for the Sun, IBM or Apache implementations.
Qua flexibility, the API for a CharBuffer (optionally) offers the
possibility to get a reference to the backing array. For
StringBuffer, we'd have to do something like: sb.toString
().toCharArray(), and IIC, this always yields an independent copy of
the StringBuffer's array, not the array itself. (Note that this
obviously also has its drawbacks; sometimes, you just /need/ an
independent copy...)
Cheers
Andreas
