Re: Big success; structural questions

2001-07-18 Thread Keiron Liddle


(where to start?)

Currently the svg rendering uses more memory than it should, all the
rendering data is written into a StringWriter.

--

I think in terms of the structure of FOP:
- changing the pdf generation would be a good thing, ie. adding streaming
support and linearized support (good for downloading (not generating))
would be useful.

- The separation of the object parsing/formatting/rendering is about the
data. I don't see a problem with a high level of control of when particular
parts of this flow occur as long as each page is valid and rendered
correctly. Also it should not get in the way of further development towards
full implementation of the FO spec or operation of the renderers.
The FOTreeBuilder is probably not the right place.

I guess we need to know details first.

--

There are tests but they do not test the pdf output (a bit too difficult)
only the xml area tree.

On Tue, 17 Jul 2001 16:19:46 Mark wrote:
 Hi again,
 
 Firstly I have successfully tested my changes with a ~20,000 page
 document of moderate complexity, it is in fact one of the example
 documents but I forget which one (doh) - multiplied by some silly factor
 like 5000 or something. I have also successfully tested my changes
 against a 120-odd page version of 'docs/examples/svg/embedding.fo' -
 that three page file x forty-something. I would try it on a bigger file
 but I need to sleep instead; I'll set one of my machines going on a
 really big file tomorrow just to see where the limits are. I haven't
 looked at the heap size growth yet but I expect a very small linear
 growth since the PDF still has to maintain a list of references for each
 page. Still, that's quite tiny and probably can be optimized
 significantly if it becomes a problem.
 
 I have some questions regarding the structure of FOP and how my changes
 might be integrated into the main tree, assuming of course that they are
 desired and the PDF page parent issue can be sorted out.
 
 Firstly it could be argued that I have violated one of the secondary
 design principals of FOP, namely that the separation between
 parsing/formatting/rendering has suffered a warp core breach. In fact I
 think I have managed to keep the separation pretty clear, but at some
 point control has to move from the parser to the formatter/renderer and
 this is no longer done by the caller. By this I mean that the thread
 running SAX is now running the formatting and rendering. Does anything
 see this as a huge problem? (What is the plan for FOP 0.20 anyway?)
 
 At the moment I am doing this in a horrid hack in FOTreeBuilder because
 that's just the most obvious place to find where the fo:page-sequence
 element ends. I also initialize and close the renderer in FOTreeBuilder
 using some new methods I had to add (PDF specific atm). I am not certain
 that FOTreeBuilder is the right place for this code, but it might be.
 Any suggestions? I like the idea of a bridging class actually;
 ParserRenderer or something, that FOTreeBuilder uses.
 
 Secondly, because of the change in the rendering sequence I am afraid
 that other renderers might not work any more, especially not the AWT
 renderer. I was wondering if anyone would like to help me with these
 other renderers? The changes are fairly straightforward. I am happy to
 work on the AWT renderer and can probably work out the PCL renderer, but
 if my code might be accepted into the tree then it would probably be
 beneficial if someone else knew broadly what I've been up to. I don't
 have any PCL devices handy so I would have some difficulty testing any
 changes I make. And I'm not even sure what MIF is, some sort of
 interchange format .. ?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Code Style, was Re: PDF serialization

2001-07-18 Thread Tore Engvig



On Tue, 17 Jul 2001, Arved Sandstrom wrote:

 Hi, Tore

 Well, how about _you_ set the day, since you're the volunteer? :-)

Sure. Monday the 23rd evening (GMT) is codeformatting day unless somebody
protests.

Everyone who have some uncomitted code should commit it by then as the
diffs in your local copy after the codeformat will mismatch and cvs will
scream conflict.

I will tag the repository before beautifying the code (eg PRE_CODEFORMAT)
and also take a look at the long-form/short-form license.


