RE: Redesign Goals and XSmiles

2002-06-12 Thread Mikko Honkala

Hello FOP :)

Sorry for the delay, but I've just noticed the thread on FOP  X-Smiles now. I've 
forwarded this message to the
[EMAIL PROTECTED] list as well.

I'm glad that the FOP community is interested in the X-Smiles project. We've been 
using FOP as part of the browser for ages, I think
maybe 18 months.

We've extended FOP AWT renderer with live links and XForms controls.

And yes, we are still maintaining a stripped down version of X-Smiles with FOP that is 
JDK 1.1 compliant, since we are also focusing
restricted devices and environments. We've therefore stopped at the last JDK 1.1 
version of FOP.

It might still be desired to create 2 versions of the FO renderer in X-Smiles, one for 
JDK 1.1, that uses the old FOP version and
one for JDK 1.2, that uses the latest version. We might be interested to add this, if 
there were substantive benefits, such as
dynamic modification of the DOM tree.

Best Regards,
Mikko Honkala
www.x-smiles.org
W3C XForms WG

 -Original Message-
 From: Jason Foster [mailto:[EMAIL PROTECTED]]
 Sent: 5. kesakuuta 2002 5:05
 To: [EMAIL PROTECTED]
 Subject: Redesign Goals and XSmiles


 I have been working with the XSmiles browser and have been quite enjoying
 the experience of mixing XML content.  In their documentation, the XSmiles
 team mentions a few things that the current version of FOP doesn't support:

  The limitations of FOP itself include:
 
  * FOP's AWTRenderer is a previewer, which prints contents one page at
  the time to a graphics object. Therefore changing content after rendering
  or using an active background would need rewrite of the renderer to use
  awt/swing components.
  * Scripting is not supported. Adding script support could be laborious,
   because DOM tree is no longer visible to the renderer, which handles the
  FOP Area Tree.

 I was wondering whether there is any desire to address these requirements?
If you haven't tried XSmiles, I would heartily suggest taking a look, as
 it is a pretty amazing client if you're trying to be as close to be
 bleeding edge of W3 technologies as possible.  The ability to do things
 such as merge live FO and XForms elements would be pretty cool.

 Thanks!

 Jason Foster


 -
 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: Performance and java 1.1

2001-09-23 Thread Mikko Honkala

Dear FOP developers,

I'm not a committer (I've sent few patches, though :), so I don't get a
official vote, but as the member of the X-Smiles project, I would really
like to see continued support for Java 1.1.

One of our target platforms is Open Source Java platform Kaffe, which is
roughly Java 1.1.8 compatible. We are currently able to run FOP 0.20.1 on
Kaffe using our own derivation of AWTRenderer.

So unofficial -1 on dropping jdk 1.1 support :)

Mikko Honkala
X-Smiles http://www.x-smiles.org/

 -Original Message-
 From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
 Sent: 21. syyskuuta 2001 11:36
 To: [EMAIL PROTECTED]
 Subject: Performance and java 1.1


 Hi All,

 I have been doing some performance testing so we can get an idea of how
 things might be improving (or getting worse) with changes to the code.
 There are three types of tests. I have used 6 fo documents that are
 generated 500 times.
 - for each document a new jvm is started, so 3000 documents in 3000 jvm's
 in serial (about 344m)
 - use only one jvm for all documents and create them all in serial (about
 57m)
 - use one jvm and a thread for each document, each thread then does that
 document 500 times (a long time)

 The actual numbers will depend on the documents size, complexity and
 inclusion of certain elements such as graphics. The threaded test
 will also
 depend on how many threads are using fop at the same time. This is mainly
 to give a general idea.

 Some recent changes have improved the times by about 1 - 2% but one change
 that I have tried has made about a 60% improvement with the threaded test.
 This is by simply using HashMap instead of Hashtable. This is very
 significant for cocoon and others who may be using fop in a threaded
 environment. The time is changed from being twice as slow as serial to
 faster than serial.

 So the question is: can we drop java 1.1 support and use better data
 structures?


 These numbers are for 6 documents 8 times each.
 --
 With Hashtable
 6 documents x 8

 One JVM in serial
 user  1m2.040s
 user  1m2.560s

 Threaded
 user  1m54.780s
 user  1m56.580s

 ---
 With HashMap

 One JVM in serial
 user  0m59.260s

 Threaded
 user  0m44.780s
 user  0m45.660s
 user  0m45.700s

 This is the user time using unix time which is actual processor time for
 the process.

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



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




Errors in link positioning

2001-09-14 Thread Mikko Honkala

Hi,

there are some bugs in FOP 0.20.1 in link positioning:

1) abolutely positioned blocks will completely mess up link positioning for
that page
2) links do not take the padding-top attribute into account, while the
renderers do. See attached fo and pdf for a demo of this bug.

- Mikko Honkala - http://www.x-smiles.org/


 demos2.fo
 demos2.pdf

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