Re: SIGSEGV when running Fop
That's a problem with the JVM not FOP. Java should not core dump in any case. That version of Linux SDK is known to be buggy. It seems that 1.3.0 is ok or any of the blackdown versions (www.blackdown.org). Cheers, Carlos [EMAIL PROTECTED] wrote: Hi, I use Fop-0.20.1. Java SUN SDK-1.3.1 on Linux and always got a SIGSEGV when running 'java org.apache.fop.apps.Fop infile.fo outfile.pdf. I'm not too stron in Java, but it seems to me strnge to get SIGSEGV when running Java app. Does anybody know the solution? Thanks Libor Sakmary [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Performance
As Keiron said that performance increased with just using HashMap instead of Hashtable. How about using ArrayList instead of Vector? Well, it depends on how much Vector is used in FOP. Another thought is the way the FO tree and area trees are implemented. There will be probably some changes with the redesign. However, the approach taken by Xalan may also be useful in FOP. In Xalan 2, the DOM has been replaced by DTM (Document Table Model) which uses tables of integers to represent the document, reducing all comparisons (of node names, etc.) to integer comparisons. Of course, Xalan benefits mostly with the faster XPath axis iterators of this implementation which are not relevant to FOP. Nevetherless, if not performance, DTM or the appropiate for FOP offers a lot of savings on memory usage. Just a few thoughts, it may trigger some ideas. Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] Page citations do not work in PSRenderer
Last time I look at the code, I noticed that resolution of page references is left to the renderers. Shouldn't that be handled by the layout process. Shouldn't the job of the renderers just convert the resolved area tree to whatever format their target is? Is this being thought of in the new layout redesign? Carlos COFFMAN Steven wrote: Done. Are other renderers similarly broken? (PCL?) I don't have a way to check. -Steve -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 1:35 PM To: [EMAIL PROTECTED] Subject: [PATCH] Page citations do not work in PSRenderer Hi Darren There is one problem, page-citations don't seem to work. The line fo:page-number-citation ref-id=xref/ should put the page number of the page on which a block with the attribute id=xref first appears. In the output from FOP -ps I get a ? instead. Ok, I fixed that. A diff is attached. Would one of the committers please apply it? Thanks. Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - 6002 Luzern Fon +41 (0)41 317 2020 - Fax +41 (0)41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Chinese characters line-breaking
Frank Chen wrote: Hi: I found the line-breaking in FOP is based upon spaces between English words. But this is not major way for Chinese characters' line-breaking. Please see elcosed files:big5test.fo and big5test.pdf to see what happens. Is there any implementation-specific way in FOP to modify this? Or can you add support to Chinese rendering? You need to set the language property to chinese (i.e. language=zh), you can add it as an attribute to fo:root or to each fo you want to format. Currently FOP checks if the language is ja, zh, ko or vi. If so it will break in the middle of words (western concept of words). Notice that this is not a complete solution to CJK line-breaking but it's better not breaking at all, like in your sample. A more sophisticated algorithm will try to keep together open punctuation marks with the next character or closing marks with the previous character, so you won't get a period or comma at the beginning of a line. This is usually done with kinsoku tables (I think that's the japanese term), that basically lists punctuation marks, whether they're open or close type and some priority or penalty. I think that's the way TeX does it. Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: XMLRenderer
Keiron Liddle wrote: The only xml diff utility I know of is the IBM one, which we can't use (not allowed to distribute). There's a free one (with source code), albeit it's not as good as IBM's. The diff generated is sometimes far less than optimum but it claims to be correct. It used to be available at http://www.cs.ucl.ac.uk/staff/c.nentwich/treediff/ but I tried to access it a while ago and the site doesn't respond. If you can't get it, let me know and I send you a copy, I think I still have it. It may work for our purposes. Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: logging
Keiron Liddle wrote:
On Thu, 02 Aug 2001 17:45:56 Carlos Villegas wrote:
I think it's possible to do in FOP what was done in Velocity. They have
a middleware that decouples Velocity from the specific logging toolkit.
So they have drivers for logkit and log4j and you can even write your
own one. This is a better choice when embedding FOP since you'd want to
use whatever logging system you've already have in place. I think it's
worth taking a look at the Velocity log package, we might be able to
reuse it.
That would work, but I have a few problems with it.
- We would need to copy their code (and hence create two diverging
versions) because it has dependancies
- It adds an extra 3 layers to every log call, also has extra logic
- a logging system should do all of the targetting things itself (instead
of having an interface with multiple targets to an interface with multiple
targets that writes the logging)
- I want to avoid having extra code that only adds complexity
Well, it was just an idea. I don't think it's that much extra code
anyway, or that extra code necessarily adds complexity. My post was
motivated from my experience with Velocity. We're using Velocity in a
servlet environment. Our system already had its own logging system.
Velocity as shipped, logs to its own file, but we wanted to use our same
configuration file to configure Velocity logging as well and to merge
logs onto a single destination. It was very easy, all you you to do is
implement a very simple interface, basically:
interface VelocityLog {
void debug(String message);
void info(String message);
void error(String message);
...
}
and set a property in Velocity to point to your logging implementation
class.
Yes, it adds an extra layer and notice that some nice features of
systems like log4j are not used, like categories. It all depends of
course on your needs. Velocity is intended primarily to be embedded, so
you'd want that flexibility.
Nevertheless, I don't neccessarily think it's the best choice for FOP.
This is also related to a recent post about FOP APIs, there were some
complains about how inflexible FOP is when trying to embed it.
Carlos
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: logging
Keiron Liddle wrote: So between logkit and log4j I think logkit is the better option simply because cocoon uses it. (that's the only thing that tips the balance, I'd rather just choose than not go anywhere.) I think it's possible to do in FOP what was done in Velocity. They have a middleware that decouples Velocity from the specific logging toolkit. So they have drivers for logkit and log4j and you can even write your own one. This is a better choice when embedding FOP since you'd want to use whatever logging system you've already have in place. I think it's worth taking a look at the Velocity log package, we might be able to reuse it. Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
