tables in PDF

[Vaidya, Raghavendra (CORP, GEITC)]

Hi,
I am trying to print a big table in which the rows span more than one page.
In some cases a part of the row at the end of the page is flowing to next
page.
How to keep all the rows on the same page.
I am using FOP 0.17 
Can some body help me
Thsnks in advance
Raghavendra


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

Re: [Patch] bug 2243 - extra space at the beginning of next lineafter line feed

[Tore Engvig]

Hi Karen,

I checked in my changes before I read your mail.
The code I just checked in has a lot of changes regarding whitespace.
I just looked at the bug and the the attached fo. I ran it through the new
code and it renders different - the missing line is included now.

I don't know if the bug appears as fixed because of the recent changes -
but it might because the LineArea constructor now discards some pending
InlineSpaces.

I'll take a look at it.


Tore


On Tue, 24 Jul 2001, Karen Lease wrote:

> Hi Tore,
>
> While you're looking at whitespace in LineArea I thought you might
> be interested in a bug I noticed yesterday.
>
> Looking at a table bug report
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2740, I stumbled
> across a different problem.
>
> It turns out that the fo file has lots of trailing whitespace in most of
> its blocks (fairly common in many formatted .fo files). In fact, it has
> a structure that looks like this:
>
> table-cell -- block |-- whitespace
> |-- block -- text
> |-- whitespace
>
> The first whitespace gets eliminated in the Block class during the widow
> handling. Then the nested block gets laid out and fits completely in the
> remaining space. Then the outer block tries to layout its last child,
> which is only whitespace. But before discovering that it won't actually
> create a LineArea (at least given the current whitespace-related
> property values), it returns an incomplete layout status because it
> can't fit a LineArea in the remaining space. The result is that my outer
> Block returns incomplete, and so does the table cell, but what is
> actually composed is complete. So the next area composed is empty,
> except for the padding and borders.
>
> I haven't looked much into handling all these linefeed, whitespace
> properties (although it certainly would be on the menu for the "New
> Layout"...) and thought maybe you had.
> There is a method in FOText called "willCreateArea()" which is used by
> the widow/orphan code in Block. Then in LineArea there is more code to
> see what to do with spaces, which is more complicated. I'm not
> necessarily asking you to try to fix the bug I mentioned, but thought
> you might have something to say about it.
>
> Regards,
> Karen Lease
>
>
> Tore Engvig wrote:
> >
> > On Mon, 23 Jul 2001, Rainer Garus wrote:
> >
> > > Is it possible to insert and commit the patch sended on 2001-06-28 to CVS?
> >
> > Had completely forgooten about your patch! Your reminder came just in time
> > - I'm working on the LineArea class right now. I'm trying to add better
> > support for spaces (there's about a dozen of different unicode spaces) and
> > have problems with my non-breaking spaces causing an extra space at
> > beginning of next line.
> >
> > I'll take a look at it.
> >
> > Tore
> >
> > >
> > > Rainer Garus
> > >
> > > -
> > > 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]
>
>


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

[Bug 2297] - Japanese Kanji SPACE does not show correctly

[bugzilla]

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2297

*** shadow/2297 Sat Jun 23 00:08:18 2001
--- shadow/2297.tmp.24365   Tue Jul 24 15:09:46 2001
***
*** 2,9 
  | Japanese Kanji  SPACE does not show correctly  |
  ++
  |Bug #: 2297Product: Fop |
! |   Status: NEW Version: all |
! |   Resolution:Platform: PC  |
  | Severity: Normal   OS/Version: Windows NT/2K   |
  | Priority: Other Component: pdf renderer|
  ++
--- 2,9 
  | Japanese Kanji  SPACE does not show correctly  |
  ++
  |Bug #: 2297Product: Fop |
! |   Status: RESOLVEDVersion: all |
! |   Resolution: FIXED  Platform: PC  |
  | Severity: Normal   OS/Version: Windows NT/2K   |
  | Priority: Other Component: pdf renderer|
  ++

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

[Bug 2243] - extra space at the beginning of next line after line feed

[bugzilla]

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2243

*** shadow/2243 Thu Jul 19 18:13:24 2001
--- shadow/2243.tmp.24349   Tue Jul 24 15:08:14 2001
***
*** 2,9 
  | extra space at the beginning of next line after line feed  |
  ++
  |Bug #: 2243Product: Fop |
! |   Status: NEW Version: all |
! |   Resolution:Platform: PC  |
  | Severity: MajorOS/Version: Windows NT/2K   |
  | Priority: Other Component: general |
  ++
--- 2,9 
  | extra space at the beginning of next line after line feed  |
  ++
  |Bug #: 2243Product: Fop |
! |   Status: RESOLVEDVersion: all |
! |   Resolution: FIXED  Platform: PC  |
  | Severity: MajorOS/Version: Windows NT/2K   |
  | Priority: Other Component: general |
  ++

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

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

[tore]

tore01/07/24 15:04:41

  Modified:src/org/apache/fop/layout LineArea.java
   src/org/apache/fop/layout/inline InlineSpace.java
  Log:
  Added support for various spaces, inluding non-breaking space
(fixes bug no 2297)
  Added support for line breaking in the middle of words for CJK languages
  Fixes for bug 2243 based on a patch from [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.46  +293 -74   xml-fop/src/org/apache/fop/layout/LineArea.java
  
  Index: LineArea.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/layout/LineArea.java,v
  retrieving revision 1.45
  retrieving revision 1.46
  diff -u -r1.45 -r1.46
  --- LineArea.java 2001/07/17 20:27:13 1.45
  +++ LineArea.java 2001/07/24 22:04:41 1.46
  @@ -1,4 +1,4 @@
  -/* $Id: LineArea.java,v 1.45 2001/07/17 20:27:13 tore Exp $
  +/* $Id: LineArea.java,v 1.46 2001/07/24 22:04:41 tore 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.
  @@ -23,10 +23,12 @@
   import org.apache.fop.fo.properties.VerticalAlign;
   import org.apache.fop.layout.hyphenation.Hyphenation;
   import org.apache.fop.layout.hyphenation.Hyphenator;
  +import org.apache.fop.configuration.Configuration;
   
   //java
   import java.util.Vector;
   import java.util.Enumeration;
  +import java.util.StringTokenizer;
   import java.awt.Rectangle;
   
   public class LineArea extends Area {
  @@ -66,7 +68,7 @@
   protected static final int NOTHING = 0;
   protected static final int WHITESPACE = 1;
   protected static final int TEXT = 2;
  -
  +
   /* the character type of the previous character */
   protected int prev = NOTHING;
   
  @@ -116,10 +118,38 @@
   
   if (prevLineArea != null) {
   Enumeration e = prevLineArea.pendingAreas.elements();
  -while (e.hasMoreElements()) {
  -pendingAreas.addElement(e.nextElement());
  +Box b = null;
  +// There might be InlineSpaces at the beginning
  +// that should not be there - eat them
  +boolean eatMoreSpace = true;
  +int eatenWidth = 0;
  +
  +while (eatMoreSpace) {
  +if (e.hasMoreElements()) {
  +b = (Box)e.nextElement();
  +if (b instanceof InlineSpace) {
  +InlineSpace is = (InlineSpace)b;
  +if (is.isEatable())
  +eatenWidth += is.getSize();
  +else
  +eatMoreSpace = false;
  +} else {
  +eatMoreSpace = false;
  +}
  +} else {
  +eatMoreSpace = false;
  +b = null;
  +}
  +}
  +
  +while (b != null) {
  +pendingAreas.addElement(b);
  +if (e.hasMoreElements())
  +b = (Box)e.nextElement();
  +else
  +b = null;
   }
  -pendingWidth = prevLineArea.getPendingWidth();
  +pendingWidth = prevLineArea.getPendingWidth() - eatenWidth;
   }
   }
   
  @@ -165,9 +195,8 @@
   int wordStart = start;
   int wordLength = 0;
   int wordWidth = 0;
  -// With CID fonts, space isn't neccecary currentFontState.width(32)
  -int whitespaceWidth =
  -currentFontState.width(currentFontState.mapChar(' '));
  +// With CID fonts, space isn't neccesary currentFontState.width(32)
  +int whitespaceWidth = getCharWidth(' ');
   
   char[] data = new char[odata.length];
   char[] dataCopy = new char[odata.length];
  @@ -181,15 +210,19 @@
   int charWidth;
   /* get the character */
   char c = data[i];
  -if (!((c == ' ') || (c == '\n') || (c == '\r') ||
  -  (c == '\t'))) {
  -//c = data[i] = currentFontState.mapChar(c);
  -   charWidth = currentFontState.width(currentFontState.mapChar(c));
  +if (!(isSpace(c) || (c == '\n') || (c == '\r') ||
  +  (c == '\t') || (c == '\u2028'))) {
  +   charWidth = getCharWidth(c);
  isText = true;
  -   if (charWidth <= 0)
  +   // Add support for zero-width spaces
  +   if (charWidth <= 0 && c != '\u200B' && c != '\uFEFF')
 charWidth = whitespaceWidth;
   } else {
  -   charWidth = whitespaceWidth;
  +if ((c == '\n') || (c == '\r') || (c == '\t'))
  +charWidt

Re: fo:block-container and page breaks

[Karen Lease]

Bertrand,

Are you trying to get the block-container itself on a new page? In that
case I think the normal solution would be to put the break-before
property on the block-container itself. However I see this isn't
implemented yet in FOP. So what happens if you use 
 and then follow it directly with your
absolutely positioned block-container?

Or are you trying to do something else?

Regards,
Karen Lease

ROUGIER Bertrand wrote:
> 
> I put a  inside a 
> to get a page break but it doesn't work.
> When I put   outside the
> ,
> it works. But I need to use a block-container (for a absolute
> positionning)
> 
> Thanks for your help !
> 
> Bertrand Rougier
> 
> -
> 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: [Patch] bug 2243 - extra space at the beginning of next lineafter line feed

[Karen Lease]

Hi Tore,

While you're looking at whitespace in LineArea I thought you might
be interested in a bug I noticed yesterday.

Looking at a table bug report
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2740, I stumbled
across a different problem.

It turns out that the fo file has lots of trailing whitespace in most of
its blocks (fairly common in many formatted .fo files). In fact, it has
a structure that looks like this:

table-cell -- block |-- whitespace
|-- block -- text
|-- whitespace

The first whitespace gets eliminated in the Block class during the widow
handling. Then the nested block gets laid out and fits completely in the
remaining space. Then the outer block tries to layout its last child,
which is only whitespace. But before discovering that it won't actually
create a LineArea (at least given the current whitespace-related
property values), it returns an incomplete layout status because it
can't fit a LineArea in the remaining space. The result is that my outer
Block returns incomplete, and so does the table cell, but what is
actually composed is complete. So the next area composed is empty,
except for the padding and borders.

I haven't looked much into handling all these linefeed, whitespace
properties (although it certainly would be on the menu for the "New
Layout"...) and thought maybe you had.
There is a method in FOText called "willCreateArea()" which is used by
the widow/orphan code in Block. Then in LineArea there is more code to
see what to do with spaces, which is more complicated. I'm not
necessarily asking you to try to fix the bug I mentioned, but thought
you might have something to say about it.

Regards,
Karen Lease


Tore Engvig wrote:
> 
> On Mon, 23 Jul 2001, Rainer Garus wrote:
> 
> > Is it possible to insert and commit the patch sended on 2001-06-28 to CVS?
> 
> Had completely forgooten about your patch! Your reminder came just in time
> - I'm working on the LineArea class right now. I'm trying to add better
> support for spaces (there's about a dozen of different unicode spaces) and
> have problems with my non-breaking spaces causing an extra space at
> beginning of next line.
> 
> I'll take a look at it.
> 
> Tore
> 
> >
> > Rainer Garus
> >
> > -
> > 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]

Re: Performance Problems

[Karen Lease]

Arved Sandstrom wrote:
> 

> 
> Failing that, if we are talking about compiling with javac or Jikes or
> whatever, you are left with compiled bytecode, and for that we have to have
> a JVM. No ifs and buts. So then the avenue of inquiry leads down looking at
> the Invocation API in JNI.

Although I tend to think it might be easier to go the Cocoon2 or HTTP
proxy route
suggested by Jeremias, I think it should be possible to do this with the
Invocation API. Basically you have to encapsulate a VM in your COM
object, but once you have it you should be able to use it do multiple
FOP calls. I have used this in the past to combine C++ and Java code, in
both Mac and Microsoft environments, so it can be done. Just to be
clear, this is a Sun JVM I'm talking about; no special MS Java involved.

Good luck,
Karen Lease



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

fo:block-container and page breaks

[ROUGIER Bertrand]

I put a  inside a 
to get a page break but it doesn't work. 
When I put   outside the
,
it works. But I need to use a block-container (for a absolute
positionning)

Thanks for your help !

Bertrand Rougier 

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

Re: FOP jar and patches available

[Chetan Vig]

Hey Mark,

I am trying to implement your changes in. However, I had a question on the
setRenderer method.

driver.setRenderer(new org.apache.fop.render.awt.AWTRenderer(translator));

What is this translator, and how do I create a new instance for this
translator? Is it

Translator translator = new Translator();

Please do let me know.

Thanks,

-Chetan


Mark Lillywhite wrote:

> Hey Fopstars
>
> I've finally managed to post my diffs, JARs, tars and output samples,
> along with a fairly lengthy explanation of what I've done, to the web.
> This includes a PDF bug fix so that Acrobat should work again, now.
> Check it all out at:
>
> http://www.inomial.com/fop
>
> Let me know if any links are dead or you have any problems. Instructions
> to applying the patch are on the web pages. The source and JARs are
> against the current CVS, updated only minutes before I sent this email.
> Note that I use Unix (Linux) so I don't know how patch/diffs/cvs/etc
> work on That Other Operating System.
>
> Feedback is definitely welcome, updates and patches etc likewise.
>
> All modified files are commented.
>
> Regards
> Mark
>
> -
> 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: Anticipated Work In Near Future

[Peter B. West]

Arved Sandstrom wrote (inter alia):

> 2. I'll be lending a hand to Peter West if and as required. I think his Tree 
> class will definitely help all round, possibly with markers and I think 
> definitely with keeps and space-specifier resolution.

Arved,

I am delighted that you find Tree class useful.  I am continuing to look 
  in the places you pointed me to, but I progress very deliberately.  If 
you see any particular uses for Tree, please apply it as you see fit. 
In the meantime, I will post questions as they arise.

Peter
-- 
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


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

Re: Performance Problems

[Jeremias Maerki]

> My confidence level of being able to transition FOP to COM myself is very
> low. It would be really nice if someone would take this on :) Or maybe I'm
> just being lazy.

You said earlier that Cocoon worked for you but you dropped it because
it used an older version of FOP. Did you look at Cocoon 2? I think it
currently includes FOP 0.18. I think from this version it's just a
matter of replacing fop.jar to get the latest version running. I'm sure
there are people around who did that already.

Maybe you could implement a simple HTTP-Proxy (that calls Cocoon) in
place of the code that calls FOP now. Just an idea.

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: Performance Problems

[Darren Munt]

>One thing to be careful of is, who is doing the talking about 
>compiling Java classes as COM components? Whenever I have run 
>across references to doing this, it's been about using MS Visual 
>J++ to compile the Java.

Of course, the talking has mostly been done by Microsoft. They want to be
all things to all people. I hate them but the bastards put food on my table.

There are a couple of alternatives available to people stuck in COM land
though. You can run a utility that registers a Java class such that it can
be called in the same way that we would call a COM object. This evidently
involves smoke and mirrors behind the scenes, no doubt needing to start the
JVM afresh each time, and probably yeilds no real gains over the command
line approach. The other is to compile the Java class as a COM object using
Visual J++. Either way, you have to use the Microsoft JVM. 

My confidence level of being able to transition FOP to COM myself is very
low. It would be really nice if someone would take this on :) Or maybe I'm
just being lazy.

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

Re: Tree class

[Peter B. West]

I have added the Ancestor iterator class.  The main outstanding task 
with Tree is to think through the full impact of changes to the tree, 
particularly deletions, on the iterators.  Should a removal descend the 
subtree recursively deleting, for example.

The current situation is that any change in the tree throws a 
ConcurrentModificationException on PreOrder, PostOrder and Ancestor, but 
the current state of the iterator is otherwise unchanged.  Under what 
circumstances, if any, might it be reasonable to pick up the iterator 
after a Comod exception?

The Preceding/FollowingSibling iterators only throw Comod exceptions on 
changes to the parents 'chldren' ArrayList - other changes in the Tree 
go unnoticed.

Off the top of my head, I think that XSL-style tree partitioning 
(Ancestors, Children, Preceding and Following) can be achieved with 
little extra effort on the basis of the existing iterators, if such is 
required.

Peter
-- 
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


//package org.apache.fop.datatypes;

import java.util.*;

// The Tree class is analogous to one of the Collection classes.  It
// provides a bag with a certain structure into which objects may be collected
// for manipulation.  This is the level of at which those operations and
// fields are defined which allow for manipulation of the tree as a whole.

/**
 * Tree.java
 *
 * The Tree class is analogous to one of the Collection
 * classes.  It provides a bag with a certain structure into which objects
 * may be collected for manipulation.
 *
 * The outer class, Tree, is the level at which are defined those fields
 * and methods which are provided for the manipulation of the tree as a
 * whole.  The tree is actually comprised of a collection of Node
 * elements.
 *
 *
 * The primary reasons for the existence of a separate Tree
 * class is to provide an object for tree-wide synchronization, and to
 * have a home for modCount for the provision of
 * fast-fail iterators.  For more details, see the
 * discussion of modCount in AbstractList.
 *
 * $Id: Tree.java,v 1.13 2001-07-22 16:38:42+10 pbw Exp pbw $
 * @author mailto:[EMAIL PROTECTED]";>Peter B. West
 * @version
 */

public class Tree {

/**
 * The number of times the tree has been structurally modified.
 * See the discussion of the modCount field in
 * AbstractList.
 */
protected int modCount = 0;
protected int nodeCount = 0;

protected Node root;

public Tree() {}

public Tree(Node root) {
this.root = root;
}

public int modified() {
// In the Tree class, this function updates the modCount
// N.B. This method is always called from within a synchronized
// method.
synchronized (this) {
return ++modCount;
}
}

public int getModCount() {
synchronized (this) {
return modCount;
}
}

public boolean modCountEqualTo(int value) {
synchronized (this) {
return value == modCount;
}
}

public int size() {
return nodeCount;
}

public boolean isEmpty() {
return nodeCount == 0;
}


public class TreeException extends Exception {
public TreeException(String message) {
super(message);
}

}

/**
 * Member class Node of class Tree provides the
 * structure for a general-purpose tree.
 *
 * Node
 * +-+
 * |(Node) parent|
 * +-+
 * |ArrayList|
 * |+---+|
 * ||(Node) child 0 ||
 * |+---+|
 * |:   :|
 * |+---+|
 * ||(Node) child n ||
 * |+---+|
 * +-+
 * |(Object) payload ->  |
 * | contents of this node   |
 * +-+
 *
 * ArrayList is used for the list of children because the
 * synchronization is performed "manually" within the individual methods,
 * and beause the fail-fast characteristics of the ArrayList
 * iterator and listIterators is desired.
 *
 * See Tree for the tree-wide support methods and fields.
 */

public class Node {

private Node parent;
private ArrayList children; // ArrayList of Node
protected Object payload;

/**
 * No argument constructor.
 *
 * Assumes that this node is the root, and so will throw a
 * TreeException when the root node in the enclosing
 * Tree object is non-null.
 */

public Node()
throws TreeException {
if (Tree.this.root != null) {
throw new TreeException(
"No arg constructor invalid when root exists");
}
parent = null;
 

Barriers to entry

[Peter B. West]

I would like to think aloud a little here, about my efforts to
try to follow the code.  This is my introduction to OO design
and programming, and (in spite of my tone sometimes) I do not
want to tread on anyone's toes here.

My comments are inspired by consideration of the issue of
cost-of-entry for new maintainers, and the sheer amount of
stumbling around that I have done up to now.  Mark's recent ease
of entry into the code may well put the lie to everything I say.

One of the things that has puzzled me is the reliance on an
object set which is largely determined by the set of FO nodes.
The XML parsing is a complete black box, which may have some
advantages, but is disconcerting for those, like me, who are
encountering XML parsing for the first time.  In any case,
the point is moot because of the move to serialization, which
should open that particular black box right up.

If an when that happens, I hope to be able to detect a flow of
control something like this:

   process root
process layout-master-set
 while children
  switch
   process simple-page-master
process region-body
process region-before
process region-after
process region-start
process region-end
   process page-sequence-master
...
process fo-declarations
 ...
process page-sequence
 until no more

with a parser feeding sets of element+attributes to a single
reader which can deliver elements of a known type on demand.
The whole process is then embedded with the "process root" method,
which requires an fo:root element, and terminates at the end of
that element.

As part of this I would like to see, if possible, a reduction
in the number of objects.  This harks back to what I was saying
about the current object set.  It seems to me that the FO nodes
are really just data, and that the algorithmic necessities are
much more minimal than the set of nodes and, heaven forbid,
properties.  Furthermore, as data, they are very simple and
consistent: simple and consistent enough to be expressed by XML
elements and attribute sets.

It seems to me from my very very limited experience that the
object model works very well for the encapsulation of data
and the provision of high level accessors for that data, as is
exemplified by the Collections of the JDK, but less well when
essentially algorithmic processes are forced into an artificial
object framework in which there is insufficient separation
between data and algorithms.

My impression of the situation at the moment is that the process
flow has been hacked up into pieces which are much too small,
and which militate against understanding.  If you understand a
program by following the control flow with a tracer or profiler,
you don't really understand it.  If you are *obliged* to do that,
there is something fundamentally wrong with the expression of
the algorithm(s).

I feel that Karen and Arved's proposals for the new model
are moving in this direction.  They are talking about
uber-processes which do not correspond to any particular FO object,
but which are primarily processing objects, i.e. heirarchical
collections of methods, in their own right.

If I am simply displaying my OO innocence here, please be
indulgent.

Peter
-- 
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


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

RE: Performance Problems

[Arved Sandstrom]

At 07:27 PM 7/24/01 +1000, Darren Munt wrote:
>I'm aware that it is possible to compile java classes as COM components, but
>even if I knew where to start on this, I'm not sure it would help much. The
>cocoon approach was looking good for us, but we discovered that the version
>of FOP that is installed with cocoon does not have the level of FO
>compliance that we need.

One thing to be careful of is, who is doing the talking about compiling Java 
classes as COM components? Whenever I have run across references to doing 
this, it's been about using MS Visual J++ to compile the Java.

This may be something you want to explore, nevertheless. I am just pointing
out that in this discussion "compile" has different meanings.

Failing that, if we are talking about compiling with javac or Jikes or 
whatever, you are left with compiled bytecode, and for that we have to have 
a JVM. No ifs and buts. So then the avenue of inquiry leads down looking at 
the Invocation API in JNI.

Sun doesn't seem to be as much help on this as they could. They leaped way 
ahead and have provided an early-access COM-EJB bridge; if you had FOP all 
wrapped up inside a session bean you'd be all set. :-)

This is interesting and I'll see what I can find out further.

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: Performance Problems

[Darren Munt]

Jeremias,

>That's because you're starting a new VM for every document you're
>creating. First the VM is started (expensive operation), then all
>classes have to be loaded which also takes a long time. Processing in
>Cocoon was faster because all FOP classes were already loaded after the
>first call. 

I figured that might have at least contributed to the problem, but I did not
realise that it would be such a big factor. I'm not a Java programmer by a
long shot and this is the first time I've tried to use it in the real world
(outside of Uni).

>How to improve your situation depends on how FOP fits into
your project.

The PDF component of the app is very small, it creates only a single report
and the app does much more than this. What happens is the user requests a
hard copy of a particular report, which we then have to create on the fly
and stream to the browser. FOP works brilliantly for this, but for the
processing time.

>If your application is written in Java...

Unfortunately it is not. It's written in ASP/Visual Basic. This is not the
place to discuss the relative merits of development platforms, but for some
very good reasons, this was a good choice for us. At least here in
Australia, COM based apps, and programmers who can write them, are common
enough. The problem is, no-one in the COM world has done what you guys have
done with FO. 

I'm aware that it is possible to compile java classes as COM components, but
even if I knew where to start on this, I'm not sure it would help much. The
cocoon approach was looking good for us, but we discovered that the version
of FOP that is installed with cocoon does not have the level of FO
compliance that we need.

It may be that I need to bring on board a Java programmer to sort this out
(I'm getting too old to learn new tricks). I guess I was hoping that someone
might have already achieved a COM installation that works, or that there
would be some other easy resolution.

Thanks for the pointers anyway. 

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

cvs commit: xml-fop/src/org/apache/fop/svg PDFAElementBridge.java PDFANode.java PDFDocumentGraphics2D.java PDFTranscoder.java

[keiron]

keiron  01/07/24 02:08:45

  Modified:src/org/apache/fop/render/pdf PDFRenderer.java
   src/org/apache/fop/svg PDFDocumentGraphics2D.java
PDFTranscoder.java
  Added:   src/org/apache/fop/svg PDFAElementBridge.java PDFANode.java
  Log:
  added the start of svg linking
  also improved a few text things
  
  Revision  ChangesPath
  1.74  +4 -1  xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java
  
  Index: PDFRenderer.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/pdf/PDFRenderer.java,v
  retrieving revision 1.73
  retrieving revision 1.74
  diff -u -r1.73 -r1.74
  --- PDFRenderer.java  2001/07/20 20:57:22 1.73
  +++ PDFRenderer.java  2001/07/24 09:08:45 1.74
  @@ -1,4 +1,4 @@
  -/* $Id: PDFRenderer.java,v 1.73 2001/07/20 20:57:22 klease Exp $
  +/* $Id: PDFRenderer.java,v 1.74 2001/07/24 09:08:45 keiron 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."
  @@ -391,6 +391,8 @@
   GVTBuilder builder = new GVTBuilder();
   GraphicsNodeRenderContext rc = getRenderContext(fs);
   BridgeContext ctx = new BridgeContext(userAgent, rc);
  +PDFAElementBridge aBridge = new PDFAElementBridge();
  +ctx.putBridge(aBridge);
   GraphicsNode root;
   PDFGraphics2D graphics =
 new PDFGraphics2D(true, fs, pdfDoc,
  @@ -399,6 +401,7 @@
   graphics.setGraphicContext(
 new org.apache.batik.ext.awt.g2d.GraphicContext());
   graphics.setRenderingHints(rc.getRenderingHints());
  +aBridge.setPDFGraphics2D(graphics);
   try {
   root = builder.build(ctx, doc);
   root.paint(graphics, rc);
  
  
  
  1.8   +32 -7 xml-fop/src/org/apache/fop/svg/PDFDocumentGraphics2D.java
  
  Index: PDFDocumentGraphics2D.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/svg/PDFDocumentGraphics2D.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- PDFDocumentGraphics2D.java2001/07/10 11:59:23 1.7
  +++ PDFDocumentGraphics2D.java2001/07/24 09:08:45 1.8
  @@ -1,4 +1,4 @@
  -/* $Id: PDFDocumentGraphics2D.java,v 1.7 2001/07/10 11:59:23 keiron Exp $
  +/* $Id: PDFDocumentGraphics2D.java,v 1.8 2001/07/24 09:08:45 keiron 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.
  @@ -16,6 +16,9 @@
   import java.awt.Font;
   import java.awt.Image;
   import java.awt.Color;
  +import java.awt.Shape;
  +import java.awt.font.FontRenderContext;
  +import java.awt.font.GlyphVector;
   import java.io.OutputStream;
   import java.io.IOException;
   
  @@ -27,7 +30,7 @@
* PDFGraphics2D.
*
* @author mailto:[EMAIL PROTECTED]";>Keiron Liddle
  - * @version $Id: PDFDocumentGraphics2D.java,v 1.7 2001/07/10 11:59:23 keiron Exp $
  + * @version $Id: PDFDocumentGraphics2D.java,v 1.8 2001/07/24 09:08:45 keiron Exp $
* @see org.apache.fop.svg.PDFGraphics2D
*/
   public class PDFDocumentGraphics2D extends PDFGraphics2D {
  @@ -55,12 +58,13 @@
OutputStream stream, int width, int height) {
   super(textAsShapes);
   
  -if(!textAsShapes) {
  +if (!textAsShapes) {
   fontInfo = new FontInfo();
   FontSetup.setup(fontInfo);
   try {
  -fontState = new FontState(fontInfo, "Helvetica", "normal", 
"normal", 12, 0);
  -} catch(FOPException e) {
  +fontState = new FontState(fontInfo, "Helvetica", "normal",
  +  "normal", 12, 0);
  +} catch (FOPException e) {
   }
   }
   standalone = true;
  @@ -80,6 +84,14 @@
   
   }
   
  +public FontState getFontState() {
  +return fontState;
  +}
  +
  +public PDFDocument getPDFDocument() {
  +return this.pdfDoc;
  +}
  +
   /**
* Set the dimensions of the svg document that will be drawn.
* This is useful if the dimensions of the svg document are different
  @@ -87,7 +99,8 @@
* The result is scaled so that the svg fits correctly inside the pdf document.
*/
   public void setSVGDimension(float w, float h) {
  -currentStream.write("" + PDFNumber.doubleOut(width / w) + " 0 0 " + 
PDFNumber.doubleOut(height / h) + " 0 0 cm\n");
  +currentStream.write("" + PDFNumber.doubleOut(width / w) +
  +" 0 0 " + PDFNumber.doubleOut(height / h) + " 0 0 
cm\n");
   }
   
   /**
  @@ -119,7 +132,7 @@

Re: Performance Problems

[Jeremias Maerki]

> I've noticed a bit of chat on the list the last few days concerning
> performance. I'm having a few problems in that area and I wondered if anyone
> had any suggestions. I have a 16 page document, consisting of text and
> embedded images, which is presently taking 30 seconds to generate. I've
> tried Mark's Fop.jar, which saves me about 4 to 6 seconds on this, but it
> still seems excessive. I think it has everything to
> do with the way I am invoking FOP.
> 
> I'm calling fop from the command line, using the runnable Jar. The call
> looks like this:
> 
> d:\jdk\bin\java.exe -classpath
> d:\jdk\lib\tools.jar;d:\jdk\lib\classes.zip;d:\fop\lib\ant.jar;d:\fop\lib\w3
> c.jar;d:\fop\lib\buildtools.jar;d:\fop\lib\xerces-1.2.3.jar;d:\fop\lib\xalan
> -2.0.0.jar;d:\fop\lib\xalanj1compat.jar;d:\fop\lib\bsf.jar;d:\fop\lib\jimi-1
> .0.jar;d:\fop\fop.jar;d:\fop\lib\xerces.jar;d:\fop\lib\xalan.jar;d:\fop\lib\
> bsf.jar -jar d:\fop\fop.jar -xml test.xml -xsl test.xsl -pdf test.pdf
> 
> The class path came from the RunTest.bat, which was the only example that I
> could find at the time. There's probably all sorts of things in there that I
> don't need.
> 
> When we first started playing with FOP, it was with Cocoon. The document we
> were testing with was only 5 pages, but the processing time was much less,
> only a few seconds. Because the cocoon distributable didn't cme with the
> latest FOP, and we wanted to use v0.19, we went for the command line option.
> It also fits in better with how we are using FOP. 
> 
> I apologise for being a Java ignoramus, but can anyone give me a pointer on
> what might be happening here?

That's because you're starting a new VM for every document you're
creating. First the VM is started (expensive operation), then all
classes have to be loaded which also takes a long time. Processing in
Cocoon was faster because all FOP classes were already loaded after the
first call. How to improve your situation depends on how FOP fits into
your project.

If your application is written in Java, I encourage you to look at
http://xml.apache.org/fop/embedding.html to see how to embed FOP into
your application. Of course, that means taking fop.jar and a few other
jars into your project class path.

Unfortunately, the page above only shows how to call FOP. The part where
XSLT comes into play is missing. I think you will find material on that
in the mailing list archive. Probably, this page will have to be
improved. Volunteers?


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]

RTF-FOP?

[Kin-Yip Tsang]

where can i get news about it?

marco

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

cvs commit: xml-fop/src/org/apache/fop/svg PDFGraphics2D.java

[keiron]

keiron  01/07/24 00:41:23

  Modified:src/org/apache/fop/svg PDFGraphics2D.java
  Log:
  Handles the graphics device better.
  Also handles the alpha transparency better, at least for white backgrounds
  it works properly
  
  Submitted by: Thomas E Deweese <[EMAIL PROTECTED]>
  Reviewed by:  Keiron Liddle
  
  Revision  ChangesPath
  1.11  +163 -18   xml-fop/src/org/apache/fop/svg/PDFGraphics2D.java
  
  Index: PDFGraphics2D.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/svg/PDFGraphics2D.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- PDFGraphics2D.java2001/07/10 11:59:24 1.10
  +++ PDFGraphics2D.java2001/07/24 07:41:23 1.11
  @@ -1,4 +1,4 @@
  -/* $Id: PDFGraphics2D.java,v 1.10 2001/07/10 11:59:24 keiron Exp $
  +/* $Id: PDFGraphics2D.java,v 1.11 2001/07/24 07:41:23 keiron 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."
  @@ -14,6 +14,7 @@
   import org.apache.fop.datatypes.ColorSpace;
   
   import org.apache.batik.ext.awt.g2d.*;
  +import org.apache.batik.ext.awt.image.GraphicsUtil;
   
   import java.text.AttributedCharacterIterator;
   import java.text.CharacterIterator;
  @@ -38,7 +39,7 @@
* implementing a Graphic2D piece-meal.
*
* @author mailto:[EMAIL PROTECTED]";>Keiron Liddle
  - * @version $Id: PDFGraphics2D.java,v 1.10 2001/07/10 11:59:24 keiron Exp $
  + * @version $Id: PDFGraphics2D.java,v 1.11 2001/07/24 07:41:23 keiron Exp $
* @see org.apache.batik.ext.awt.g2d.AbstractGraphics2D
*/
   public class PDFGraphics2D extends AbstractGraphics2D {
  @@ -170,22 +171,32 @@
   
   int count = 0;
   int maskpos = 0;
  +int [] iarray;
  +int i, j, val, alpha, add, mult;
   switch (bd.getDataType()) {
   case DataBuffer.TYPE_INT:
   int[][] idata = ((DataBufferInt) bd).getBankData();
  -for (int i = 0; i < idata.length; i++) {
  -for (int j = 0; j < idata[i].length; j++) {
  +for (i = 0; i < idata.length; i++) {
  +iarray = idata[i];
  +for (j = 0; j < iarray.length; j++) {
  +val = iarray[j];
  +alpha = val >>> 24;
   //mask[maskpos++] = (byte)((idata[i][j] >> 24) & 0xFF);
  -if (((idata[i][j] >> 24) & 0xFF) != 255) {
  -result[count++] = (byte) 0xFF;
  -result[count++] = (byte) 0xFF;
  -result[count++] = (byte) 0xFF;
  +if (alpha != 255) {
  +// System.out.println("Alpha: " + alpha);
  +// Composite with opaque white...
  +add = (255 - alpha);
  +mult = (alpha << 16) / 255;
  +result[count++] = (byte)(add +
  + val >> 16) & 0xFF) * mult) 
>> 16));
  +result[count++] = (byte)(add +
  + val >> 8) & 0xFF) * mult) 
>> 16));
  +result[count++] = (byte)(add +
  + val) & 0xFF) * mult) 
>>16));
   } else {
  -result[count++] =
  -  (byte)((idata[i][j] >> 16) & 0xFF);
  -result[count++] =
  -  (byte)((idata[i][j] >> 8) & 0xFF);
  -result[count++] = (byte)((idata[i][j]) & 0xFF);
  +result[count++] = (byte)((val >> 16) & 0xFF);
  +result[count++] = (byte)((val >> 8) & 0xFF);
  +result[count++] = (byte)((val) & 0xFF);
   }
   }
   }
  @@ -905,12 +916,12 @@
boolean nonzero) {
   if (fill) {
   if (stroke) {
  -if (!nonzero)
  +if (nonzero)
   currentStream.write("B*\n");
   else
   currentStream.write("B\n");
   } else {
  -if (!nonzero)
  +if (nonzero)
   currentStream.write("f*\n");
   else
   currentStream.write("f\n");
  @@ -926,9 +937,143 @@
* Graphics2D.
*/
   public GraphicsConfiguration getDeviceConfiguration() {
  -//System.out.println("getDeviceConviguration");
  -return GraphicsEnvironment.ge

Performance Problems

[Darren Munt]

I've noticed a bit of chat on the list the last few days concerning
performance. I'm having a few problems in that area and I wondered if anyone
had any suggestions. I have a 16 page document, consisting of text and
embedded images, which is presently taking 30 seconds to generate. I've
tried Mark's Fop.jar, which saves me about 4 to 6 seconds on this, but it
still seems excessive. I think it has everything to
do with the way I am invoking FOP.

I'm calling fop from the command line, using the runnable Jar. The call
looks like this:

d:\jdk\bin\java.exe -classpath
d:\jdk\lib\tools.jar;d:\jdk\lib\classes.zip;d:\fop\lib\ant.jar;d:\fop\lib\w3
c.jar;d:\fop\lib\buildtools.jar;d:\fop\lib\xerces-1.2.3.jar;d:\fop\lib\xalan
-2.0.0.jar;d:\fop\lib\xalanj1compat.jar;d:\fop\lib\bsf.jar;d:\fop\lib\jimi-1
.0.jar;d:\fop\fop.jar;d:\fop\lib\xerces.jar;d:\fop\lib\xalan.jar;d:\fop\lib\
bsf.jar -jar d:\fop\fop.jar -xml test.xml -xsl test.xsl -pdf test.pdf

The class path came from the RunTest.bat, which was the only example that I
could find at the time. There's probably all sorts of things in there that I
don't need.

When we first started playing with FOP, it was with Cocoon. The document we
were testing with was only 5 pages, but the processing time was much less,
only a few seconds. Because the cocoon distributable didn't cme with the
latest FOP, and we wanted to use v0.19, we went for the command line option.
It also fits in better with how we are using FOP. 

I apologise for being a Java ignoramus, but can anyone give me a pointer on
what might be happening here?

Thanks.

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