Re: java.nio.CharBuffer
On Jul 14, 2008, at 18:15, Andreas Delmelle wrote:
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
Re: Building FOP Trunk with Any - BUILD FAILED
Peter,
Which file is this?
basedir ${basedir} build.gensrc.dir ${build.gensrc.dir}
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
> basedir ${basedir} build.gensrc.dir ${build.gensrc.dir}
> 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
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: 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: Barcode fonts not displaying correctly when generating PCL
Jeremias Maerki wrote: 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: 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
basedir ${basedir} build.gensrc.dir ${build.gensrc.dir}
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
Re: Barcode fonts not displaying correctly when generating PCL
On 14.07.2008 11:20:09 Chris Bowditch wrote:
> Chris Bowditch wrote:
>
>
>
> > 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
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=676307&view=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
Chris Bowditch wrote:
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