Tore


 I tend to agree with your comments about cvswrappers, and you're right, why
 not try the logical first approach, which is that all committers make a
 point of running the code beautifier of their choice before making commits?
 We have not in a long time, if ever, put our foot down and said that this is
 the way it will be - it's been pretty lackadaisical so far. So, once you
 have reformatted everything, and recommitted, all committers would be on
 notice to adhere to code conventions.

 It would be useful if you can work in license long-form - short-form
 translation also.

 A tag is a good idea, I agree. Who knows what might happen?

 Thanks in advance for doing this.

 Regards,
 Arved

 Fairly Senior Software Type
 e-plicity (http://www.e-plicity.com)
 Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Can FOP work with other parsers and processors?

2001-07-18 Thread adel ben

Hi all,

I have tested FOP with the xerces parser and xalan processor and it works
correctly.
However, in the documentation I noticed that it would work correctly with
other parsers and processors. can anyone tell me which are parsers and
processors?

with regards,
adel





___
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




set request properties for URLConnections

2001-07-18 Thread Heiko Barthel

i wanna set request properties when retrieving for example an image with
fo:external-graphic. I need it for setting cookies or authorization header (if
image is located on a server where authorization is needed):
  ...
  URLConnection uc = url.openConnection();
  uc.setRequestProperty(Cookie,cookie);
  uc.setRequestProperty(Authorization, Basic  + encoding);
  ...

I'm new to FOP development. Does anybody know if it is a feature commonly
wanted because I found that it is not implemented yet:



FopImageFactory.java:

public static FopImage Make(String href)
throws MalformedURLException, FopImageException {

// Get the absolute URL
URL absoluteURL = null;
InputStream imgIS = null;
try {
absoluteURL = new URL(href);
imgIS = absoluteURL.openStream();
} catch (Exception e) {

=

Here some code has to be implemented to set the request properties and a way
has to be found to set name and value of the properties via Driver object I
would suggest.
Any comments are welcome.

Heiko

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

GMX Tipp:

Machen Sie Ihr Hobby zu Geld bei unserem Partner 11!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




external-graphic - problem using relative path

2001-07-18 Thread Micheál Healy



Hi all,

I posted a message regarding this problem a couple 
of weeks ago, but received no reply. 

I need to reference images ("external-graphic") in 
my xsl. It seems to work fine when I use the absolute path, but not when I 
use the relative path. Please find attached my original message - it's a 
little more detail and contains some sample XSL.

Any help on this would be greatly 
appreciated.

TIA,

Micheál

Micheál HealyEngitech Ltd.[EMAIL PROTECTED]




Hi all,

I'm using Xalan to create my .fo files from XML and 
XSL, then rendering pdf's using fop (v.0.19). I'm using JDK 1.3. 
This is all within a servlet. I'm using Apache and Tomcat together as web 
server and servlet engine. My problem is when I try to include 
'external-graphics'. I want to be able to get the graphics using a 
relative path over the web server. Problem is, when I put the path "http://localhost/VincentSite/img/checkbox.gif", 
it works, but "/VincentSite/img/checkbox.gif" doesn't. The strange thing 
is, I use a dictionary aswell, and I can find that using either 
"/VincentSite/xml/Dictionary.xml", or "http://localhost/VincentSite/xml/Dictionary.xml", 
so I know I'm using the correct path. Also, this happens within a larger 
application which uses relative paths everywhere in the XSL to get images, and 
has no problems.

I've looked elsewhere for a solution to this, and 
can't seem to find one, so any help would be much appreciated.

TIA

Micheál


Micheál HealyEngitech Ltd.[EMAIL PROTECTED]

  
xsl:choosexsl:when 
test="PersonalData/Checked='Y'"fo:table-cellfo:block 
font-size="9pt" line-height="13pt" 
text-align="start"fo:external-graphic 
src="/VincentSite/img/chkbxgif-y.gif"//fo:block/fo:table-cell/xsl:whenxsl:otherwisefo:table-cellfo:block 
font-size="9pt" line-height="13pt" 
text-align="start"fo:external-graphic 
src="/VincentSite/img/chkbxgif.gif"//fo:block/fo:table-cell/xsl:otherwise/xsl:choose


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


FOP in a servlet under load

2001-07-18 Thread Weiqi Gao

We did some playing around with a simple FOP servlet that does
XHTML-XSL-FO-PDF using Xalan and FOP and come away with the following
findings:

1. It uses quite a bit of memory.  While running around 20-30 concurrent
users, each generating a set of four PDFs ranging from 2 to 5 pages five
times each, the servlet engine memory usage is about 110MB.

2. It uses quite a bit of CPU.  While running the above test, the CPU is
about 50% with 10 users, 70% with 20 users, and over 80% with 30 users.

3. It takes quite a bit of time to do the generation.  The minimum
generation time for the four documents are from 1 to 4 seconds (the 4
seconds one is 5 pages with 13 tables with various cell colors and
border styles).  In the 30 user test, the average time are from 20 to 40
seconds, and maximum well over 2 minutes.

-- 
Weiqi Gao
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Christopher R. Maden

At 03:25 18-07-2001, Weiqi Gao wrote:
We did some playing around with a simple FOP servlet that does
XHTML-XSL-FO-PDF using Xalan and FOP and come away with the following
findings:

1. It uses quite a bit of memory.  While running around 20-30 concurrent
users, each generating a set of four PDFs ranging from 2 to 5 pages five
times each, the servlet engine memory usage is about 110MB.

2. It uses quite a bit of CPU.  While running the above test, the CPU is
about 50% with 10 users, 70% with 20 users, and over 80% with 30 users.

3. It takes quite a bit of time to do the generation.  The minimum
generation time for the four documents are from 1 to 4 seconds (the 4
seconds one is 5 pages with 13 tables with various cell colors and
border styles).  In the 30 user test, the average time are from 20 to 40
seconds, and maximum well over 2 minutes.

How much of that load is from Xalan and how much from FOP?

It might be instructive to construct a similar applet that uses Xalan to do 
XHTML-XSL-FO, and serve those FOs (labeled as application/xml) to the 
browser.  If a significant portion of the load is due to Xalan, a reduction 
might be possible by using a different XSLT engine such as SAXON.  (SAXON 
is also more compliant than Xalan.)

-Chris
-- 
Christopher R. Maden, XML Consultant
DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training
URL: http://crism.maden.org/consulting/ 
PGP Fingerprint: BBA6 4085 DED0 E176 D6D4  5DFC AC52 F825 AFEC 58DA


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




RE: external-graphic - problem using relative path

2001-07-18 Thread Ronald Jaramillo

try  fo:external-graphic src=file:VincentSite/img/chkbxgif-y.gif/

mvh
Ronald

-Original Message-
From: Micheál Healy [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 12:16 PM
To: [EMAIL PROTECTED]
Subject: external-graphic - problem using relative path


Hi all,

I posted a message regarding this problem a couple of weeks ago, but
received no reply.  
 
I need to reference images (external-graphic) in my xsl.  It seems to work
fine when I use the absolute path, but not when I use the relative path.
Please find attached my original message - it's a little more detail and
contains some sample XSL.

Any help on this would be greatly appreciated.

TIA,

Micheál

Micheál Healy
Engitech Ltd.
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Jeremias Maerki

 3. It takes quite a bit of time to do the generation.  The minimum
 generation time for the four documents are from 1 to 4 seconds (the 4
 seconds one is 5 pages with 13 tables with various cell colors and
 border styles).  In the 30 user test, the average time are from 20 to 40
 seconds, and maximum well over 2 minutes.

This sounds quite like the experiences by Jim Cotugno (See subject
Multithreading). Some time ago I did some concurrency tests and it was
interesting to see what happened. When multiple conversions occur
concurrently FOP seems to align the processing like this:

Let's say FOP does steps 1, 2 and 3 and we have conversions A, B, C and
D which run more or less at the same time. The following seems to
happen:
A1, B1, C1, D1, A2, B2, C2, D2, A3, B3, C3, D3

I happened to see that when I sent the output of every thread into the
same console. It might very vell be, that this has something to do with
the use of static variables. This also explains your experienced maximum
of over 2 minutes.

There's a lot we can do here (everybody can help):
- Identify the bad spots
- Streamline the generation process (as currently done by Mark)
- Write a simple performance benchmark to see if we're making any
  progress. Document the results.
- Rework the bad parts

The topic Avalon has come up a few times over the last months. It has
never got much attention. But it might help us to get rid of some of the
performance problems just by reworking parts of FOP for Avalon. This
could also result in a stable high-level interface for FOP which would
probably cheer up a few people as well (Cocooners, Servlet-integrators
etc.). What do you think?

I know we're not really in the optimization phase but looking at the
number of Foppers.

Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Keiron Liddle


On Wed, 18 Jul 2001 13:43:07 Jeremias Maerki wrote:
 This sounds quite like the experiences by Jim Cotugno (See subject
 Multithreading). Some time ago I did some concurrency tests and it was
 interesting to see what happened. When multiple conversions occur
 concurrently FOP seems to align the processing like this:
 
 Let's say FOP does steps 1, 2 and 3 and we have conversions A, B, C and
 D which run more or less at the same time. The following seems to
 happen:
 A1, B1, C1, D1, A2, B2, C2, D2, A3, B3, C3, D3
 
 I happened to see that when I sent the output of every thread into the
 same console. It might very vell be, that this has something to do with
 the use of static variables. This also explains your experienced maximum
 of over 2 minutes.

I don't see how it could be static variables. I think the more likely cause
is from Vector and Hashtable. In other words we should go to jdk1.2 and get
rid of these bad classes (thats enough of my jdk1.1 bashing for the day).


 The topic Avalon has come up a few times over the last months. It has
 never got much attention. But it might help us to get rid of some of the
 performance problems just by reworking parts of FOP for Avalon. This
 could also result in a stable high-level interface for FOP which would
 probably cheer up a few people as well (Cocooners, Servlet-integrators
 etc.). What do you think?

Definitely.
Integrating Avalon should be done as soon as possible.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: external-graphic - problem using relative path

2001-07-18 Thread Micheál Healy

Ronald,

Thanks for the suggestion, but unfortuately, it hasn't worked.  I still get
the following error - Invalid Image URL - error on relative URL :
java.lang.NullPointerException.  I tried both fo:external-graphic
src=file:VincentSite/img/chkbxgif-y.gif/ and fo:external-graphic
src=file:/VincentSite/img/chkbxgif-y.gif/ with identical results.  I
wonder if it's something to do with my configuration, although, as I said, I
can read the dictionary using a relative path.

Any ideas?

Thanks,

Micheál


- Original Message -
From: Ronald Jaramillo [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 18, 2001 12:38 PM
Subject: RE: external-graphic - problem using relative path


 try  fo:external-graphic src=file:VincentSite/img/chkbxgif-y.gif/

 mvh
 Ronald

 -Original Message-
 From: Micheál Healy [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, July 18, 2001 12:16 PM
 To: [EMAIL PROTECTED]
 Subject: external-graphic - problem using relative path


 Hi all,

 I posted a message regarding this problem a couple of weeks ago, but
 received no reply.

 I need to reference images (external-graphic) in my xsl.  It seems to
work
 fine when I use the absolute path, but not when I use the relative path.
 Please find attached my original message - it's a little more detail and
 contains some sample XSL.

 Any help on this would be greatly appreciated.

 TIA,

 Micheál

 Micheál Healy
 Engitech Ltd.
 [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]




RE: external-graphic - problem using relative path

2001-07-18 Thread Ronald Jaramillo

try placing an image (say foo.gif ) on the same directory as the fop.jar .
Then write a simple fo file:

?xml version=1.0 encoding=UTF-8?
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
fo:layout-master-set
fo:simple-page-master master-name=simple
fo:region-body margin-top=3cm/
fo:region-before extent=1.5cm/
/fo:simple-page-master
/fo:layout-master-set

fo:page-sequence master-name=simple
fo:flow flow-name=xsl-region-body
fo:block
fo:external-graphic src=file:foo.gif/
/fo:block
/fo:flow
/fo:page-sequence
/fo:root

Place it in the same directory and test if from the command line.
If this does not work, something is broken with the version of fop you are
using.
Most probably the path you are using should be relative to where the fop.jar
is placed ( this is what works for me, not necesary the best way to do it )

MVH
Ronald


 -Original Message-
 From: Micheál Healy [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, July 18, 2001 2:44 PM
 To: [EMAIL PROTECTED]
 Subject: Re: external-graphic - problem using relative path
 
 
 Ronald,
 
 Thanks for the suggestion, but unfortuately, it hasn't 
 worked.  I still get
 the following error - Invalid Image URL - error on relative URL :
 java.lang.NullPointerException.  I tried both fo:external-graphic
 src=file:VincentSite/img/chkbxgif-y.gif/ and fo:external-graphic
 src=file:/VincentSite/img/chkbxgif-y.gif/ with identical 
 results.  I
 wonder if it's something to do with my configuration, 
 although, as I said, I
 can read the dictionary using a relative path.
 
 Any ideas?
 
 Thanks,
 
 Micheál
 
 
 - Original Message -
 From: Ronald Jaramillo [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, July 18, 2001 12:38 PM
 Subject: RE: external-graphic - problem using relative path
 
 
  try  fo:external-graphic 
 src=file:VincentSite/img/chkbxgif-y.gif/
 
  mvh
  Ronald
 
  -Original Message-
  From: Micheál Healy [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, July 18, 2001 12:16 PM
  To: [EMAIL PROTECTED]
  Subject: external-graphic - problem using relative path
 
 
  Hi all,
 
  I posted a message regarding this problem a couple of weeks ago, but
  received no reply.
 
  I need to reference images (external-graphic) in my xsl.  
 It seems to
 work
  fine when I use the absolute path, but not when I use the 
 relative path.
  Please find attached my original message - it's a little 
 more detail and
  contains some sample XSL.
 
  Any help on this would be greatly appreciated.
 
  TIA,
 
  Micheál
 
  Micheál Healy
  Engitech Ltd.
  [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]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




FOP in a servlet under load

2001-07-18 Thread Raju Dave

Hi,

xhtml-xsl-fo takes very short time say only fraction of total time. Thus it is best 
done with external tool and not to load fop with it. 


Raju Dave
iORMYX GmbH


http://www.monsterindia.com - The Best Jobs. For the Best Minds.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Can't build fop: Hangs after Starting Ant...

2001-07-18 Thread Gregor N. Purdy

All --

On 11 Jul 2001 11:12:50 -0400, Gregor N. Purdy wrote:
 Its been some time since I've been able to build fop from CVS. I just
 completed a fresh checkout of xml-fop and when I run ./build.sh, the
 thing just hangs after printing Starting Ant
 
 Has anyone else run into this? Is it solved? I'd like to get back to
 using FOP for some of my projects, and I'd prefer to track the
 development rather than go back to an older release.

My apologies if someone dealt with this and I didn't see it. I still
cannot build fop out of CVS. I just did a CVS update, too.

I can't figure out why Ant would hang, and I thought fop was self-
contained, so whatever I'm running should be whatever you all are
running, but I assume you are all able to build fop.

Does anyone have any idea what I could look at to try to resolve
the problem? I'd really like to get back to producing PDF files...


Thanks!



Regards,

-- Gregor
 _ 
/ \
   Gregor N. Purdy  [EMAIL PROTECTED]
   Focus Research, Inc.http://www.focusresearch.com/
   8080 Beckett Center Drive #203   513-860-3570 vox
   West Chester, OH 45069   513-860-3579 fax
\_/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




cvs commit: xml-fop/src/org/apache/fop/layout BorderAndPadding.java

2001-07-18 Thread klease

klease  01/07/18 14:24:36

  Modified:src/org/apache/fop/fo/flow TableRow.java TableCell.java
   src/org/apache/fop/layout BorderAndPadding.java
  Log:
  Make display-align work on table-cell
  
  Revision  ChangesPath
  1.48  +3 -2  xml-fop/src/org/apache/fop/fo/flow/TableRow.java
  
  Index: TableRow.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/TableRow.java,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- TableRow.java 2001/07/15 00:17:13 1.47
  +++ TableRow.java 2001/07/18 21:24:36 1.48
  @@ -1,4 +1,4 @@
  -/*-- $Id: TableRow.java,v 1.47 2001/07/15 00:17:13 arved Exp $ --
  +/*-- $Id: TableRow.java,v 1.48 2001/07/18 21:24:36 klease Exp $ --
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -350,7 +350,8 @@
// Only do this for STARTCELL, ending spans are handled separately
// What about empty cells? Yes, we should set their height too!
for (int iCol = 1; iCol = columns.size(); iCol++) {
  - if (cellArray.getCellType(iCol) == CellArray.CELLSTART) {
  + if (cellArray.getCellType(iCol) == CellArray.CELLSTART 
  + rowSpanMgr.isSpanned(iCol)==false) {
   cellArray.getCell(iCol).setRowHeight(largestCellHeight);
   }
}
  
  
  
  1.34  +97 -62xml-fop/src/org/apache/fop/fo/flow/TableCell.java
  
  Index: TableCell.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/flow/TableCell.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- TableCell.java2001/07/04 21:16:02 1.33
  +++ TableCell.java2001/07/18 21:24:36 1.34
  @@ -1,4 +1,4 @@
  -/*-- $Id: TableCell.java,v 1.33 2001/07/04 21:16:02 klease Exp $ --
  +/*-- $Id: TableCell.java,v 1.34 2001/07/18 21:24:36 klease Exp $ --
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
  @@ -48,9 +48,12 @@
 */
protected int beforeOffset;
   
  - /* ivan demakov */
  + /* For collapsed border style */
protected int borderHeight = 0;
  - protected int cellHeight = 0;
  + /**
  +  * Minimum ontent height of cell.
  +  */
  + protected int minCellHeight = 0;
   
protected int height = 0;
protected int top; // Ypos of cell ???
  @@ -126,7 +129,7 @@
}
else bRelativeAlign = false; // Align on a per-cell basis
   
  - this.cellHeight = 
this.properties.get(height).getLength().mvalue();
  + this.minCellHeight = 
this.properties.get(height).getLength().mvalue();
}
   
   
  @@ -159,9 +162,9 @@
// configure id

area.getIDReferences().configureID(id,area);
}
  -
  - int spaceLeft = area.spaceLeft() - 
m_borderSeparation/2 + borderHeight/2 ;
   
  + //  int spaceLeft = 
area.spaceLeft() - m_borderSeparation/2 + borderHeight/2 ;
  + int spaceLeft = area.spaceLeft() - m_borderSeparation ;
// The Area position defines the content rectangle! 
Borders
// and padding are outside of this rectangle.
this.cellArea =
  @@ -210,6 +213,11 @@
cellArea.end();
area.addChild(cellArea);
   
  + // Adjust for minimum cell content height
  + if (minCellHeight  cellArea.getContentHeight()) {
  + cellArea.setHeight(minCellHeight);
  + }
  +
// This is the allocation height of the cell 
(including borders
// and padding
// ALSO need to include offsets if using separate 
borders
  @@ -225,56 +233,69 @@
return new Status(Status.OK);
}
   
  - // TableRow calls this. Anyone else?
  + /**
  +  * Return the allocation height of the cell area.
  +  * Note: called by TableRow.
  +  * We adjust the actual allocation height of the area by the value
  +  * 

Re: Problem with border and tables

2001-07-18 Thread Karen Lease

Bonjour Jean-Claude,

That looks like the sort of problem I might be working on soon. I'll let
you know if and when I get it fixed.

Salut,
Karen

GALLO Jean-Claude wrote:
 
 I would like to create a fo:table inside which a fo:table-cell contain
 another fo:table. Everything goes fine while you didn't set border
 attributes. When the included table has border attributes , the PDF is not
 well suited, the contained table and its border are painted outside the
 container table.
 
 Ii looks like the table class was returning a bad width (the height is
 correct).
 
 I suppose the problem is yet referenced, but I didn't read the 8764 mails of
 the list.
 
 I'm using Fop-0.19.0-CVS on Solaris and Java 1.3
 
 Did you have any plan to correct the problem ?
 
 My XSL sample :
 ..
[snip]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Can't build fop: Hangs after Starting Ant...

2001-07-18 Thread Arved Sandstrom

At 04:34 PM 7/18/01 -0400, Gregor N. Purdy wrote:
All --

On 11 Jul 2001 11:12:50 -0400, Gregor N. Purdy wrote:
 Its been some time since I've been able to build fop from CVS. I just
 completed a fresh checkout of xml-fop and when I run ./build.sh, the
 thing just hangs after printing Starting Ant
 
 Has anyone else run into this? Is it solved? I'd like to get back to
 using FOP for some of my projects, and I'd prefer to track the
 development rather than go back to an older release.

My apologies if someone dealt with this and I didn't see it. I still
cannot build fop out of CVS. I just did a CVS update, too.

I can't figure out why Ant would hang, and I thought fop was self-
contained, so whatever I'm running should be whatever you all are
running, but I assume you are all able to build fop.

Does anyone have any idea what I could look at to try to resolve
the problem? I'd really like to get back to producing PDF files...

Hi, Gregor

Well, let's try and troubleshoot this through. I recall having had identical 
hangs last year; I wish I could remember why. :-)

Could it be a line-ending issue? This has bitten us a few times, depending 
on what machine a committer was on when they committed UNIX shell scripts, 
and if they weren't careful. I did it a time or two myself, committing the 
shell scripts with DOS line endings.

Failing that, what happens when you set the environment variables by hand, 
and then execute the final command by itself, not through the script...still 
no joy?

Can you run your current Ant on other build files?

What version of Ant are you using? Try Ant 1.3 if all else fails.

Just some starter ideas. I'm sure we'll get to the solution sooner or later.

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Mark Lillywhite

Hi

With my changes to FOP I can process tens of thousands of pages of 
XML:FO in only a few Mb of heap. I have asked for testers but so far 
noone has responded... this sounds like an ideal environment in which to 
test, no? The performance of FOP seems also to have improved, probably 
because the GC is a lot less stressful (far fewer objects to scan and 
far fewer OS memory requests being performed).

I hope to have my final changes completed today at which time I will 
post a summary of them and submit them for inclusion... they are not too 
major. I have modified all of the renderers to suit and have a slightly 
different API and calling sequence. But I'm happy to send a JAR and the 
sources to anyone who wants them earlier.

One of the main problems with FOP IMHO is not that it is poorly designed 
but that there has been little control over the quality of the code that 
is present there. There are wild variations in the code, assumptions 
made in it, commenting, use of public/private members, coupling, 
cohesion, maturity, you name it and it changes from file to file and 
module to module. I make this observation because a redesign of FOP is 
not going to make these issues go away - another solution is required.

I'll look at the synchronization issues once I'm finished with the 
pipelining issues, assuming my patches are worthwhile :)

Regards
Mark


Weiqi Gao wrote:

We did some playing around with a simple FOP servlet that does
XHTML-XSL-FO-PDF using Xalan and FOP and come away with the following
findings:

1. It uses quite a bit of memory.  While running around 20-30 concurrent
users, each generating a set of four PDFs ranging from 2 to 5 pages five
times each, the servlet engine memory usage is about 110MB.

2. It uses quite a bit of CPU.  While running the above test, the CPU is
about 50% with 10 users, 70% with 20 users, and over 80% with 30 users.

3. It takes quite a bit of time to do the generation.  The minimum
generation time for the four documents are from 1 to 4 seconds (the 4
seconds one is 5 pages with 13 tables with various cell colors and
border styles).  In the 30 user test, the average time are from 20 to 40
seconds, and maximum well over 2 minutes.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Mark Lillywhite



I just run 30 threads of my earlier chapter 15 allelements example on my
home machine and noticed that compared to a single thread run, time
spent on XSLT increased roughly 6 fold, time spent on build FO tree
increased 30 fold, formating 12 fold.  Context switches are at 6 per
second level while in FOP, compared to 4000 per second while in Xalan.

In unmodified FOP, input from the source FO document occurs entirely at 
the beginning of the FOP run, and output entirely at the end. Therefore, 
the largest part of FOP processing occurs entirely in-memory and is 
therefore CPU bound. If you run 30 CPU bound threads concurrently on a 
machine with less than 30 CPUs then you are going to get degraded 
performance.

When you say 6, 30 and 12 fold, I assume you mean times? AFAIK, 
processing time on a single CPU machine with a CPU bound thread running 
with 29 other concurrent CPU bound threads *should* take 30 times 
longer, because it's executing 30x the instructions. If the XSLT and the 
formatting are doing I/O then these parts of the system will benefit 
from threading because the JVM can make progress during IO waits. I'm 
actually surprised that the numbers aren't much higher, but perhaps you 
have SMP.

Anyway, I'm not sure if my analysis is entirely correct here but none of 
this seems particularly surprising to me, and doesn't indicate any 
problems with FOP processing per se.

Of course there is a lot I don't know about FOP so maybe someone call 
explain this to me.

Regards
Mark



The data seem to point to contention problems as was pointed out
yesterday.

It might be instructive to construct a similar applet that uses Xalan to do 
XHTML-XSL-FO, and serve those FOs (labeled as application/xml) to the 
browser.  If a significant portion of the load is due to Xalan, a reduction 
might be possible by using a different XSLT engine such as SAXON.  (SAXON 
is also more compliant than Xalan.)

-Chris
-- 
Christopher R. Maden, XML Consultant
DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training
URL: http://crism.maden.org/consulting/ 
PGP Fingerprint: BBA6 4085 DED0 E176 D6D4  5DFC AC52 F825 AFEC 58DA


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




userconfig in AIX.

2001-07-18 Thread David Ryan



Hi..I'm attempting to run FOP 0.19.0 under AIX using WebSphere 
Java 1.2.2. Mostthings seems to be working ok. My problem is 
that I can't seem to load myown user configuration file. Using the Fop 
command line program..java -classpath fop.jar org.apache.fop.apps.Fop -c 
"conf/userconfig.xml" -fofonts.fo -pdffonts.pdf---I get the 
following message.reading user configuration fileCan't find user 
configuration file conf/userconfig.xmlusing default values--I 
have tried copying the config file into the current directory. I've 
triedproviding the whole path /.../userconfig.xml. I've tried renaming 
the file.In the end I tried writing my own code to test if it was related to 
fopcommand line code. static void main( String[] args ) 
{ try { Options options = 
null; String pathFonts = 
null; InputSource foFile = new InputSource( new 
FileInputStream("fonts.fo")); FileOutputStream out = 
new FileOutputStream( "fonts.pdf" ); // options = new 
Options(new 
File("/home/davidr/Fop19/userconfig.xml")); options 
= new Options(); 
options.loadUserconfiguration("userconfig.xml"); 
Driver driver = new Driver(); 
driver.setRenderer(Driver.RENDER_PDF); 
driver.addElementMapping("org.apache.fop.fo.StandardElementMapping");driver.addPropertyList("org.apache.fop.fo.StandardPropertyListMapping"); 
driver.setOutputStream(out); 
driver.buildFOTree(createParser(), foFile); 
driver.format(); driver.render(); } catch 
(Exception e) { System.out.println("Error in 
Main"); e.printStackTrace(); } 
}You will notice, I even tried different methods of setting 
options. Everytime I get the same error. I can only assume this 
is a bug related to AIX?Anyone seen this problem, or can suggest a solution 
or workaround?Thanks..David.


Re: FOP in a servlet under load

2001-07-18 Thread Arved Sandstrom

At 11:05 AM 7/19/01 +1000, Mark Lillywhite wrote:
I hope to have my final changes completed today at which time I will 
post a summary of them and submit them for inclusion... they are not too 
major. I have modified all of the renderers to suit and have a slightly 
different API and calling sequence. But I'm happy to send a JAR and the 
sources to anyone who wants them earlier.

You can certainly fire them over to me - I'll be happy to test.

One of the main problems with FOP IMHO is not that it is poorly designed 
but that there has been little control over the quality of the code that 
is present there. There are wild variations in the code, assumptions 
made in it, commenting, use of public/private members, coupling, 
cohesion, maturity, you name it and it changes from file to file and 
module to module. I make this observation because a redesign of FOP is 
not going to make these issues go away - another solution is required.

Well, yeah, you're right. Rather than comment on this further right now, 
because I want to crash out, let's just agree that redesign is another issue 
entirely (in fact we really do need one, I believe), and that reformatting 
is just a stopgap - it doesn't address the issues you mention. Over the next 
couple of weeks we'll obviously have to hash this out.

The design is still holding its own (you'd have to read the archives to get 
a feel for why we want to move on, but all that discussion pertains to a 
FOP 2), but one real problem is the lack of design documentation - docs  
diagrams. Another real problem is that we are operating sort of at a CMM 
Level 1 - the project is succeeding because of individuals and not because 
of process. All stuff we need to talk about, definitely.

Regards,
Arved

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Mark Lillywhite

Hi,

You can certainly fire them over to me - I'll be happy to test.

Great! Thanks. I'm just about ready to send you a bunch of stuff, I 
think. Have worked out the citations business and will ask you a few 
questions privately if that's OK.

Well, yeah, you're right. Rather than comment on this further right now, 
because I want to crash out, let's just agree that redesign is another issue 
entirely (in fact we really do need one, I believe), and that reformatting 
is just a stopgap - it doesn't address the issues you mention. Over the next 
couple of weeks we'll obviously have to hash this out.

OK. I think my concern here grows from the fact that (a) I'm new and (b) 
the comments I've seen recently about redesign have not, to me, been 
design issues. Also, I want to say that I was not complaining about the 
code quality as such - in a project like this just about all code is 
Good Code and it's important to be grateful for and gracious about it - 
but just that the quality variability can itself cause problems.

The design is still holding its own (you'd have to read the archives to get 
a feel for why we want to move on, but all that discussion pertains to a 
FOP 2), but one real problem is the lack of design documentation - docs  
diagrams. Another real problem is that we are operating sort of at a CMM 
Level 1 - the project is succeeding because of individuals and not because 
of process. All stuff we need to talk about, definitely.

Yeah, but I suspect an open source project can never get much past CMM 1 
by it's very nature. I like the idea of the CMM categories but I think 
that in practise CMM can't solve problems for a bunch of autonomous 
people who don't even share a time zone. But there is probably going to 
be a better time than the present to talk about that sort of thing. :-)

Cheers
Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Weiqi Gao

On 19 Jul 2001 11:24:01 +1000, Mark Lillywhite wrote:
 
  I just run 30 threads of my earlier chapter 15 allelements example on my
  home machine and noticed that compared to a single thread run, time
  spent on XSLT increased roughly 6 fold, time spent on build FO tree
  increased 30 fold, formating 12 fold.  Context switches are at 6 per
  second level while in FOP, compared to 4000 per second while in Xalan.
 
 In unmodified FOP, input from the source FO document occurs entirely at 
 the beginning of the FOP run, and output entirely at the end. Therefore, 
 the largest part of FOP processing occurs entirely in-memory and is 
 therefore CPU bound. If you run 30 CPU bound threads concurrently on a 
 machine with less than 30 CPUs then you are going to get degraded 
 performance.

That's exactly what we observed.  Unfortunately, in the servlet world,
multi-threading is the norm.  Not so much to distribute the load as to
handle concurrent requests.  I simply cannot queue up all the requests
and process then one at a time.

The question then becomes, is there room for improvements.  From what
I've heard so far, the answer is yes.  Replacing inefficient JDK 1.1
always synchronized data structures, streamline the processing model,
find ways to reduce object creation and garbage collection, seems to be
the key.

 When you say 6, 30 and 12 fold, I assume you mean times?

Yes.  But I have to prefix that with 'uncontrolled unscientific
unofficial pseudo-benchmark on a home machine'.  Don't read too much
into it.

 AFAIK, 
 processing time on a single CPU machine with a CPU bound thread running 
 with 29 other concurrent CPU bound threads *should* take 30 times 
 longer, because it's executing 30x the instructions. If the XSLT and the 
 formatting are doing I/O then these parts of the system will benefit 
 from threading because the JVM can make progress during IO waits. I'm 
 actually surprised that the numbers aren't much higher, but perhaps you 
 have SMP.

Following suggestions from another post in the thread, we tried Saxon in
place of Xalan, and achieved noticeable speedups.  And yes, Saxon is
picky!  I'll share some numbers later.

 Anyway, I'm not sure if my analysis is entirely correct here but none of 
 this seems particularly surprising to me, and doesn't indicate any 
 problems with FOP processing per se.

It raises a question about the suitability of using FOP in a servlet
environment.  We certainly learned what is and is not achievable with
today's FOP.  And we'll regulate its use in a way that won't flatline
the servers.

 Of course there is a lot I don't know about FOP so maybe someone can
 explain this to me.

In another post Mark wrote:
 
 With my changes to FOP I can process tens of thousands of pages of
 XML:FO in only a few Mb of heap. I have asked for testers but so far
 noone has responded... this sounds like an ideal environment in 

I'll volunteer to test.  Email me at [EMAIL PROTECTED]

-- 
Weiqi Gao
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: How FOP renderred my 17,344 page document...

2001-07-18 Thread Seshadri G.K.

AAh, I have a working multi -threaded memory patch that i developed and its
been lying around with me simply because i just dont want to figure how to
commit from my stupid windoze machine. If anyone wants to see the work i
have done, committers included, pls take it from me and commit it!

sesha

- Original Message -
From: Mark [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, July 16, 2001 8:56 AM
Subject: Re: How FOP renderred my 17,344 page document...


 Hi Fopsters

  I'm personally only offended by being referred to as a fopsicle. Just
  kidding. :-)

 I just love the word 'fop', it has so many literary possibilities. :-)

  Seriously, this is great stuff. You should be aware that the initial
memory
  buffering that you see with the -buf switch is only a limited portion of
  more extensive work that has yet to be folded into FOP.

 [snip]

 OK. I believe it will be necessary for the two systems to be aware of
 one another. I actually had to back out the changes to FOText that
 related to BufferManager because BufferManager was holding onto the text
 well past it's use-by millisecond. As I understand things, the
 BufferManager stuff will help with long, single page-sequences, and my
 stuff will help with multiple page sequences. This should satisfy
 everyone! (famous last words if ever i've written them!)

  This is open-source; nobody should be offended by people hacking away at
code.

 should be being the operative word. Some open source project
 participants don't like getting critiqued by outsiders - and a patch is
 basically a critique written in Java. So I'm very pleased and excited
 with your reaction to these ideas.

  Specific comments; IDReferences have mostly to do with
  fo:page-number-citation/, that is, the possibility is there that you
need
  the page number that contains the results of rendering the block with
  id=foo356, and you're currently on page 44, and the block with
id=foo356
  will end up on page 887, although you don't know that yet. You're right,
  this kind of stuff can cause major issues for pipelining. Nothing
  insurmountable, though.

 OK. For my own personal 'itch' I don't care about page-number-citations,
 but obviously it must be supported. So I would propose that I work out
 how to deal with the citations in a PageSequence queue and use deferral
 for the time being. This would mean that documents that contain
 references to future page-sequences will consume more memory, but should
 otherwise work just the same.

  The code you see in Root.java should not require page-sequence N+1 to be
  formatted before you render page-sequence N. All that's going on there
is,
  if the force-page-count property on page-sequence N is auto, it
needs to
  know about the initial-page-number property on page-sequence N+1. This
  doesn't require any formatting to take place at all.

 OK, well with the deferral mechanism the page-sequence will be parsed
 but not formatted/rendered immediately. I'll look at the code path for
 the force-page-count property and see how i can optimise it under this
 queue scheme.

 So this is how I plan to proceed:

 o Try to get the PDF renderer serializing much sooner. This appears to
 be a current bottleneck in complex documents, but I haven't run the
 profiler against them yet since I only started processing large numbers
 of examples last night.

 o Look at the IDReferences again and see if I can design a neat
 implementation that addresses the queuing issues.

 So far all my work has been an unstructured hack (there are some nasty
 public statics in there to hold things together - um ahh), so - if I can
 show that the approach works, I intend to reimplement it from scratch
 against the latest CVS. I think what I'll do is, once I make everything
 work using my hacks, I'll post a summary of the changes I intend to
 make, so that people can give me feedback on the ideas.

 Also, I have run some of the tests from the examples directory and they
 appear to look fine, except that I don't know what they're *supposed* to
 look like!! So how would I go about getting my code validated against
 XML:FO? (I think there was a thread about this a little while ago but
 sadly I didn't read it ):

 Regards
 Mark



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Mark Lillywhite

Hi Weiqi,

In unmodified FOP, input from the source FO document occurs entirely at 
the beginning of the FOP run, and output entirely at the end. Therefore, 
the largest part of FOP processing occurs entirely in-memory and is 
therefore CPU bound. If you run 30 CPU bound threads concurrently on a 
machine with less than 30 CPUs then you are going to get degraded 
performance.


That's exactly what we observed.  Unfortunately, in the servlet world,
multi-threading is the norm.  Not so much to distribute the load as to
handle concurrent requests.  I simply cannot queue up all the requests
and process then one at a time.

Why not? It would be pretty easy to make a queue up that processes FOP 
objects serially, blocking the servlet thread until the requested object 
is formatted. With a centralised Queue you could then select the number 
of FOP processors that are processing the entries on the queue. I have a 
nice multithreaded Queue implementation that allows multiple servers on 
a single queue with multiple submitters - it doesn't block the enqueue 
caller, but that wouldn't be too difficult. That way you can have the 
right number of threads for the number of CPUs you have, and you should 
get better overall performance and much less memory usage. Sure, the 
servlet thread(s) will block waiting for processing, but that's what 
happens anyway, right?

I am actually interested in solving this problem because I am using 
XSLT-XHTML in servlets, but I am using a HTML serializer rather than 
FOP to output to browsers.

The question then becomes, is there room for improvements.  From what
I've heard so far, the answer is yes.  Replacing inefficient JDK 1.1
always synchronized data structures, streamline the processing model,
find ways to reduce object creation and garbage collection, seems to be
the key.

Agreed, there are plenty of places to improve FOP, definitely in the 
current implementation but also (apparently) in the design. I've just 
finished (I hope!) the first of a couple of iterations that should 
improve the throughput and memory use of FOP significantly. I hope to 
send patches and JARs out in a few hours, but there are plenty of places 
where things could be improved. Just one example is the FONode which 
always allocates a Vector, even if it has no children... there are 
plenty of these things - but that's OK. It's much more important to get 
things broadly correct than to be totally optimised, especially at this 
early stage.

 When you say 6, 30 and 12 fold, I assume you mean times?

Yes.  But I have to prefix that with 'uncontrolled unscientific
unofficial pseudo-benchmark on a home machine'.  Don't read too much
into it.

Sure, I wasn't reading too much into it, just replying. But a 30-fold 
time increase from 2 seconds is about 34 years. :-) I'm just a pedant I 
think, everyone these days seems to say fold when they mean times. 
It's like saying one could care less when one actually couldn't. :-)

Following suggestions from another post in the thread, we tried Saxon in
place of Xalan, and achieved noticeable speedups.  And yes, Saxon is
picky!  I'll share some numbers later.

Great!

It raises a question about the suitability of using FOP in a servlet
environment.  We certainly learned what is and is not achievable with
today's FOP.  And we'll regulate its use in a way that won't flatline
the servers.

I believe that there are going to be processing speed limitations in 
FOP, and (IMO) XML in general, for the next while. For example, most 
software (including FOP, I think) seems to process XML by comparisons 
with tags, lookups in dictionaries, etc etc. While this is lovely, what 
we end up with is this whole chain of inefficient processing - from XSL 
to FO to PDF - where everything is dealt with as Strings, with the 
management and resource usage that entails (regardless of language). It 
would be ideal if, for example, an XSLT processor could say to FOP, OK, 
instead of sending you the string 'fo:block', I'm going to send you 
the integer 1 - this double-handling of everything slows XML processing 
down significantly, and this means that there are going to limitations 
on how fast it's possible to make FOP go. In reality, I reckon that XML 
needs to be preprocessed before computers get to it, kinda like using 
lex before sending stuff off to yacc. But rather than whinge I should 
just do something about it in my spare time :-)

Anyway, all of the above are just the demented ramblings of someone who 
wishes that there was a way of efficiently encoding XML documents for 
processing. I love XML, but to summarize, I think FOP's problem is 
largely XML, not FOP.

I'll volunteer to test.  Email me at [EMAIL PROTECTED]

Great. I'm going to have a look at another phase of optimisation before 
I send you something because I suspect that all the renderers are 
working a particular way and, if so, then I may as well take advantage 
of it now - which will reduce the memory footprint even more, if 

Re: userconfig in AIX.

2001-07-18 Thread Keiron Liddle


First of all can you put -d in the command line. THis will show an error
dump of what is hapenning.

The message that you are getting is printed out if the ConfigurationReader
throws a FOPException, ie. any sort of error. So it may be that there is
some other problem such as invalid xml, there is an IOException, your
parser doesn't support namespace pref, your parser wasn't found etc.

In other words, lots of things could be wrong.

On Thu, 19 Jul 2001 04:33:01 David Ryan wrote:
 
 Hi..
 
 I'm attempting to run FOP 0.19.0 under AIX using WebSphere Java 1.2.2. 
 Most
 things seems to be working ok.  My problem is that I can't seem to load
 my
 own user configuration file.  Using the Fop command line program..
 
 java -classpath fop.jar org.apache.fop.apps.Fop -c conf/userconfig.xml
 -fo
 fonts.fo -pdf
 fonts.pdf
 
 ---I get the following message.
 reading user configuration file
 Can't find user configuration file conf/userconfig.xml
 using default values
 --
 
 I have tried copying the config file into the current directory.  I've
 tried
 providing the whole path /.../userconfig.xml.  I've tried renaming the
 file.
 In the end I tried writing my own code to test if it was related to fop
 command line code.
 
static void main( String[] args ) {
try {
  Options options = null;
 
  String pathFonts = null;
  InputSource foFile = new InputSource( new
 FileInputStream(fonts.fo));
  FileOutputStream out = new FileOutputStream( fonts.pdf );
 // options = new Options(new File(/home/davidr/Fop19/userconfig.xml));
  options = new Options();
  options.loadUserconfiguration(userconfig.xml);
 
  Driver driver = new Driver();
  driver.setRenderer(Driver.RENDER_PDF);
  driver.addElementMapping(org.apache.fop.fo.StandardElementMapping);
 
 driver.addPropertyList(org.apache.fop.fo.StandardPropertyListMapping);
  driver.setOutputStream(out);
  driver.buildFOTree(createParser(), foFile);
  driver.format();
  driver.render();
   } catch (Exception e) {
  System.out.println(Error in Main);
  e.printStackTrace();
   }
   }
 
 You will notice, I even tried different methods of setting options. 
 Every
 time I get the same error.  I can only assume this is a bug related to
 AIX?
 Anyone seen this problem, or can suggest a solution or workaround?
 
 Thanks..
 David.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: FOP in a servlet under load

2001-07-18 Thread Keiron Liddle


On Thu, 19 Jul 2001 03:05:33 Mark Lillywhite wrote:
 Hi
 
 With my changes to FOP I can process tens of thousands of pages of 
 XML:FO in only a few Mb of heap. I have asked for testers but so far 
 noone has responded... this sounds like an ideal environment in which to 
 test, no? The performance of FOP seems also to have improved, probably 
 because the GC is a lot less stressful (far fewer objects to scan and 
 far fewer OS memory requests being performed).

I'll take a look at it, although I don't really have anywhere decent to
actually test it properly.

 One of the main problems with FOP IMHO is not that it is poorly designed 
 but that there has been little control over the quality of the code that 
 is present there. There are wild variations in the code, assumptions 
 made in it, commenting, use of public/private members, coupling, 
 cohesion, maturity, you name it and it changes from file to file and 
 module to module. I make this observation because a redesign of FOP is 
 not going to make these issues go away - another solution is required.

and at the end of the day FOP still doesn't do what it is intended to do
(format XSL properly).

The only way to move forward on this is to decide where we stand on such
things as:
- jdk version
- data structures
- use of data structures
- etc.

(once I have cvs access again) I will be setting up all elements to read
all the relevant properties. With that I will be looking at how the
information is handled.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Unknown namespace prefix fo

2001-07-18 Thread peti ban

I am facing a problem:

When I use fop_15 from the server. It is working all right, but the same code
doesn't work for fop_14. 

It gives the error - Unknown namespace prefix fo

Even the sample file which is provided with FOP version_14 also doesn't work.


My xsl file looks like this.

?xml version=1.0?
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fo=http://www.w3.org/1999/XSL/Format;

xsl:template match =/
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;

-
/fo:root
/xsl:template
---
/xsl:stylesheet

Do I need to add anything while declaring the namespaces? 

Thanks in advance.

Regards

Peti Ban




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: userconfig in AIX.

2001-07-18 Thread Keiron Liddle

Well thats you problem, its not proper xml.

You have to actually cloas of all tags.
ie.
   font-triplet name=gara style=normal weight=normal/
notice the / at the end of the line

On Thu, 19 Jul 2001 08:19:10 David Ryan wrote:
 Thanks for the suggestion.  I tried the -d option but it didn't give me
 much
 detail on why the error was occuring.  I tried commenting out most of the
 userconfig.xml and found that it succeeded.  Now I need to work out why
 it
 doesn't like my config file.  Is there anyway I can get more information
 from the config file parser?
 
 !DOCTYPE configuration SYSTEM config.dtd
 configuration
 fonts
  font metrics-file=gara.xml kerning=yes embed-file=gara.ttf
 font-triplet name=gara style=normal weight=normal
  /font
 /fonts
 /configuration
 
 Can you see anything wrong with this?  Commenting out the font tag
 makes
 it read the file successfully.
 
 Thanks,
 David.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: userconfig in AIX.

2001-07-18 Thread Stefan Bodewig

On Thu, 19 Jul 2001, David Ryan [EMAIL PROTECTED] wrote:

  font metrics-file=gara.xml kerning=yes embed-file=gara.ttf
 font-triplet name=gara style=normal weight=normal
  /font
 
 Can you see anything wrong with this?

You don't close the font-triplet element. Make that

font-triplet name=gara style=normal weight=normal /

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]