Re: Redesign issues
Arved Sandstrom wrote: I actually helped push for this last year - the notion of separate layout managers. I was strongly influenced by the mess that FOP code had become at the time, and really thought that layout should be taken out of the FOs themselves; that the FO's, in a sense, were (or should be) just value objects. I worked on an xslfo-proc prototype (in Perl) for months earlier this year. I started out with the layout manager idea. It became increasingly clear to me that there was in fact a natural 1-1 correspondence between managers and FOs. I had a prototype, incidentally, which properly handled reference-orientation in all regions, and even took RO down to block-containers, something which no implementation (not FOP, not XEP, not XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly, which I don't know. It's also interesting, Joerg, that you should mention a hard to understand layout manager class hierarchy...this is also what inevitably developed in my prototype. So at some point (and I think there are comments and emails to support this) I eventually came back to the thought that there is nothing wrong with individual FOs being able to do their own layout. Which is actually the existing maintenance stream FOP model. Here are a couple. I remembered these exchanges, and was wondering whether you might mention them in this context. http://sourceforge.net/mailarchive/forum.php?thread_id=740835forum_id=450 http://sourceforge.net/mailarchive/message.php?msg_id=1780417 Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
On Mon, 2002-12-09 at 01:00, Arved Sandstrom wrote: I actually helped push for this last year - the notion of separate layout managers. I was strongly influenced by the mess that FOP code had become at the time, and really thought that layout should be taken out of the FOs themselves; that the FO's, in a sense, were (or should be) just value objects. I worked on an xslfo-proc prototype (in Perl) for months earlier this year. I started out with the layout manager idea. It became increasingly clear to me that there was in fact a natural 1-1 correspondence between managers and FOs. I had a prototype, incidentally, which properly handled reference-orientation in all regions, and even took RO down to block-containers, something which no implementation (not FOP, not XEP, not XSLFormatter, not XFC) has correctly done. Unless Epic handles RO correctly, which I don't know. It's also interesting, Joerg, that you should mention a hard to understand layout manager class hierarchy...this is also what inevitably developed in my prototype. So at some point (and I think there are comments and emails to support this) I eventually came back to the thought that there is nothing wrong with individual FOs being able to do their own layout. Which is actually the existing maintenance stream FOP model. I still believe that it is useful to have the layout managers separate from the fo tree. There are a number of reasons that come to mind. It is possible to independantly change layout managers. Certain fo's aren't directly in the same hierarchy: markers, undefined table columns, table cells under table body. Then there are things like floats and footnotes that can gain from this. I'll have some more to say laterthese are immediate comments. I am just struck by the fact that it is now December 2002 and we are not where we want to be, not even close, which is providing an open-source Extended conformance XSL processor to the hungry, huddled and poor. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Hi Joerg, These are the issues that you have mentioned before. It is still essentially only attacking two methods (and supporting classes). If you have a better design, then do it. On Sun, 2002-12-08 at 00:16, J.Pietschmann wrote: deep inheritance hierarchies. There is only so much someone can hold in the brain. Nevertheless, this is something I don't know how to fix on the cheap. We aren't at that stage yet. Why, because there aren't enough people developing it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs/design/alt.design AbsolutePosition-png.xml BorderCommonStyle-png.xml PropNames-png.xml Properties-png.xml PropertyConsts-png.xml VerticalAlign-png.xml book.xml classes-overview.xml AbsolutePosition.png.xml BorderCommonStyle.png.xml PropNames.png.xml Properties.png.xml PropertyConsts.png.xml VerticalAlign.png.xml
keiron 2002/12/09 00:45:16 Modified:src/documentation/content/xdocs news.xml status.xml src/documentation/content/xdocs/design/alt.design book.xml classes-overview.xml Added: src/documentation/content/xdocs/design/alt.design AbsolutePosition-png.xml BorderCommonStyle-png.xml PropNames-png.xml Properties-png.xml PropertyConsts-png.xml VerticalAlign-png.xml Removed: src/documentation/content/xdocs/design/alt.design AbsolutePosition.png.xml BorderCommonStyle.png.xml PropNames.png.xml Properties.png.xml PropertyConsts.png.xml VerticalAlign.png.xml Log: updated and fixed some broken links Revision ChangesPath 1.4 +4 -0 xml-fop/src/documentation/content/xdocs/news.xml Index: news.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/news.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- news.xml 19 Nov 2002 07:57:27 - 1.3 +++ news.xml 9 Dec 2002 08:45:15 - 1.4 @@ -8,6 +8,10 @@ /header body section + title22 November 2002 - New Committer/title + pWelcome Victor Mote!/p + /section +section title9 November 2002 - New Committer/title pWelcome Oleg Tkachenko!/p /section 1.6 +1 -1 xml-fop/src/documentation/content/xdocs/status.xml Index: status.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/status.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- status.xml29 Nov 2002 22:00:31 - 1.5 +++ status.xml9 Dec 2002 08:45:15 - 1.6 @@ -73,7 +73,7 @@ section titleMaintenance Status/title p -Latest maintenance release was FOP 0.20.5 on 24th November 2002. +Latest maintenance release will be FOP 0.20.5 on TBA. See link href=relnotes.htmlrelease notes/link for more details. Releases will be made periodically to address minor bugs and compatibility. 1.3 +6 -6 xml-fop/src/documentation/content/xdocs/design/alt.design/book.xml Index: book.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/design/alt.design/book.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- book.xml 2 Dec 2002 12:00:11 - 1.2 +++ book.xml 9 Dec 2002 08:45:16 - 1.3 @@ -21,12 +21,12 @@ menu-item label=alt.properties href=alt-properties.html/ menu-item label=Classes overview href=classes-overview.html/ menu-item label=Properties classes href=properties-classes.html/ - menu-item label=Properties href=Properties.png.html/ - menu-item label=PropertyConsts href=PropertyConsts.png.html/ - menu-item label=PropNames href=PropNames.png.html/ - menu-item label=AbsolutePosition href=AbsolutePosition.png.html/ - menu-item label=VerticalAlign href=VerticalAlign.png.html/ - menu-item label=BorderCommonStyle href=BorderCommonStyle.png.html/ + menu-item label=Properties href=Properties-png.html/ + menu-item label=PropertyConsts href=PropertyConsts-png.html/ + menu-item label=PropNames href=PropNames-png.html/ + menu-item label=AbsolutePosition href=AbsolutePosition-png.html/ + menu-item label=VerticalAlign href=VerticalAlign-png.html/ + menu-item label=BorderCommonStyle href=BorderCommonStyle-png.html/ menu-item label=XML parsing href=xml-parsing.html/ menu-item label=Property parsing href=propertyExpressions.html/ menu-item label=Compound properties href=compound-properties.html/ 1.4 +3 -3 xml-fop/src/documentation/content/xdocs/design/alt.design/classes-overview.xml Index: classes-overview.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/design/alt.design/classes-overview.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- classes-overview.xml 2 Dec 2002 14:34:04 - 1.3 +++ classes-overview.xml 9 Dec 2002 08:45:16 - 1.4 @@ -85,7 +85,7 @@ figure src=images/design/alt.design/PropertyStaticsOverview.png alt=Top level property classes/ dl -dtlink href=PropNames.htmlPropNames/link/dt +dtlink href=PropNames-png.htmlPropNames/link/dt dd Contains an array, codepropertyNames/code, of the names of all properties, and a set of enumeration constants, one @@ -97,7 +97,7 @@ hence the naming
Re: todo
Hi Oleg, I think writing direction would be a good addition. I am hoping to bring back all the renderers and this is one issue that need to be considered. ie. how it is handled in the area tree and how renderers deal with it, sorting out width/height vs. ipd/bpd On Sun, 2002-12-08 at 18:30, Oleg Tkachenko wrote: Hello there! I've got some time to be devoted to FOP's dev, but I'm not sure where to focus and as newbie commiter I'm asking the community where you want to see my efforts. From the todo list, writing direction stuff looks the most interesting to me (especially to my boss :), so if nobody works on it already I would take it. (I have a little experience in this domain by virtue of living in rtl-writing-mode country). Another one we should discuss probably is moving to CLI instead of home-brewed CommandLineOptions - comments? That possibly goes with the rest of the api and avalon integration which needs doing. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
On Fri, 2002-12-06 at 15:43, Rhett Aultman wrote: We have a Wiki that seems to have been a good way of quickly throwing up ideas for style guidelines and voting on them. Why don't we do the same thing here? We could throw up our ideas, try to sort them into lofty, long term stuff and immediate tasks and whatnot. Yeah...Bugzilla can be used somewhat, but I think this would be a better way to go when it comes to collaboratively creating a game plan. Anyone else have thoughts on this? I say we set up another page on our Wiki. A very rough start at some tasks for FOP here: http://codeconsult.ch/wiki/index.php/FopTasks I'm new to this wiki stuff, so see what happens. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/xml-docs/data logo.svg track.svg
keiron 2002/12/09 02:52:27 Modified:docs/xml-docs/data logo.svg track.svg Log: updated Revision ChangesPath 1.3 +11 -11xml-fop/docs/xml-docs/data/logo.svg Index: logo.svg === RCS file: /home/cvs/xml-fop/docs/xml-docs/data/logo.svg,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- logo.svg 30 Nov 2002 01:14:51 - 1.2 +++ logo.svg 9 Dec 2002 10:52:27 - 1.3 @@ -1,7 +1,7 @@ ?xml version=1.0 standalone=no? !DOCTYPE svg PUBLIC -//W3C//DTD SVG 20001102//EN http://www.w3.org/TR/2000/CR-SVG-20001102/DTD/svg-20001102.dtd; -svg width=250 height=250 +svg width=100 height=100 defs text id=asf @@ -23,11 +23,11 @@ /textPath /text g style=stroke:black;stroke-width:8 -line x1=5 y1=20 x2=125 y2=20/ -line x1=5 y1=40 x2=40 y2=40/ -line x1=5 y1=60 x2=100 y2=60/ -line x1=5 y1=85 x2=40 y2=85/ -line x1=5 y1=110 x2=40 y2=110/ +line x1=15 y1=20 x2=125 y2=20/ +line x1=15 y1=40 x2=50 y2=40/ +line x1=15 y1=60 x2=100 y2=60/ +line x1=15 y1=85 x2=50 y2=85/ +line x1=15 y1=110 x2=50 y2=110/ /g /g @@ -59,12 +59,12 @@ /textPath /text g style=stroke:black;stroke-width:8 -line x1=5 y1=20 x2=110 y2=20/ -line x1=5 y1=40 x2=40 y2=40/ +line x1=15 y1=20 x2=110 y2=20/ +line x1=15 y1=40 x2=40 y2=40/ line x1=90 y1=40 x2=120 y2=40/ -line x1=5 y1=60 x2=105 y2=60/ -line x1=5 y1=85 x2=40 y2=85/ -line x1=5 y1=110 x2=40 y2=110/ +line x1=15 y1=60 x2=105 y2=60/ +line x1=15 y1=85 x2=50 y2=85/ +line x1=15 y1=110 x2=50 y2=110/ /g /g 1.2 +8 -4 xml-fop/docs/xml-docs/data/track.svg Index: track.svg === RCS file: /home/cvs/xml-fop/docs/xml-docs/data/track.svg,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- track.svg 12 Jun 2002 14:12:19 - 1.1 +++ track.svg 9 Dec 2002 10:52:27 - 1.2 @@ -44,11 +44,15 @@ text x=140 y=-59FOP 0.20.3/text text x=140 y=-49 style=font-size:8;color:grey4th March 2002/text -use xlink:href=#event transform=translate(260,-89)/ -text x=250 y=-59FOP 0.20.4/text -text x=250 y=-49 style=font-size:8;color:grey12th June 2002/text +use xlink:href=#event transform=translate(240,-89)/ +text x=230 y=-59FOP 0.20.4/text +text x=230 y=-49 style=font-size:8;color:grey12th June 2002/text -use xlink:href=#break transform=translate(340,-94)/ +use xlink:href=#event transform=translate(330,-89)/ +text x=320 y=-59FOP 0.20.5/text +text x=320 y=-49 style=font-size:8;color:greyTBA/text + +use xlink:href=#break transform=translate(380,-94)/ use xlink:href=#break transform=translate(260,8) scale(1.3)/ text x=240 y=40redesign/text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/pdf PDFXMLHandler.java
keiron 2002/12/09 03:18:58
Modified:src/org/apache/fop/render/pdf PDFXMLHandler.java
Log:
use more decimal places for scaling
Revision ChangesPath
1.12 +5 -5 xml-fop/src/org/apache/fop/render/pdf/PDFXMLHandler.java
Index: PDFXMLHandler.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/pdf/PDFXMLHandler.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- PDFXMLHandler.java14 Nov 2002 15:22:30 - 1.11
+++ PDFXMLHandler.java9 Dec 2002 11:18:58 - 1.12
@@ -256,10 +256,10 @@
if (!at.isIdentity()) {
double[] vals = new double[6];
at.getMatrix(vals);
-pdfInfo.currentStream.add(PDFNumber.doubleOut(vals[0]) +
-+ PDFNumber.doubleOut(vals[1]) +
-+ PDFNumber.doubleOut(vals[2]) +
-+ PDFNumber.doubleOut(vals[3]) +
+pdfInfo.currentStream.add(PDFNumber.doubleOut(vals[0], 5) +
++ PDFNumber.doubleOut(vals[1], 5) +
++ PDFNumber.doubleOut(vals[2], 5) +
++ PDFNumber.doubleOut(vals[3], 5) +
+ PDFNumber.doubleOut(vals[4]) +
+ PDFNumber.doubleOut(vals[5]) + cm\n);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/apps LayoutHandler.java
keiron 2002/12/09 03:22:35
Modified:src/org/apache/fop/apps LayoutHandler.java
Log:
added some comments and changed debugging a bit
Revision ChangesPath
1.8 +63 -20xml-fop/src/org/apache/fop/apps/LayoutHandler.java
Index: LayoutHandler.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/LayoutHandler.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- LayoutHandler.java25 Oct 2002 09:29:39 - 1.7
+++ LayoutHandler.java9 Dec 2002 11:22:35 - 1.8
@@ -96,10 +96,21 @@
areaTree.setTreeModel(atModel);
}
+/**
+ * Get the area tree for this layout handler.
+ *
+ * @return the area tree for this document
+ */
public AreaTree getAreaTree() {
return areaTree;
}
+/**
+ * Start the document.
+ * This starts the document in the renderer.
+ *
+ * @throws SAXException if there is an error
+ */
public void startDocument() throws SAXException {
pageCount = 0;
@@ -122,6 +133,11 @@
}
}
+/**
+ * End the document.
+ *
+ * @throws SAXException if there is some error
+ */
public void endDocument() throws SAXException {
try {
//processAreaTree(atModel);
@@ -131,14 +147,14 @@
throw new SAXException(e);
}
-if (MEM_PROFILE_WITH_GC) {
-System.gc(); // This takes time but gives better results
-}
-
-long memoryNow = runtime.totalMemory() - runtime.freeMemory();
-long memoryUsed = (memoryNow - initialMemory) / 1024L;
-
if (getLogger().isDebugEnabled()) {
+if (MEM_PROFILE_WITH_GC) {
+// This takes time but gives better results
+System.gc();
+}
+
+long memoryNow = runtime.totalMemory() - runtime.freeMemory();
+long memoryUsed = (memoryNow - initialMemory) / 1024L;
getLogger().debug(Initial heap size: + (initialMemory / 1024L) +
Kb);
getLogger().debug(Current heap size: + (memoryNow / 1024L) + Kb);
getLogger().debug(Total memory used: + memoryUsed + Kb);
@@ -149,9 +165,8 @@
}
}
-long timeUsed = System.currentTimeMillis() - startTime;
-
if (getLogger().isDebugEnabled()) {
+long timeUsed = System.currentTimeMillis() - startTime;
getLogger().debug(Total time used: + timeUsed + ms);
getLogger().debug(Pages rendered: + pageCount);
if (pageCount 0) {
@@ -160,6 +175,15 @@
}
}
+/**
+ * Start a page sequence.
+ * At the start of a page sequence it can start the page sequence
+ * on the area tree with the page sequence title.
+ *
+ * @param pageSeq the page sequence starting
+ * @param seqTitle the title of the page sequence
+ * @param lms the layout master set
+ */
public void startPageSequence(PageSequence pageSeq, org.apache.fop.fo.Title
seqTitle, LayoutMasterSet lms) {
Title title = null;
if (seqTitle != null) {
@@ -169,24 +193,38 @@
}
/**
- Format the PageSequence. The PageSequence
- formats Pages and adds them to the AreaTree,
- which subsequently calls the StreamRenderer
- instance (this) again to render the page.
- At this time the page might be printed
- or it might be queued. A page might not
- be renderable immediately if the IDReferences
- are not all valid. In this case we defer
- the rendering until they are all valid.
+ * End the PageSequence.
+ * The PageSequence formats Pages and adds them to the AreaTree.
+ * The area tree then handles what happens with the pages.
+ *
+ * @param pageSequence the page sequence ending
+ * @throws FOPException if there is an error formatting the pages
*/
public void endPageSequence(PageSequence pageSequence)
throws FOPException {
//areaTree.setFontInfo(fontInfo);
+if (getLogger().isDebugEnabled()) {
+if (MEM_PROFILE_WITH_GC) {
+// This takes time but gives better results
+System.gc();
+}
+
+long memoryNow = runtime.totalMemory() - runtime.freeMemory();
+getLogger().debug(Current heap size: + (memoryNow / 1024L) + Kb);
+}
+
pageSequence.format(areaTree);
}
-
+/**
+ * Process an area tree.
+ * If a store pages model is used this can read and send all the
+ * pages to the renderer.
+ *
+ * @param
Re: Getting breaks: revisited
J.Pietschmann wrote: Victor Mote wrote: Just to be clear, I should point out that there is not a layout that is impossible to perform. There are layouts for which it is very hard to decide what to do. Consider the following: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=thin page-width=110mm page-height=297mm fo:region-body/ /fo:simple-page-master fo:simple-page-master master-name=thick page-width=210mm page-height=297mm fo:region-body/ /fo:simple-page-master fo:page-sequence-master master-name=master fo:repeatable-page-master-reference maximum-repeats=100 master-reference=thin/ fo:repeatable-page-master-reference master-reference=thick/ /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=master fo:flow flow-name=xsl-region-body fo:block width=150mmblabla../fo:block /fo:flow /fo:page-sequence /fo:root Should this create 100 empty pages and render the text onto the 101st page, or should it squeeze it onto the first page, thereby violating the advised width constraint of the block? The user could have either in mind. Joerg, I kept this one in my inbox, and have finally got back to it. I would have thought that in a case like this, the intention of the spec would be realised by laying out 0 of the repeatable-p-m-refs thin, out of the available range of 0-100, then laying out 1 of the thick r-p-m-refs. This would work in the same way for the other case you mention - constrained height and keep-together table rows. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote: I still believe that it is useful to have the layout managers separate from the fo tree. There are a number of reasons that come to mind. It is possible to independantly change layout managers. Certain fo's aren't directly in the same hierarchy: markers, undefined table columns, table cells under table body. Then there are things like floats and footnotes that can gain from this. Keiron, I'm inclining in this direction myself, because I am interested in isolating the layout/area tree functions as much as possible from the raw information stream of the FO tree. I tend to view the FO tree as a read-only data source for the layout. manaaged by the Fo objects. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
ready for Release Candidate
Hi all, I've (finally) updated the build process to the new Forrest docs and I'm ready now for doing the Release Candidate. If this is ok for everybody I'll do it later today. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: png image problem
IvanLatysh wrote: Hi. I am experience problem when I am trying to get output from the FOP as png. Images are not shown in the result png. Could someone help me with it. First of all you need to tell us which FOP version you are using. If it's 0.20.4 you need to download Jimi from SUN at: http://java.sun.com/products/jimi/ extract the archive and copy JimiProClasses.zip to FOP's lib dir and rename it to jimi-1.0.jar. This is actually mentioned in the release notes and the FAQ. And it is a user question which should be posted to fop-user Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: bsf.jar
Oleg Tkachenko wrote: Christian Geisert wrote: I just noticed bsf.jar in the lib directory and IIRC it was needed by xalan1. As we switched to xalan2 some time ago is it ok for everyone if I remove bsf.jar? btw, isn't bsf.jar used by xalan2 to process extensions? Yes it's needed for extensions written in languages other than Java, but for that you need a jar with the extension language anyway so IMHO it makes no sense to distribute bsf.jar. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs compliance.xml
vmote 2002/12/09 09:26:10 Modified:src/documentation/content/xdocs compliance.xml Log: fixes from review of W3C standard, Implemented doc, and Limitations doc Revision ChangesPath 1.5 +29 -9 xml-fop/src/documentation/content/xdocs/compliance.xml Index: compliance.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/compliance.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- compliance.xml3 Dec 2002 07:26:11 - 1.4 +++ compliance.xml9 Dec 2002 17:26:10 - 1.5 @@ -165,14 +165,33 @@ level-3 name=border-right-color compliance-level=1 comply=yes/ level-3 name=border-right-style compliance-level=1 comply=yes/ level-3 name=border-right-width compliance-level=1 comply=yes/ - level-3 name=padding-before compliance-level=1 comply=yes/ - level-3 name=padding-after compliance-level=1 comply=yes/ - level-3 name=padding-start compliance-level=1 comply=yes/ - level-3 name=padding-end compliance-level=1 comply=yes/ - level-3 name=padding-top compliance-level=1 comply=yes/ - level-3 name=padding-bottom compliance-level=1 comply=yes/ - level-3 name=padding-left compliance-level=1 comply=yes/ - level-3 name=padding-right compliance-level=1 comply=yes/ + level-3 name=padding-before compliance-level=1 comply=yes +commentonly one value allowed/comment +commentonly implemented for blocks/comment +commentcan't be used to make extra space (use indents + spaces instead)/comment +commentcan be used to control how much the background-color extends beyond the content rectangle/comment + /level-3 + level-3 name=padding-after compliance-level=1 comply=yes +commentsame limitations as padding-before/comment + /level-3 + level-3 name=padding-start compliance-level=1 comply=yes +commentsame limitations as padding-before/comment + /level-3 + level-3 name=padding-end compliance-level=1 comply=yes +commentsame limitations as padding-before/comment + /level-3 + level-3 name=padding-top compliance-level=1 comply=yes +commentsame limitations as padding-before/comment + /level-3 + level-3 name=padding-bottom compliance-level=1 comply=yes +commentsame limitations as padding-before/comment + /level-3 + level-3 name=padding-left compliance-level=1 comply=yes +commentsame limitations as padding-before/comment + /level-3 + level-3 name=padding-right compliance-level=1 comply=yes +commentsame limitations as padding-before/comment + /level-3 /level-2 level-2 name=Common Font Properties level-3 name=font-family compliance-level=1 comply=yes/ @@ -233,7 +252,7 @@ level-2 name=Area Dimension Properties level-3 name=block-progression-dimension compliance-level=1 comply=no/ level-3 name=content-height compliance-level=2 comply=no/ - level-3 name=content-width compliance-level=1 comply=no/ + level-3 name=content-width compliance-level=2 comply=no/ level-3 name=height compliance-level=1 comply=yes/ level-3 name=inline-progression-dimension compliance-level=1 comply=no/ level-3 name=max-height compliance-level=3 comply=no/ @@ -374,6 +393,7 @@ level-3 name=ends-row compliance-level=2 comply=no/ level-3 name=number-columns-repeated compliance-level=1 comply=no/ level-3 name=number-columns-spanned compliance-level=1 comply=yes/ + level-3 name=number-rows-spanned compliance-level=1 comply=yes/ level-3 name=starts-row compliance-level=2 comply=no/ level-3 name=table-layout compliance-level=2 comply=no/ level-3 name=table-omit-footer-at-break compliance-level=2 comply=yes/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs faq.xml
vmote 2002/12/09 11:37:44 Modified:src/documentation/content/xdocs faq.xml Log: Expanded FAQs related to PDF post-processing. Revision ChangesPath 1.5 +25 -14xml-fop/src/documentation/content/xdocs/faq.xml Index: faq.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/faq.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- faq.xml 9 Dec 2002 18:23:13 - 1.4 +++ faq.xml 9 Dec 2002 19:37:44 - 1.5 @@ -873,24 +873,35 @@ p(Still applicable in 0.20.3?)/p /answer /faq +faq id=PDF-postprocess + questionWhat tools are available for post-processing my PDF document?/question + answer +ul + liThe most popular one that we are aware of is link href=http://www.lowagie.com/iText;iText/link, which has tools for adding security features, document properties, watermarks, and many other features to PDF files. See also Joerg Pietschmann's link href=http://marc.theaimsgroup.com/?l=fop-devamp;m=102002975028427amp;w=2;posting on PDF Encryption/link for an example of Java application using iText./li +liYou can use Adobe Acrobat (the full version, not the Reader) to process the file manually or with scripting that it supports./li +/ul + /answer +/faq faq - questionPDF encryption, PDF protection (read-only)/question + questionHow do I add security features (encryption, for example) to my PDF document?/question answer - puse some other tool to postprocess the PDF (itext, or something?)/p +pFOP does not currently support this feature. Possible workarounds include those mentioned in the link href=#PDF-postprocessPDF Post-Processing FAQ/link./p /answer /faq faq - questionWatermarks/question + questionHow do I add document properties (title, author, etc.) to my PDF document?/question answer -p Answer: see 3.3, or use a a region overlapping the flowing text and put - an image there: -/p -pFrom: [EMAIL PROTECTED] -Use the region-before. Make it large enough to contain your image and then -include a block (and if required an absolutely positioned block-container) -with your image in the static-content for the region-before. - Could use some code here... -/p +pFOP does not currently support this feature. Possible workarounds include those mentioned in the link href=#PDF-postprocessPDF Post-Processing FAQ/link./p + /answer +/faq +faq + questionHow do I add watermarks to my PDF document?/question + answer +pFOP does not currently support this feature. Possible workarounds:/p +ul + liSee the link href=#PDF-postprocessPDF Post-Processing FAQ/link./li + li(submitted by [EMAIL PROTECTED]) Place an image in a region that overlaps the flowing text. For example, make region-before large enough to contain your image. Then include a block (if necessary, use an absolutely positioned block-container) containing the watermark image in the static-content for the region-before./li +/ul /answer /faq faq @@ -1340,8 +1351,8 @@ /ul /answer /faq -faq - question id=FO-validate(FO) How do I validate my FO document?/question +faq id=FO-validate + question(FO) How do I validate my FO document?/question answer plink href=http://www.renderx.com;RenderX/link has provided an link href=http://www.renderx.com/Tests/validator/fo.dtd.html;Unofficial DTD for FO Documents/link. This document may be helpful in validating general FO issues./p pFOP also maintains an link href=http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/docs/foschema/fop.xsd?rev=HEADamp;content-type=text/plain;Unofficial FOP Schema/link in the FOP CVS Repository. This document can be used either to validate against the FO standard, or against the actual FOP implementation. See the notes near the beginning of the document for instructions on how to use it./p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Redesign issues
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: December 9, 2002 8:56 AM To: [EMAIL PROTECTED] Subject: Re: Redesign issues Keiron Liddle wrote: I still believe that it is useful to have the layout managers separate from the fo tree. There are a number of reasons that come to mind. It is possible to independantly change layout managers. Certain fo's aren't directly in the same hierarchy: markers, undefined table columns, table cells under table body. Then there are things like floats and footnotes that can gain from this. Keiron, I'm inclining in this direction myself, because I am interested in isolating the layout/area tree functions as much as possible from the raw information stream of the FO tree. I tend to view the FO tree as a read-only data source for the layout. manaaged by the Fo objects. The feeling I got from my prototype is that there is not much commonality. Markers - there is no logic here that has anything to do with layout, per se. The content goes into a static-content and hence does not influence page break decisions. The logic for handling markers can be confined to the document level. root is an FO - it is the document, so it is the FO that can handle this. Floats and footnotes - the float goes on a page or it doesn't. The footnote starts on page N and continues through N+x or it doesn't. What FO knows about pages? The page-sequence...that's the natural FO for handling float and footnote problems. OK, this is somewhat simplified; with floats it may come down to columns, and then it is the region-body that also needs to intercede. Tables I can't comment on. So there may be an argument here for independent layout managers. I think we could use layout managers when it is clear that there is a layout problem involving N FOs, such that those N FOs are not identical to the children of a higher FO. I see keeps as being the main occurrence of this. But even then, keeps are still related to logic that occurs in page-sequence and region-body and lines (3 entities, in other words), and the nature of that logic differs in all 3 situations, so is it worth abstracting out a keep manager? I don't know. Here's a common ground that I can agree on...pull the layout logic out, and put it in managers. This is not going to hurt. But really, really cut down on the urge to re-use managers through an inheritance hierarchy. I think this is also Joerg's point. It obfuscates more than it helps. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Peter B. West wrote: ...the intention of the spec would be realised by laying out 0 of the repeatable-p-m-refs thin, out of the available range of 0-100, then laying out 1 of the thick r-p-m-refs. Interesting and useful interpretation. The problem is, how to implement this? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Redesign issues
Keiron Liddle wrote: These are the issues that you have mentioned before. It is still essentially only attacking two methods (and supporting classes). Unfortunately, these are the core methods, essential for understanding the whole approach. If you have a better design, then do it. I put a detailed critique and some proposals for alternatives forward. It would be nice to hear your comments about how essential the current approach (for the iterators) is for you and Karens plans for further development, and/or how the alternatives would interfere with it. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign issues
Response below. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 3:00 PM To: [EMAIL PROTECTED] Subject: Re: Redesign issues Keiron Liddle wrote: These are the issues that you have mentioned before. It is still essentially only attacking two methods (and supporting classes). Unfortunately, these are the core methods, essential for understanding the whole approach. Indeed. If you have a better design, then do it. I put a detailed critique and some proposals for alternatives forward. It would be nice to hear your comments about how essential the current approach (for the iterators) is for you and Karens plans for further development, and/or how the alternatives would interfere with it. I agree, and this is one of the reasons I thought a comprehensive development plan, not just a simple todo list, is essential. More than just one or two of us are waiting to see the solidification of a plan before we can see where we fit. Personally, I see a lot of things I'd like to do with the layout system, but I have a strong concern that they may not be fully congruent with the overall path of FOP as it is seen by the most prolific committers (like Keiron). My work would thus be a waste of time for both me and FOP. Let's get it together on this so we can all work towards a solution. I really don't see why there's such a love it or leave it attitude with respect to the LMs as they are now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Getting FOP running on Mac OS X
Howdy, FYI, I had a problem running FOP on my Mac OS X system. Here's the error I got: [webmaestro-mac:Users/Shared/fop-0.20.4] clay% ./fop.sh -d -xml /Users/clay/Desktop/HuiBro/test_MIWC.xml -xsl /Users/clay/Desktop/HuiBro/xml_med7_MIWC.fo -awt Exception in thread main java.lang.NoClassDefFoundError: org/apache/avalon/framework/logger/Logger at org.apache.fop.apps.Fop.main(Unknown Source) [webmaestro-mac:Users/Shared/fop-0.20.4] clay% The information on the FOP FAQ was helpful in finding the problem, but was by no means enough. It ended up being a simple problem, but nonetheless was difficult for me to resolve. The files were ZIP'd, and when they were unZIP'd using Stuffit Expander, the avalon JAR file's long filename was changed from: avalon-framework-cvs-20020315.jar to: avalon-framework-cvs-20020315.j Adding ar at the end of that filename, resolved the problem, and I am able to run FOP on my Mac. Unfortunately, it took a few days to figure out this problem. JAVA_HOME UNDER MAC OS X Also, according to Apple's Developer Connection: http://developer.apple.com/qa/qa2001/qa1170.html Java Home. Many Java applications require the identification of a Java Home directory during installation. The equivalent on Mac OS X should always be /Library/Java/Home. This is actually a symbolic link to the current installed J2SE version, and allows access to the bin subdirectory where command line tools such as java, javac, etc. exist as expected. The advantage of using this link, as opposed to its target, is that it will be maintained and updated when a new version of Java is downloaded via Software Update or installed with a newer version of Mac OS X. For this reason, it is important that developers do not install files below the Java Home, as the actual directory referenced by the link will be lost with subsequent updates when the link is updated. I didn't see this in the FAQ, but I think it might be a good addition. Respectfully, - Clay Leeds - Web Developer - [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting FOP running on Mac OS X
Clay Leeds wrote: The files were ZIP'd, and when they were unZIP'd using Stuffit Expander, the avalon JAR file's long filename was changed from: avalon-framework-cvs-20020315.jar to: avalon-framework-cvs-20020315.j Adding ar at the end of that filename, resolved the problem, and I am able to run FOP on my Mac. Unfortunately, it took a few days to figure out this problem. First, thanks for the input. I'll be glad to update the FAQ, but I am a little confused about what to put into it. The file name was truncated after 31 characters, which is too odd of a number to seem to have been done on purpose by StuffIt. What caused the filename truncation? Without understanding that, I am not sure how to help. Java Home. Many Java applications require the identification of a Java Home directory during installation. The equivalent on Mac OS X should always be /Library/Java/Home. This is actually a symbolic link to the current installed J2SE version, and allows access to the bin subdirectory where command line tools such as java, javac, etc. exist as expected. The I am not a Mac guy, so please excuse my ignorance. Is this something that Mac people should already know? In other words, I wonder whether it is even appropriate to address this in FOP doc as it is primarily a sysadmin issue, or at least a Mac or Java issue. Also, what if /Library/Java/Home points to a 1.1 or 1.2 java runtime? If we tell the user to use that, then FOP doesn't work. Again, I am not sure what to recommend here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting FOP running on Mac OS X
It is possible the latest StuffIt Expanders work properly for filenames longer than 31 chars but it is a known problem. OS X can use much longer filenames. I include the following when I put up archives: MacOSX Note: Don't use Stuffit to expand the archive. Use the following shell command instead: tar -xzf source.tar.gz gunzip should work for a zip file also (I think). Clay Leeds wrote: The files were ZIP'd, and when they were unZIP'd using Stuffit Expander, the avalon JAR file's long filename was changed from: avalon-framework-cvs-20020315.jar to: avalon-framework-cvs-20020315.j Adding ar at the end of that filename, resolved the problem, and I am able to run FOP on my Mac. Unfortunately, it took a few days to figure out this problem. First, thanks for the input. I'll be glad to update the FAQ, but I am a little confused about what to put into it. The file name was truncated after 31 characters, which is too odd of a number to seem to have been done on purpose by StuffIt. What caused the filename truncation? Without understanding that, I am not sure how to help. Java Home. Many Java applications require the identification of a Java Home directory during installation. The equivalent on Mac OS X should always be /Library/Java/Home. This is actually a symbolic link to the current installed J2SE version, and allows access to the bin subdirectory where command line tools such as java, javac, etc. exist as expected. The I am not a Mac guy, so please excuse my ignorance. Is this something that Mac people should already know? In other words, I wonder whether it is even appropriate to address this in FOP doc as it is primarily a sysadmin issue, or at least a Mac or Java issue. Also, what if /Library/Java/Home points to a 1.1 or 1.2 java runtime? If we tell the user to use that, then FOP doesn't work. Again, I am not sure what to recommend here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- -s - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting FOP running on Mac OS X
On Monday, December 9, 2002, at 11:54 PM, Victor Mote wrote: Clay Leeds wrote: The files were ZIP'd, and when they were unZIP'd using Stuffit Expander, the avalon JAR file's long filename was changed from: avalon-framework-cvs-20020315.jar to: avalon-framework-cvs-20020315.j Adding ar at the end of that filename, resolved the problem, and I am able to run FOP on my Mac. Unfortunately, it took a few days to figure out this problem. First, thanks for the input. I'll be glad to update the FAQ, but I am a little confused about what to put into it. The file name was truncated after 31 characters, which is too odd of a number to seem to have been done on purpose by StuffIt. What caused the filename truncation? Without understanding that, I am not sure how to help. This is because 31 characters was the file name limit under Mac OS Classic. StuffIt Expander being a carbonized application, it may still contains code that make sure filenames are truncated to 31 characters. The Good Way to extract Unix archives under Mac OS X is to open the Terminal and use gzip, gnutar and zip/unzip. Java Home. Many Java applications require the identification of a Java Home directory during installation. The equivalent on Mac OS X should always be /Library/Java/Home. This is actually a symbolic link to the current installed J2SE version, and allows access to the bin subdirectory where command line tools such as java, javac, etc. exist as expected. The I am not a Mac guy, so please excuse my ignorance. Is this something that Mac people should already know? In other words, I wonder whether it is even appropriate to address this in FOP doc as it is primarily a sysadmin issue, or at least a Mac or Java issue. Also, what if /Library/Java/Home points to a 1.1 or 1.2 java runtime? If we tell the user to use that, then FOP doesn't work. Again, I am not sure what to recommend here. Java under Mac OS X started with JDK 1.3. JDK 1.4 is in beta test. The JAVA_HOME issue should already be known by most Java programmers that work under Mac OS X, but it may be useful to recall the trick. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/docs/design/alt.design AbsolutePosition.dia PropNames.dia PropertyConsts.dia Properties.dia VerticalAlign.dia
pbwest 2002/12/09 15:41:00 Removed: docs/design/alt.design AbsolutePosition.dia PropNames.dia PropertyConsts.dia Properties.dia VerticalAlign.dia Log: No longer required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alt-Design: Preliminary results FO tree build test
Peter B. West wrote: Keiron Liddle wrote: On Fri, 2002-12-06 at 03:47, Peter B. West wrote: If anyone else want to have a look I would be interested in the results. I am particularly interested in memory usage, which, prima facie, looks good. 9 megs total memory usage for 51 pages of FO tree sounds very encouraging to me, although I have called these preliminary because I am not certain that everything that needs to be created has been created. I don't know how much you know about it, but in HEAD Karen added whitespace handling that reduces the whitespace as it is processed (eg. when a block ends). I get about 17.5Mb for that document. I don't know what is using it all but there are lots of variables that are not being used. Unfortunately, since FOP was changed to trigger layout on the end element of a page-sequence, no complete FO tree is built in the current versions. There are, however, only two page sequences in the fo file, so the simple solution may be to remove the the smaller of these for the comparisons. Keiron, Using the current maint version, I made the following modifications: Forced GC for memory profiling Moved time calculation ahead of GC (it takes over 1.2 seconds) - in apps.StreamRenderer.java Commented out the call to render() Allowed page-sequence FO subtree to be added to the FO tree - in fo.FOTreeBuilder.java Compiled and run under j2sdk-1.4.1 and build.compiler=jikes. Obviously all of the renderer setup code is still present, including font setup, and as you say, there are no doubt variables which are initialised for the rendering. Results (fastest of three successive runs): [DEBUG] Input mode: [DEBUG] FO [DEBUG] fo input file: /home/pbw/public_html/xml/real-life-51-page-document.fo [DEBUG] Output mode: [DEBUG] pdf [DEBUG] output file: /tmp/51.pdf [DEBUG] OPTIONS [DEBUG] no user configuration file is used [default] [DEBUG] debug mode on [DEBUG] dump configuration [DEBUG] quiet mode on [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] base directory: file:/home/pbw/public_html/xml/ [INFO] FOP 0.20.5cvs [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [INFO] setting up fonts [INFO] Parsing of document complete, stopping renderer [DEBUG] Total time used: 17159ms [DEBUG] Pages rendered: 0 [DEBUG] Initial heap size: 497Kb [DEBUG] Current heap size: 16922Kb [DEBUG] Total memory used: 16425Kb The equivalent figures from my original post are: Initial heap size: 352Kb Current heap size: 8879Kb Total memory used: 8527Kb The comparable time is the elapsed time before preorder scan: 15960ms Fop-devs, I have just run some quick test of property generation, to determine whether I was actually generating the property sets for the FOs. Although there are obviously still some bugs in property generation, the full property sets are being generated. I don't think that almost halving the memory usage of the FO tree build can be accounted for by unused variables in the maint code. Rather, it seems that the rewrite of FO tree building and property representation has achieved its design goal: significantly reduced memory usage. To my surprise, it also runs faster, in spite of using an admittedly less efficient pull parsing method implemented over the top of SAX. Taking advantage of native pull parsing APIs when they become available (and the Neko pull parser is slated for release with Xerces soon) will increase the performance. Now if I can work out Forrest, I'll update the documentation. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
src/documentation/README
Keiron and Nicola Ken (and anyone else who is interested): I have the process of building the fop web site mostly scripted at /home/vmote/script/build-fop-website.bsh. I have a couple of problems/questions, which I will interject into the src/documentation/README doc contents below: The current procedure is: - checkout xml-forrest module - run: build.sh(bat) dist - follow instructions to set FORREST_HOME and path - go to xml-fop directory - run forrest(.bat) The documents will then be placed in build/site/ I have been running this on the Apache machine. Is that OK? If successful, we can theoretically just add a cron job to publish periodically if we wish, until Forrest is ready to do its magic for us. When running forrest, I am getting the NoClassDefFoundError on java.awt.Rectangle, which I assume is Batik failing during pdf generation because of running in a headless environment. I did not find any of our solutions in our headless FAQ available on that machine. How have you been handling this? Or have you been running locally then uploading the completed web site? NOTE: the compliance.html currently does not work, it can be fixed by adding the dtd ref to: build/tmp/context/resources/schema/catalog and placing the dtd in: build/tmp/context/resources/schema/dtd/ I'll work on this after I get the basics going. To update website - put the generated docs into the xml-site module targets/fop/ this could be done by simlinking the destination to the targets/fop - commit the documents I wonder if we still should have this under cvs control. It probably doesn't matter much for the html files, but the pdf files are binary, and cvs is basically keeping a full copy of each revision. For example, status.pdf is currently 8328 bytes, and status.pdf,v which contains 3 versions, is 27,769 bytes. Since these are generated files now, we probably don't need an audit trail of them. Does committing the documents actually trigger something that immediately updates the web site, or is there some process that runs periodically that does that? I am hoping, if this script works, that we can change our workflow as follows: If a reasonably good question comes up on the user list that can/should be addressed in our doc, the monitor (usually Joerg or Oleg) can change the doc, republish the web site, and post an answer that contains a link to the new doc, along with a comment that it was just updated. In this way, not only does the question get answered, but the doc is improved, for little more than the cost of answering it. This only works well if the doc can be republished almost at will. I'm hoping that the monitors would view this as an investment that should result in less questions on the user list (especially after our doc gets a reputation for being thorough), but, if not, I'll try to cull through the lists to update the doc myself. This would require a less-frequent update cycle -- once a day is probably plenty. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting FOP running on Mac OS X
Clay Leeds wrote: This is fine, but I think it would be better to state something like: MacOSX Note: Use the following shell command to extract FOP under Mac OS X: tar -xzf source.tar.gz If you use Stuffit to expand the archive, the following filename: fop-0.20.4\lib\avalon-framework-cvs-20020315.jar may be truncated to 31 characters fop-0.20.4\lib\avalon-framework-cvs-20020315.j ... Thanks to Clay, Stephen, and Sebastien for enlightening me on the 31-character truncation issue. Unless any other developers object, I will find a place in the documentation (probably in the installation) to deal with this. It will be much more general than the one proposed (I don't want to maintain anything that has specific filenames in it, nor do I want to turn this into a Mac support site), but should be sufficient for someone to get started on finding a solution. Sebastien Aperghis-Tramoni wrote: Java under Mac OS X started with JDK 1.3. JDK 1.4 is in beta test. The JAVA_HOME issue should already be known by most Java programmers that work under Mac OS X, but it may be useful to recall the trick. Again, barring objections from the other developers, I'll add a comment to the installation doc. However, the upgrade issue still remains. I really don't want to document for users how to point to an obsolete version of Java (I see that it is not obsolete now -- I am thinking of future FOP releases that may require higher versions of Java). What is Apple's plan for upgrading Java when that is needed? Is there a web site URL that I could add that would help the user 1) figure out what version they have, and 2) get it upgraded if necessary? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
