Re: tables with margins and borders
Hello, Hello Karen, I tried it with the snapshot of the night before yesterday (due to the firewall I cannot get into CVS directly). It was not rendered correctly. I have included the document (doc.xml) and the stylesheet (doc2pdf.xsl) that lead to docxalan.fo If rendered to awt few borders are rendered and those rendered are not aligned with the table. If rendered to pdf all borders ara rendered but all are not aligned with the table. The version I'm using is from a file called xml-fop_20010806101537.tar.gz (it is stating FOP 0.19.0-CVS at startup) Kind regards, Koen. Please respond to [EMAIL PROTECTED] |--- | | | |--- ---| | | ---| |--- | To: | | |--- ---| | [EMAIL PROTECTED] | ---| |--- | cc: | | |--- ---| | (bcc: Koen HANDEKYN/BE/ALCATEL) | ---| |--- | | | |--- ---| | | ---| |--- | Subject: | | |--- ---| | Re: tables with margins and borders | ---| [IMAGE] Hi Koen, There are some table-border fixes in both PDF and AWT in the latest CVS which probably fix this problem. Try using one of the recent source snapshots if you can't wait for the 0.20 release. Or you can send your .fo file and I'll see whether it still looks bad with the current version. Hope that helps, Karen Lease [EMAIL PROTECTED] wrote: Hello, I'm using version 0.19.0 from the distribution directory.
running without batik (was logging)
This would require the element mappings to handle things a bit better, fairly easy. The other part is to setup some sort of render factory for foreign data handling (in fo:instream-foreign-object and external graphics). This would need a bit of work and time. Another issue might be the size of the hyphenation (about 1.1Mb) in fop.jar. On Mon, 06 Aug 2001 17:35:25 Alistair Hopkins wrote: +1 to that And while we're here, is there any way to switch OFF SVG support so the batik jar is dispensible? I'm using fop as the printing API for a desktop/Swing app and it is brilliant (proper print preview, high quality saved and printed documents, easy format to build with) but the size of the jars is quite a big issue: it's about 80% of the size of the application right now! More jars are not needed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Different result on Win2K and win98!!!
Hi,
I designed an xsl-fo at work with win2k. It works nice and smooth, the
result is exactly what I want.
I wanted to do some work at home (on a win 98 PC) and the result is
different.
My xml file is someting like this:
school name = Don Bosco
class
class_nameMath/class_name
groupScience/group
teacher rank = level3John Smith/teacher
...
/class
class
...
the xsl process gives table for each group with all the teacher, and tables
for each teacher with all the groups he is in. I need to use a for-each
with a key to have the list with having multiple row with the same values:
xsl:for-each select=key('teacher-group', teacher)[not(concat(teacher,
group)=concat(preceding::teacher, preceding::group))]
With win2k, I have the tables as I want to. In win98, I have the groups as
many times as there are teachers in the group.
I use FOP this way:
c:\jdk1.3.1\bin\java -cp e:\Fop-0.19.0-CVS\fop.jar org.apache.fop.apps.Fop
-xsl e:\testxml\school.xsl -xml e:\testxml\school.xml -pdf e:
\testxml\school.pdf
any idea what's wrong? The rendering is good but it seems that the xsl
processing sucks with FOP and win98. I have the same version of java (SUN
jdk 1.3.1), the same version of Xalan (j2.2.D6). I even upgradded the msxml
on my win98 (useless but how knows...). I checked my path and classpath.
I'm lost and the FOP FAQ is not yet available to me... ;o)
Cheers
Emmanuel Ponette
Euro DB
Place de l'Université, 16
B-1348 Louvain-La-Neuve
Phone: +32 10 47 67 44
Fax: +32 10 47 67 67
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Newbie attempting to help
Total agreement to everything Keiron just said.
However, that's not to say that we can't work up something that meets your
needs for 'keep-together' on fo:list-item. It's usually possible to take
care of a specific; as Keiron says it's the general case (making keeps work
everywhere that they are supposed to) that is rather more of an obstacle. I
have some ideas in regard to how you might want to tackle the problem you
describe and will elaborate this evening.
Regards,
Arved Sandstrom
At 09:38 AM 8/7/01 +0200, Keiron Liddle wrote:
Your help is very welcome.
Unfortunately the the solution to the problem is not that easy. This is one
area that fop does not handle very well and we are in search of a solution.
The problem of keeps (and space resolution etc.) is one that spans across
the fo heirarchy in a number of directions. This makes it difficult to
handle without a rehash of how the layout is organised.
An effort is underway in this direction but there seems to be a fair amount
of resistance to change (from fop).
Hope this doesn't put you off.
On Tue, 07 Aug 2001 03:21:14 Don Wellington wrote:
Hi-
Well, I am trying to make my first contribution to
FOP. By working on bug 2988 which I submitted. I
willingly accept any and all help.
I tried forcing the status return from
ListItemLabel.layout to keep-with-next in an attempt
to force other code to handle keeping the
list-item-label and list-item-body together. That
didn't work, but keep-with-next is broken anyways, so
that is probably not unexpected. My thought right
now is to change
the end of ListItemLabel.layout to:
if(status == Status.OK) {
status = new Status(Status.KEEP_WITH_NEXT);
}
return status;
At least temporally, until I figure how to get FOP to
obey the keep_with_next when there is an
external-graphics as the first element in the
list-item-body.
Anything wrong with that? Any pointers in the right
direction?
Don Wellington
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
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]
Different Header Content
hi all, I have used FOP 0-19-0.CVS in generating of pdf file from xml. And, I have a problem here, that is how can I put different header content in bibliography page and the rest pages of a document? The attactment is the xsl that I have generated, any problems? Thanks for any help you can give. best rgds, ektan (See attached file: diffHeader2.xsl) diffHeader2.xsl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
Hello Koen I may be able to help with ~part~ of this. The latest version of AWTRender fails to draw a border at all for your .fo file. However, the border re-appears if you increase the border-size to 1.0pt. This may be a (bad) side effect of changes we recently made to the awt render to respect border-size (previously it drew all borders 1 pixel thick regardless of the value of border-size.) My hunch is the thickness calculation is rounding down to zero. [ aside: We will investigate and supply a patch later today if appropriate. The awt renderer should probably render a border one pixel thick when the math rounds to zero. Any comments? ] As for the ~placement~ of the borders, others will need to comment on that. At first glance, it looks to me that the pdf and awt renderers both put the borders in the same wrong place. Which suggests the problem is not in the renderers themselves. One more comment, however, it looks like your table is buried 3 or 4 levels deep in fo:blocks. While that is probably legal, my own experience is that nesting fo:blocks too deeply can lead to spacing and placement problems. As a workaround, you might want to try embedding your table in a single level fo:block -- perhaps that would improve the border placement. ' Best, -Ralph LaChance At 08:19 AM 8/7/01 +0200, you wrote: Hello, I tried it with the snapshot of the night before yesterday (due to the firewall I cannot get into CVS directly). It was not rendered correctly. I have included the document (doc.xml) and the stylesheet (doc2pdf.xsl) that lead to docxalan.fo If rendered to awt few borders are rendered and those rendered are not aligned with the table. If rendered to pdf all borders ara rendered but all are not aligned with the table. The version I'm using is from a file called xml-fop_20010806101537.tar.gz (it is stating FOP 0.19.0-CVS at startup) Kind regards, Koen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tree class: advice please.
Dear Listners,
I have attached the latest iteration of Tree.java. I saw that Mark was
bypassing part of the FO tree, I think it was. At any rate, with
dynamic rendering, there was a need to be able to delete a subtree. The
methods are deleteSubTree and delete.
Looking at applying Tree to the FO tree, I quickly ran into the
limitations of my Java knowledge. Tree at the moment is a top-level
class with a member class Node. Node, in turn, has member classes which
provide the various Iterators. It seemed a good idea at the time,
Iterators being all the rage.
When I came to look at the application of this, I thought that making
classes FOTree and FONode, where FONode is a member class of FOTree,
would be useful. The problem is that I can't seem to arrange to inherit
from a member class unless I that inheritance occurs within the context
of an enclosing class which inherits from the parallel enclosing class.
I.e., given Tree with a member class Node, I can have a class FONode
inherit from Node, provided FONode is a member class of FOTree, which
inherits from Tree.
Currently FONode is an abstract class, the foundation of all of the FObj
classes. Every time I want to subclass FONode, I would have to do it as
an member class of a subclass of FOTree.
There seems to be two alternatives.
One is to split Tree and Node, prohibiting orphan Nodes by having only
constructors with a reference to a Tree as an argument. Node can then
be inherited, with all of the tree manipulation being done back in the
superclass. One advantage of this is that Object contents can be
ignored, and FONode and its subclasses defined in much the same way.
(Except that all the implicit tree operations must be re-specified in
terms of Tree and Node.) One question that arises from this is whether
to retain the classes which implement the tree traversal iterators, of
to recast them as Node methods.
The other alternative is to use the generic Tree/Node class directly to
define both the FOTree and the AreaTree. All of the inheritance would
then be done throught the contents object, which would require a
reference to its enclosing Node. The object and its wrapper Node would
have to be created in two operations at the time of creation of the object.
As I write this, the former option sounds better.
Any comments?
Peter
--
Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest
Lord, to whom shall we go?
/*
* $Id: Tree.java,v 1.20 2001-08-07 15:43:57+10 pbw Exp pbw $
* 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.
*/
//package org.apache.fop.datatypes;
import java.util.*;
// TODO:
// Should I provide a separate or supplementary exception for CoMods appends
// on the trailing edge of the tree? I.e., for each append, check if it is an
// append to a node which is the final sibling at any level of the tree.
// If so, set a copy the modCount value as the trailingEdgeModAge.
// If a ConcurrentModificationException is about to be thrown, check whether
// the trailingEdgeModAge is the same as the modCount. If so, throw a
// ConcurrentTreeAppendException instead. Probably, make that a subclass of
// ConcurrentModificationException so that the check can be done on the
// catch of the CoModEx.
/**
* Tree.java
*
* The ttTree/tt class is analogous to one of the ttCollection/tt
* 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 ttNode/tt
* elements.
*
*
* The primary reasons for the existence of a separate ttTree/tt
* class is to provide an object for tree-wide synchronization, and to
* have a home for ttmodCount/tt for the provision of
* ifast-fail/i iterators. For more details, see the
* discussion of ttmodCount/tt in ttAbstractList/tt.
*
* @author a href=mailto:[EMAIL PROTECTED];Peter B. West/a
* @version
*/
public class Tree {
/**
* The number of times the tree has been istructurally modified/i.
* See the discussion of the ttmodCount/tt field in
* ttAbstractList/tt.
*/
protected int modCount = 0;
protected int nodeCount = 0;
protected Node root;
public Tree() {}
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 ==
[Bug 1952] - color attribute to table content overflowing on next page
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1952 *** shadow/1952 Fri Jun 1 08:04:59 2001 --- shadow/1952.tmp.15845 Tue Aug 7 04:32:58 2001 *** *** 4,13 |Bug #: 1952Product: Fop | | Status: NEW Version: all | | Resolution:Platform: PC | ! | Severity: Critical OS/Version: | ! | Priority: Component: pdf renderer| ++ ! | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED]| | CC list: Cc: | ++ --- 4,13 |Bug #: 1952Product: Fop | | Status: NEW Version: all | | Resolution:Platform: PC | ! | Severity: Critical OS/Version: All | ! | Priority: High Component: pdf renderer| ++ ! | Assigned To: [EMAIL PROTECTED]| | Reported By: [EMAIL PROTECTED]| | CC list: Cc: | ++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 2491] - footnote can't fit remaining space and crash
PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2491 *** shadow/2491 Fri Jul 6 17:28:08 2001 --- shadow/2491.tmp.15858 Tue Aug 7 04:34:43 2001 *** *** 7,13 | Severity: Critical OS/Version: Other | | Priority: Other Component: pdf renderer| ++ ! | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | | CC list: Cc: | ++ --- 7,13 | Severity: Critical OS/Version: Other | | Priority: Other Component: pdf renderer| ++ ! | Assigned To: [EMAIL PROTECTED]| | Reported By: [EMAIL PROTECTED] | | CC list: Cc: | ++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Nesting tables in FOP
I am using FOP 0-19-0.CVS and having problems nesting tables. Just as a simple test I am trying to place one table inside a block, within a single outer table cell. The PDF output does display the values, but entirely ignores the inner table structure by placing the values on a single row. I have seen some of the other discussions on this issue, eg, setting column widths, yet have not been able to resolve the problem. Attached is the xsl fragment. Does anyone know how to overcome this, or have an example of code that will give me something to work from? Many thanks Vicki Test_fo_5.xsl Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Pb running FOP
Hi, I cannot access the FOP-FAQ on the xml.apache.org web site, concerning the use of FOP, so I write directly to this list. I would like to apologise in advance because I am a real beginner in this field and I might not be using the right channel to ask my questions (let me know if this is the case). Situation: I have installed sun java v 1.31. I have transformed an .xml document into a .fo document using an .xsl document (with msxsl command line). I now try to transform this .fo document into a.pdf document. I have also installed msxml v 3. Problem: To do the transformation, I am using this command: java -jar fop.jar doc.fo doc.pdf -d I then got a lot of error messages (Using SAX Parser org.apache.xerces.parsers.SAXParser - Building formatting object tree - Warning: Unknown formatting object- ERROR: nul). Questions: Is this the right way to process an .fo file? Do I need to install something else to make things working? What else should I do? Thank you in advance and sorry if this question has nothing to do on this list. Arnaud Carrard. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AWTRenderer patch
Hi,
Below is a patch to prevent AWTRender from drawing an invisible
border when the value for border-width is too small. The patch
basically says that no matter how small the border-width is, it will
always render at least 1 pixel on the target graphics context.
I leave it to others to rule on the correctness of this approach
(makes sense to me) and thereby commit the patch or not.
Note however that for the sample fo attached,
(border-width is 0.1pt) both -awt and -print
fail to render a border, while -pdf does.
[Separate problem that the borders are in the wrong place
for all renderers..]
The attached sample fo was submitted to this list earlier by
[EMAIL PROTECTED]
' Best,
-Ralph LaChance
-- patch
/**
* draw a filled rectangle in the current color.
* Force 1 pixel wide area if the size rounds to zero.
*
* @param x the x position of left edge in millipoints
* @param y the y position of top edge in millipoints
* @param w the width in millipoints
* @param h the height in millipoints
* @param drawAsOutline true for draw, false for fill
*/
// helper function by aml/rlc to correct integer roundoff problems
//
protected void addRect(int x, int y, int w, int h,
boolean drawAsOutline) {
int startx = (x + 500) / 1000;
int starty = pageHeight - ((y + 500) / 1000);
int endx = (x + w + 500) / 1000;
int endy = pageHeight - ((y + h + 500) / 1000);
if (drawAsOutline)
graphics.drawRect(startx, starty, endx - startx, endy - starty);
else
{
//don't round down to zero
if (w != 0 endx == startx) endx++;
if (h != 0 endy == starty) endy++;
graphics.fillRect(startx, starty, endx - startx, endy - starty);
}
}
---
?xml version=1.0 encoding=UTF-8?
fo:root
xmlns:fo=http://www.w3.org/1999/XSL/Format;fo:layout-master-setfo:simple-page-master
margin-right=1cm margin-left=1cm margin-bottom=1cm margin-top=1cm
master-name=cover-pagefo:region-body
display-align=center//fo:simple-page-masterfo:simple-page-master
margin-right=1cm margin-left=1cm margin-bottom=1cm margin-top=1cm
master-name=plain-pagefo:region-body margin-right=1.5cm margin-left=1.5cm
margin-top=14pt/fo:region-before extent=1.5cm/fo:region-after
extent=1.5cm//fo:simple-page-masterfo:page-sequence-master
master-name=coverfo:single-page-master-reference
master-name=cover-page//fo:page-sequence-masterfo:page-sequence-master
master-name=tocfo:single-page-master-reference
master-name=plain-page//fo:page-sequence-masterfo:page-sequence-master
master-name=bodyfo:single-page-master-reference
master-name=plain-page//fo:page-sequence-master/fo:layout-master-setfo:page-sequence
master-name=coverfo:flow flow-name=xsl-region-bodyfo:block
text-align=centerDocument Title/fo:blockfo:block text-align=center/fo:block
text-align=center/fo:block
text-align=centerAlcatel/fo:block/fo:flow/fo:page-sequencefo:page-sequence
master-name=tocfo:flow flow-name=xsl-region-bodyfo:blockTable of
Contents:/fo:blockfo:block1 part titlefo:leader
leader-pattern=dots/fo:page-number-citation ref-id=N11/fo:block1.1 Part
Titlefo:leader leader-pattern=dots/fo:page-number-citation
ref-id=N19/fo:block1.1.1 Part Titlefo:leader
leader-pattern=dots/fo:page-number-citation
ref-id=N3F//fo:block/fo:blockfo:block1.2 Part Titlefo:leader
leader-pattern=dots/fo:page-number-citation
ref-id=N88//fo:block/fo:blockfo:block2 part titlefo:leader
leader-pattern=dots/fo:page-number-citation
ref-id=N92//fo:block/fo:flow/fo:page-sequencefo:page-sequence
master-name=bodyfo:static-content flow-name=xsl-region-afterfo:block
text-align=center
p. fo:page-number/ /
fo:page-number-citation ref-id=terminator//fo:block/fo:static-contentfo:flow
flow-name=xsl-region-bodyfo:block id=N11/
fo:block space-after.optimum=8pt space-before.optimum=8pt
color=white background-color=black end-indent=0cm padding-bottom=0pt
padding-top=2pt text-align=center font-size=16pt start-indent=0cm1 part
title/fo:block
fo:block space-after.optimum=6pt space-before.optimum=6pt
text-align=justifyA paragraph./fo:block
fo:block id=N19 margin-left=1cm#10;
fo:block space-after.optimum=8pt space-before.optimum=8pt
color=white background-color=black end-indent=0cm padding-bottom=0pt
padding-top=2pt text-align=center font-size=16pt start-indent=1cm1.1 Part
Title/fo:block
fo:block space-after.optimum=6pt space-before.optimum=6pt
text-align=justifyThis is paragraph./fo:block
fo:block text-align=centerfo:external-graphic
src=alcatel_logo.jpg/fo:block
linefeed-treatment
Curious: I'm using the docbook-xsl-1.14 tools from docbook.sourceforge.net to convert a DocDook XML file into xsl:fo and then using FOP to convert that into PDF. I've noticed FOP printing messages like this: warning: property - linefeed-treatment is not implemented yet. it turns out that docbook-xsl is using that attribute on the fo:block elements it creates out of my screen DocBook elements. Is linefeed-treatment handling on the radar screen? I'm getting the correct output, so I'm wondering if by setting white-space-collapse='false' in the fo:block, docbook-xsl is causing FOP to do the right thing? Is it true that white-space-collapse='false' implies the same effect as linefeed-treatment='preserve'? 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]
Re: Pb running FOP
Hi Arnaud, That's about right, but try putting the -d argument before the doc.fo and doc.pdf. Hopefully you will get a better debugging message. It sounds like your .fo file has an unknown object in it, although the message isn't very helpful. You might want to include your .fo file with your message so one of us can take a look at it. Regards, Karen Lease Arnaud Carrard wrote: Hi, I cannot access the FOP-FAQ on the xml.apache.org web site, concerning the use of FOP, so I write directly to this list. I would like to apologise in advance because I am a real beginner in this field and I might not be using the right channel to ask my questions (let me know if this is the case). Situation: I have installed sun java v 1.31. I have transformed an .xml document into a .fo document using an .xsl document (with msxsl command line). I now try to transform this .fo document into a.pdf document. I have also installed msxml v 3. Problem: To do the transformation, I am using this command: java -jar fop.jar doc.fo doc.pdf -d I then got a lot of error messages (Using SAX Parser org.apache.xerces.parsers.SAXParser - Building formatting object tree - Warning: Unknown formatting object- ERROR: nul). Questions: Is this the right way to process an .fo file? Do I need to install something else to make things working? What else should I do? Thank you in advance and sorry if this question has nothing to do on this list. Arnaud Carrard. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - 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: Different result on Win2K and win98!!!
Hi Emmanuel,
As you say, the problem seems to be in processing the XSL. That isn't
really done by FOP, except by calling Xalan (or some other kind of Trax
compliant transformer.)
Sounds like one of two things: obscure classpath problem or problem with
the Sun JDK 1.3.1 itself on Win98. Do you have any jars in the ext
directory (c:\jdk1.3.1\lib\ext)? What is your CLASSPATH environment
variable set to? If all else fails, you might try generating the FO file
separately (maybe with MSXML for example if that works) and then just
using FOP directly on the FO file.
HTH,
Karen
[EMAIL PROTECTED] wrote:
Hi,
I designed an xsl-fo at work with win2k. It works nice and smooth, the
result is exactly what I want.
I wanted to do some work at home (on a win 98 PC) and the result is
different.
My xml file is someting like this:
school name = Don Bosco
class
class_nameMath/class_name
groupScience/group
teacher rank = level3John Smith/teacher
...
/class
class
...
the xsl process gives table for each group with all the teacher, and tables
for each teacher with all the groups he is in. I need to use a for-each
with a key to have the list with having multiple row with the same values:
xsl:for-each select=key('teacher-group', teacher)[not(concat(teacher,
group)=concat(preceding::teacher, preceding::group))]
With win2k, I have the tables as I want to. In win98, I have the groups as
many times as there are teachers in the group.
I use FOP this way:
c:\jdk1.3.1\bin\java -cp e:\Fop-0.19.0-CVS\fop.jar org.apache.fop.apps.Fop
-xsl e:\testxml\school.xsl -xml e:\testxml\school.xml -pdf e:
\testxml\school.pdf
any idea what's wrong? The rendering is good but it seems that the xsl
processing sucks with FOP and win98. I have the same version of java (SUN
jdk 1.3.1), the same version of Xalan (j2.2.D6). I even upgradded the msxml
on my win98 (useless but how knows...). I checked my path and classpath.
I'm lost and the FOP FAQ is not yet available to me... ;o)
Cheers
Emmanuel Ponette
Euro DB
Place de l'Université, 16
B-1348 Louvain-La-Neuve
Phone: +32 10 47 67 44
Fax: +32 10 47 67 67
-
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: tables with margins and borders
Koen (and Ralph and others), There is a problem, but it's not a border-drawing problem. You have a left-margin specified as 2cm on a block which is containing the paragraphs before the table and the table itself. This property is inherited and is therefore used on both the fo:table and the fo:blocks inside the fo:table-cell objects. What isn't normal is that the table itself should be indented by 2cm and it isn't. But that in itself won't fix the cell text alignment, since the margin (or start-indent which is the same thing) is being inherited by all the content inside the table. So the cell content would still be badly positioned. Assuming that FOP handled indent correctly on the table, you would want to set it back to a smaller value, on table-body for example. In the meantime, there is an ugly workaround involving an empty first column whose width is equal to the current indent and which only has borders on the right side. As Arved has just suggested focusing on tables, this problem will be a good place to start and I'll try to put it on the high priority list. Regards, Karen [EMAIL PROTECTED] wrote: Hello, Hello Karen, I tried it with the snapshot of the night before yesterday (due to the firewall I cannot get into CVS directly). It was not rendered correctly. I have included the document (doc.xml) and the stylesheet (doc2pdf.xsl) that lead to docxalan.fo If rendered to awt few borders are rendered and those rendered are not aligned with the table. If rendered to pdf all borders ara rendered but all are not aligned with the table. The version I'm using is from a file called xml-fop_20010806101537.tar.gz (it is stating FOP 0.19.0-CVS at startup) Kind regards, Koen. Please respond to [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
At 06:53 PM 8/7/01 +0200, you wrote: Koen (and Ralph and others), There is a problem, but it's not a border-drawing problem. Karen, Sorry, I wasn't clear -- I'm suggesting there are ~two~ separate problems here. The first is what you describe below. The second is: given the fo such as it is, it renders differently for -print and -awt versus -pdf. On both -awt and -print no border is drawn for the table cells. The pdf renderer ~does~ draw the table borders. The awt/print problem is due to AWTRenderer attmpting to fill a rectangle with either the width or height of zero. This happens when the border size drops below a threshold (i.e., 500 millipts) This all stems from a patch to AWTRender I supplied a few weeks ago in which, among other things, we made AWTRenderer honor actual border sizes. (The original 0.19.0 AWTRenderer drew ~all~ borders 1 pixel thick, regardless of border-size.) Does this make sense to you ? If so, I supplied a patch earlier today to fix it. You have a left-margin specified as 2cm on a block which is containing the paragraphs before the table and the table itself. This property is inherited and is therefore used on both the fo:table and the fo:blocks inside the fo:table-cell objects. What isn't normal is that the table itself should be indented by 2cm and it isn't. But that in itself won't fix the cell text alignment, since the margin (or start-indent which is the same thing) is being inherited by all the content inside the table. So the cell content would still be badly positioned. Assuming that FOP handled indent correctly on the table, you would want to set it back to a smaller value, on table-body for example. In the meantime, there is an ugly workaround involving an empty first column whose width is equal to the current indent and which only has borders on the right side. As Arved has just suggested focusing on tables, this problem will be a good place to start and I'll try to put it on the high priority list. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Table Status (was Re: problems with height of cells in tables)
Hi Arved (and other interested parties), Lots of other bugs (like the inline-area height) show up well in tables because the grid makes things visible. That's the case with the trailing white-space bug I saw the other day, resulting in an empty table row. Some of these can also be shown by using border, padding and background on fo:block, which also needs more test cases. I think base-level table functionality has gotten considerably better, and we need to publicize that with the next release, since there have been so many problems in the past releases. Of course, I know there are still a number of bugs, but I think the row-spanning, vertical alignment and general border-handling improvements should help lots of people. Off the top of my head, here are major areas for work: 1. border-collapse=collapse. There is a partial bandaid for this now. I've written a lot of pseudo-code for this, as the general case is quite complex. It should take into account cell, row and column borders (though I'd like to see the final word in the PR on this). As often, I ran up against the problem of handling the break conditions, since that can affect the borders. But unless someone else has done lots of work here or has some easy improvements, I'd like to keep it on my plate (after vacation). 2. Keeps and breaks. There are some cases where breaks cause problems; as I recall the culprit is in table-body. I know the general problem of keeps can't really be handled, but tables are a particularly sore point for that. It's worth trying to do keep-together for table-row; actually I think I did a first pass on this when I did spans. 3. Handling limit conditions, like table-row with keeps but which doesn't fit on the page. 4. Indents. Just looked at Koen's bug, which involves the indents not affecting the table itself, but rather the cell content. My reading of the CR is that the areas created by fo:table are block areas and should be positioned by indents. Lots of people also want to center their tables; I can't figure out how this is supposed to happen, unless it's in table-and-capation. 5. The table-and-caption fo. 6. Row-less tables using start-row and end-row properties on the cells. I think this can be handled in addChild for the table-body by creating fake TableRow objects as needed. 7. Automatic table layout style (this is a fairly big deal). Or at least really implement the percentage stuff, which would be simpler and still quite flexible. This needs some work in calculating the column widths once the size of the containing reference area is known. 8. The relative-align style for vertical alignment. Needs post-processing once all cells in the row are done. Might as well wait until we get our line-stacking straightened out. That should keep people thinking for a while... There are also a few remarks below. I'll be away from my Internet access for a while, so this is probably it for now. Overall the idea seems good. Obviously if I've temporarily let go of bottom-up layout, it was to try to reduce the volume of table-related complaints. Regards and a bientot Karen Arved Sandstrom wrote: Hi, Karen (and other interested parties) A thought occurred to me just now. A high percentage of our bandwidth (and bug reports) are devoted to tables. There are so many table-related bug reports mainly because so many folks want to use tables, I believe, not because there are more bugs in tables than elsewhere. I'm thinking that perhaps we can use table support as the centrepiece for all of our FOP efforts. In order to have tables be fully supported, and work properly, a really big percentage of the XSL specification (and FOP mechanics) gets exercised. Redesign of layout is something of a fuzzy goal; making tables work isn't. You've currently got probably the best perspective on tables. What I am thinking would be useful would be a report concerning table FOs, with a property-by-property breakdown, that assesses what works, and what doesn't, and what needs to happen in order to make things work. This could drive a whole bunch of tasks that people could take on. It would be easier to gauge the progress of FOP, because table support would be a bellwether for FOP as a whole. This doesn't mean that everything else would be ignored. But the shift of emphasis would be as follows: if I want to work on markers, I make sure that they work inside fo:table-and-caption, fo:table, fo:table-caption, fo:table-header, fo:table-footer, fo:table-body, and fo:table-cell. If someone wants to make sure FO X works, they make sure it works also as a descendant of fo:table-cell. Keiron has laid the groundwork for testing - a really suitable area for a first comprehensive set of test-cases could be (you guessed it) tables! :-) KL: Agreed. I started to do some test cases, but then discovered I needed to add more properties to the AreaTree concerning borders and padding. I didn't get around to doing this, so we can put
RE: Pb running FOP
I had a similiar problem to this when running an FO file output from MSXML through FOP. If my memory serves correctly, it was caused by the encoding, which is UTF-16 by default. You need to set it to UTF-8. This may be because MSXML by default places some binary data in the first byte or two of the file that FOP doesn't like. Sorry I don't have more precise details on this - I had the problem, I tried changing the encoding, it worked, I moved on. -Original Message- From: Arnaud Carrard [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 7 August 2001 6:18 To: [EMAIL PROTECTED] Subject: Pb running FOP Hi, I cannot access the FOP-FAQ on the xml.apache.org web site, concerning the use of FOP, so I write directly to this list. I would like to apologise in advance because I am a real beginner in this field and I might not be using the right channel to ask my questions (let me know if this is the case). Situation: I have installed sun java v 1.31. I have transformed an .xml document into a .fo document using an .xsl document (with msxsl command line). I now try to transform this .fo document into a.pdf document. I have also installed msxml v 3. Problem: To do the transformation, I am using this command: java -jar fop.jar doc.fo doc.pdf -d I then got a lot of error messages (Using SAX Parser org.apache.xerces.parsers.SAXParser - Building formatting object tree - Warning: Unknown formatting object- ERROR: nul). Questions: Is this the right way to process an .fo file? Do I need to install something else to make things working? What else should I do? Thank you in advance and sorry if this question has nothing to do on this list. Arnaud Carrard. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
