Re: Image Handling Question

[Keiron Liddle]

Hi Arved,

There are a couple of reasons that it only has a URL.
If the page is going to be serialized we don't want to serialize an image.
There is no advantage to having a reference to the image and it would make 
it harder to keep track of references for caching.
The URL is used as a key to get the image from the cache. The only problem 
with this is if someone decides to use two syntactily different URL's for 
the same image, which I am guessing is rare.

As for the size, since the image is inside a viewport I was thinking of 
setting the size and position in the viewport. There are other objects 
that can be in the viewport that need the same things.

So in the FOTree it only grabs the image (using the URL) if the size of 
the image is needed. The image is then in the cache with the URL as the 
key. When the renderer comes to render the image it grabs the image again 
and draws it. In the case of the PDF Renderer it no longer needs the 
original image in the cache so it releases the image. The image is then 
available as a PDF Object.

Keiron.

On 2002.03.17 18:38 Arved Sandstrom wrote:
 Keiron or Karen,
 
 I have a quick question. This is mostly because I am unfamiliar with the
 code. As it stands right now org.apache.fop.area.inline.ImageArea does
 not
 look like something that the layout process can use; it also doesn't look
 
 like something that the renderer can use because it supplies only a URL
 reference, not any extra information as to what changes (e.g. scaling)
 may
 have taken place.
 
 So is it the case that org.apache.fop.image.AbstractFopImage (or
 something
 like it) is the primary object to be used in layout? And I'm thinking
 that if
 this is the case, that the ImageArea class should not have a reference to
 a
 URL, but rather to the AbstractFopImage.
 
 Am I missing something here? I am going to continue on with research - I
 have
 plenty of serious reading and code review ahead of me, I can see. I
 wanted to
 ask about _this_ to maybe speed things up with image handling.
 
 Regards,
 Arved

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

Re: Area tree - renderer (pr.fo for structure renderers)

[Bertrand Delacretaz]

On Saturday 16 March 2002 14:52, Peter B. West wrote:
. . .
The last stage of the FOP process translates one page
 description (the area tree) into another (the input to the target
 renderer.)

ok

 So why would anyone want to interpose another translation step into
 this tightly coupled arrangement?  Who knows?  
. . .
For page-based renderers where FOP has to compute the layout (like for 
PDF output), I don't see a need for another translation step either. 
IMHO asking who knows is usually a sign that a feature is not needed 
*at this stage of development*...

OTOH, for structure-based renderers like RTF and MIF, I think the only 
parts of FOP that are reusable are the first two stages: parsing and 
property resolution (apart from infrastructure like logging, config, 
etc. which might come from Avalon in the future?).

Last week we had a talk about using XML to communicate between FOP 
pipeline components, but for me this currently would only make sense 
between the property resolver and structure renderers components.

The deal is being able to reuse FOP's property resolution (p.res) in 
different contexts. I think the following usage scenarios could greatly 
benefit from reusing FOP's front-end (parser + p.res).

In the following I call pr.fo an XSL-FO document where all properties 
(fonts, sizes, etc.) are explicitely written, for example when 
inherited from parents:

a) XSL-FO to RTF conversion:
FOP parser - FOP p.res - pr.fo - jfor converter

b) XSL-FO to MIF conversion
FOP parser - FOP p.res - pr.fo - yet-to-write XML-to-MIF converter 

c) automated testing of first FOP stages
FOP parser - FOP p.res - pr.fo - XML testing tool

Keeping in mind that RTF and MIF are formats where the page layout is 
left to the client software to compute (word processor or FrameMaker), 
keeping these converters independent of FOP instead of integrating them 
has several advantages:

b) Helps keep FOP focused on its main task: generating great PDF from 
XSL-FO documents

c) If FOP is ever rewritten in another language for performance, these 
converters, being much less compute-intensive, can stay in java and 
keep the same interface to the FOP components that they use

d) assuming I want to write a MIF converter, basing it on XSL-FO input 
instead of on a FOP API allows me to easily include MIF-specific 
constructs for applications where XSL-FO conformance is not needed but 
precise control of the generated MIF is (often a requirement for MIF 
when producing half-finished documents that are typographically 
reviewed before printing).

In conclusion, I think an interface based on XML documents (possibly 
this pr.fo discussed above) is the best choice to use between the FOP 
property resolution stage and the structure renderers like RTF and 
MIF renderers.

OTOH I agree that using XML between the layout and rendering stages 
doesn't make sense at this stage of FOP development.

Due to many other commitments, I don't have time right now (sorry, 
I know you're getting used to hear this) to implement this pr.fo 
interface, but if we agree on its usefulness I'll put this high on my 
list and hopefully give it a shot in the next few weeks...

-- 
 Bertrand Delacrétaz (codeconsult.ch, jfor.org)

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.

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

Re: Image Handling Question

[Jeremias Maerki]

I've got a comment below concerning the PS renderer which I think may be
important when working on the image stuff.

snip/
 So in the FOTree it only grabs the image (using the URL) if the size of 
 the image is needed. The image is then in the cache with the URL as the 
 key. When the renderer comes to render the image it grabs the image again 
 and draws it. In the case of the PDF Renderer it no longer needs the 
 original image in the cache so it releases the image. The image is then 
 available as a PDF Object.

PostScript has no such thing as a PDF Object it can simply reference.
You have to write a procedure if you want to reuse an image. From that
point of view it may be helpful if we had a usage counter for images per
rendered document. That would enable the PS renderer (and maybe others
too) to decide whether to create a procedure in the Prolog that contains
the image and that could be called whenever necessary (reduces PS size,
may improve RIP performance), or if the image should be best provided
inline (reduces RIP memory usage). Especially for logos that are printed
on every page this would be very helpful.

Of course, this would mean that the renderer interface would probably
have to be extended so information like this can be passed to the
renderer so it can do stuff like the above. The problem on the other
side is the incremental rendering process: we don't know how many
intances of the same image will get rendered. So, maybe the usage
counter is not such a good idea, except if the renderer can rearrange
the generated PS afterwards (moving images into procedures in the Prolog,
kills simple incremental PS writing).

The longer I think about this, the more I can't see a way around
losing the incremental PS writing if we want to provide some
optimizations. Probably, the PS renderer will have to be configurable
whether to do these optimizations or not.

Any other ideas?

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +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]

cvs commit: xml-fop/docs/xml-docs/fop output.xml

[keiron]

keiron  02/03/18 00:58:05

  Modified:.build.xml
   docs/design book.xml
   docs/xml-docs/fop output.xml
  Log:
  updates to docs with build target for understanding and alt.design
  Submitted by: Peter B. West [EMAIL PROTECTED]
  Reviewed by:  Keiron
  
  Revision  ChangesPath
  1.52  +28 -3 xml-fop/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/xml-fop/build.xml,v
  retrieving revision 1.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- build.xml 11 Feb 2002 09:54:47 -  1.51
  +++ build.xml 18 Mar 2002 08:58:05 -  1.52
  @@ -84,8 +84,9 @@
- package [default] - creates ./build/fop.jar
- usage - shows a help screen
- codegen - generates needed java sources from xml resources
  - - docs - generates the HTML documentation in ./build/docs
  + - htmldoc - generates the HTML documentation in ./build/docs/html-docs
- javadocs - generates the API documentation in ./build/javadocs
  + - pdfdoc - generates the PDF documentation in ./build/docs/xml-docs
- dist - generates the Fop distribution
- clean - restores the distribution to its original and clean state 
   (excepting dist files)
  @@ -308,8 +309,9 @@
   echo message=   package   -- generates the ${name}.jar file (default)/
   echo message=   codegen   -- generates the java files from the xml 
resources/
   echo message=   compile   -- compiles the source code/
  -echo message=   docs  -- generates the HTML documentation/
  +echo message=   htmldoc   -- generates the HTML documentation/
   echo message=   javadocs  -- generates the API documentation (java 1.2 
only)/
  +echo message=   pdfdoc-- generates the PDF documentation/
   echo message=   dist  -- generates the ${Name} distribution as .tar.gz 
and .zip/
   echo message=   clean -- cleans up the directory (except for the dist 
files)/
   echo message=   distclean -- cleans up the directory/
  @@ -537,7 +539,10 @@
 /target
   
 target name=html depends=javadocs, htmldoc/
  -  target name=htmldoc depends=prepare-src
  +  
  +  target name=htmldoc depends= html-fop, html-design/
  +
  +  target name=html-fop depends=prepare-src
   copy file=${xdocs}/fop.xml
 tofile=${xdocs}/book.xml
 filtering=on/
  @@ -545,9 +550,29 @@
 classpath refid=libs-build-classpath/
 arg line=targetDirectory=${docs} ${xdocs}/book.xml ${skins}/
   /java
  +  /target
  +
  +  target name=html-design depends=prepare-src, html-newdesign,
  +   html-altdesign, html-understanding/
  +
  +  target name=html-newdesign depends=prepare-src
   java classname=${doc.generator} fork=yes
 classpath refid=libs-build-classpath/
 arg line=targetDirectory=${docs}/design/ docs/design/book.xml ${skins}/
  +/java
  +  /target
  +
  +  target name=html-altdesign depends=prepare-src
  +java classname=${doc.generator} fork=yes
  +  classpath refid=libs-build-classpath/
  +  arg line=targetDirectory=${docs}/design/alt.design/ 
docs/design/alt.design/book.xml ${skins}/
  +/java
  +  /target
  +
  +  target name=html-understanding depends=prepare-src
  +java classname=${doc.generator} fork=yes
  +  classpath refid=libs-build-classpath/
  +  arg line=targetDirectory=${docs}/design/understanding 
docs/design/understanding/book.xml ${skins}/
   /java
 /target
   
  
  
  
  1.4   +5 -0  xml-fop/docs/design/book.xml
  
  Index: book.xml
  ===
  RCS file: /home/cvs/xml-fop/docs/design/book.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- book.xml  17 Mar 2002 16:09:22 -  1.3
  +++ book.xml  18 Mar 2002 08:58:05 -  1.4
  @@ -3,6 +3,8 @@
   book title=FOP Design copyright=1999-2002 The Apache Software Foundation
 external href=http://xml.apache.org/fop/;  label=About FOP/
 separator/
  +  external href=understanding/index.html  label=Understanding /
  +  separator/
 page id=index  label=Design  source=intro.xml/
 page id=architecture   label=Architecturesource=architecture.xml /
 page id=propertieslabel=Properties source=properties.xml /
  @@ -19,4 +21,7 @@
 page id=extendinglabel=Extending source=extending.xml /
 separator/
 page id=status label=Status source=status.xml /
  +  separator/
  +  external href=alt.design/index.html  label=ALT DESIGN /
  +  separator/
   /book
  
  
  
  1.5   +7 -0  xml-fop/docs/xml-docs/fop/output.xml
  
  Index: output.xml
  ===
  RCS file: /home/cvs/xml-fop/docs/xml-docs/fop/output.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- output.xml17 Mar 2002 17:43:55 

Re: Updates to xml docs

[Keiron Liddle]

I have applied your patch and also updated the live website.

Thanks to all those who have contributed to various parts of the site.

For those interested the html is checked into the xml-site cvs module 
(which is a small 148Mb) under targets/fop/.
Some time in the future, hopefully real soon now :), it will be 
automatically done with the forrest project.

On 2002.03.17 23:47 Peter B. West wrote:
 Arved,
 
 After Karen's post on her updates I checked the repository, and I note 
 that you have installed the alt.design and understanding directories. 
 Many thanks to you and to Cyril.
 
 Attached are cvs diff -u output files for xml-fop/build.xml and 
 xml-fop/docs/design/book.xml whcih will bring the documentation onstream.
 
 One note: the .dia files are not necessary; they were used to generate 
 the .pngs.

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

RE: Image Handling Question

[Arved Sandstrom]

Hi, Keiron

OK, I'll buy all of this. I need to get used to the idea that we are
actually doing viewports. :-) That changes things. :-)

With viewports being used then the ImageArea becomes a relatively
unimportant thing. Except right at the beginning, where odds are pretty good
that the author will set auto for block- and inline-progression-dimension
(that is, not set those at all, nor 'height' and 'width'), and therefore in
conjunction with 'content-width', 'content-height', and scaling we'll have
to figure out the content size so the _viewport_ can get this for itself.
But afterwards nobody should care about the image itself except for the
renderer. And in the case that BPD and IPD are both explicitly set on the
viewport then layout will _never_ care about the actual image.

So I don't disagree, although I'd get pedantic and point out that, yes,
we're setting _a_ size  on the viewport, but that is not necessarily the
size of the image. But layout doesn't care - it only cares about the size of
the viewport.

Using the URL as a cache key clears other things up, too. Thanks.

Is it safe to assume that when we refer to the image being in cache, and
being retrieved from cache with the URL, etc etc, that _this_ image is the
FopAbstractImage or an advanced version of same?

Regards,
Arved

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: March 18, 2002 4:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Image Handling Question


Hi Arved,

There are a couple of reasons that it only has a URL.
If the page is going to be serialized we don't want to serialize an image.
There is no advantage to having a reference to the image and it would make
it harder to keep track of references for caching.
The URL is used as a key to get the image from the cache. The only problem
with this is if someone decides to use two syntactily different URL's for
the same image, which I am guessing is rare.

As for the size, since the image is inside a viewport I was thinking of
setting the size and position in the viewport. There are other objects
that can be in the viewport that need the same things.

So in the FOTree it only grabs the image (using the URL) if the size of
the image is needed. The image is then in the cache with the URL as the
key. When the renderer comes to render the image it grabs the image again
and draws it. In the case of the PDF Renderer it no longer needs the
original image in the cache so it releases the image. The image is then
available as a PDF Object.

Keiron.

On 2002.03.17 18:38 Arved Sandstrom wrote:
 Keiron or Karen,

 I have a quick question. This is mostly because I am unfamiliar with the
 code. As it stands right now org.apache.fop.area.inline.ImageArea does
 not
 look like something that the layout process can use; it also doesn't look

 like something that the renderer can use because it supplies only a URL
 reference, not any extra information as to what changes (e.g. scaling)
 may
 have taken place.

 So is it the case that org.apache.fop.image.AbstractFopImage (or
 something
 like it) is the primary object to be used in layout? And I'm thinking
 that if
 this is the case, that the ImageArea class should not have a reference to
 a
 URL, but rather to the AbstractFopImage.

 Am I missing something here? I am going to continue on with research - I
 have
 plenty of serious reading and code review ahead of me, I can see. I
 wanted to
 ask about _this_ to maybe speed things up with image handling.

 Regards,
 Arved

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


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

cvs commit: xml-fop/src/org/apache/fop/render/pdf PDFXMLHandler.java

[keiron]

keiron  02/03/18 04:30:46

  Modified:src/org/apache/fop/apps Driver.java
   src/org/apache/fop/fo FOTreeBuilder.java
   src/org/apache/fop/render/pdf PDFXMLHandler.java
  Log:
  made it easier to add xml handlers
  
  Revision  ChangesPath
  1.44  +9 -4  xml-fop/src/org/apache/fop/apps/Driver.java
  
  Index: Driver.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/Driver.java,v
  retrieving revision 1.43
  retrieving revision 1.44
  diff -u -r1.43 -r1.44
  --- Driver.java   5 Mar 2002 10:26:35 -   1.43
  +++ Driver.java   18 Mar 2002 12:30:46 -  1.44
  @@ -1,5 +1,5 @@
   /*
  - * $Id: Driver.java,v 1.43 2002/03/05 10:26:35 keiron Exp $
  + * $Id: Driver.java,v 1.44 2002/03/18 12:30:46 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.
  @@ -173,6 +173,7 @@
* the system resources that FOP will use
*/
   private Logger log;
  +private FOUserAgent userAgent = null;
   
   public static final String getParserClassName() {
   String parserClassName = null;
  @@ -192,6 +193,7 @@
   public Driver() {
   _stream = null;
   _treeBuilder = new FOTreeBuilder();
  +_treeBuilder.setUserAgent(getUserAgent());
   setupDefaultMappings();
   }
   
  @@ -202,12 +204,15 @@
   }
   
   public void setUserAgent(FOUserAgent agent) {
  +userAgent = agent;
   }
   
   private FOUserAgent getUserAgent() {
  -FOUserAgent ua = new FOUserAgent();
  -ua.setLogger(log);
  -return ua;
  +if(userAgent == null) {
  +userAgent = new FOUserAgent();
  +userAgent.setLogger(log);
  +}
  +return userAgent;
   }
   
   public void setLogger(Logger logger) {
  
  
  
  1.35  +6 -1  xml-fop/src/org/apache/fop/fo/FOTreeBuilder.java
  
  Index: FOTreeBuilder.java
  ===
  RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FOTreeBuilder.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- FOTreeBuilder.java5 Mar 2002 10:26:36 -   1.34
  +++ FOTreeBuilder.java18 Mar 2002 12:30:46 -  1.35
  @@ -1,5 +1,5 @@
   /*
  - * $Id: FOTreeBuilder.java,v 1.34 2002/03/05 10:26:36 keiron Exp $
  + * $Id: FOTreeBuilder.java,v 1.35 2002/03/18 12:30:46 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.
  @@ -82,6 +82,11 @@
   public void setUserAgent(FOUserAgent ua) {
   userAgent = ua;
   }
  +
  +public FOUserAgent getUserAgent() {
  +return userAgent;
  +}
  +
   
   public void setStreamRenderer(StreamRenderer streamRenderer) {
   this.streamRenderer = streamRenderer;
  
  
  
  1.2   +19 -11xml-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.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- PDFXMLHandler.java8 Mar 2002 11:00:20 -   1.1
  +++ PDFXMLHandler.java18 Mar 2002 12:30:46 -  1.2
  @@ -1,5 +1,5 @@
   /*
  - * $Id: PDFXMLHandler.java,v 1.1 2002/03/08 11:00:20 keiron Exp $
  + * $Id: PDFXMLHandler.java,v 1.2 2002/03/18 12:30:46 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.
  @@ -59,7 +59,17 @@
   
   public void handleXML(RendererContext context, Document doc,
 String ns) throws Exception {
  -PDFDocument pdfDoc = (PDFDocument) context.getProperty(PDF_DOCUMENT);
  +PDFInfo pdfi = getPDFInfo(context);
  +
  +String svg = http://www.w3.org/2000/svg;;
  +if (svg.equals(ns)) {
  +SVGHandler svghandler = new SVGHandler();
  +svghandler.renderSVGDocument(context, doc, pdfi);
  +} else {
  +}
  +}
  +
  +public static PDFInfo getPDFInfo(RendererContext context) {
   PDFInfo pdfi = new PDFInfo();
   pdfi.pdfDoc = (PDFDocument)context.getProperty(PDF_DOCUMENT);
   pdfi.currentStream = (PDFStream)context.getProperty(PDF_STREAM);
  @@ -70,18 +80,12 @@
   pdfi.currentFontSize = 
((Integer)context.getProperty(PDF_FONT_SIZE)).intValue();
   pdfi.currentXPosition = 

Re: Area tree - renderer (pr.fo for structure renderers)

[Peter B. West]

Bertrand,

See below...

Bertrand Delacretaz wrote:

On Saturday 16 March 2002 14:52, Peter B. West wrote:

. . .
The last stage of the FOP process translates one page
description (the area tree) into another (the input to the target
renderer.)


ok

So why would anyone want to interpose another translation step into
this tightly coupled arrangement?  Who knows?  
. . .

For page-based renderers where FOP has to compute the layout (like for 
PDF output), I don't see a need for another translation step either. 
IMHO asking who knows is usually a sign that a feature is not needed 
*at this stage of development*...

This was purely for rhetorical effect.  My point, developed further in 
the original, was that shoe-horning an xml-based externalisation step in 
here is probably completely redundant.  You have to invent a method of 
expressing all of the information contained in the area tree, while 
flattening the tree into a series of drawing instructions.  If you need 
to externalise the area tree, why not externalise it using an already 
well-defined page description language.  Your externalisation is then
Area Tree - Well defined PDL

Then attach any translators that you like to the end of that PDL; PDL - 
PDF, PDL - awt, PDL - PCL, whatever.  By the stage of the translation 
to the PDL, XSLFO has done its work.  If someone wants to define a PDL 
in XML, fair enough; but he has fallen off the end of the spec, and is 
creating something new.  At least that's the way I see it.  And if you 
want an already well-defined PDL, with, I assume, a number of converters 
already in place, why not Postscript?  Maybe even PDF.


OTOH, for structure-based renderers like RTF and MIF, I think the only 
parts of FOP that are reusable are the first two stages: parsing and 
property resolution (apart from infrastructure like logging, config, 
etc. which might come from Avalon in the future?).

Last week we had a talk about using XML to communicate between FOP 
pipeline components, but for me this currently would only make sense 
between the property resolver and structure renderers components.

The deal is being able to reuse FOP's property resolution (p.res) in 
different contexts. I think the following usage scenarios could greatly 
benefit from reusing FOP's front-end (parser + p.res).

In the following I call pr.fo an XSL-FO document where all properties 
(fonts, sizes, etc.) are explicitely written, for example when 
inherited from parents:

a) XSL-FO to RTF conversion:
FOP parser - FOP p.res - pr.fo - jfor converter

b) XSL-FO to MIF conversion
FOP parser - FOP p.res - pr.fo - yet-to-write XML-to-MIF converter 

c) automated testing of first FOP stages
FOP parser - FOP p.res - pr.fo - XML testing tool

Keeping in mind that RTF and MIF are formats where the page layout is 
left to the client software to compute (word processor or FrameMaker), 
keeping these converters independent of FOP instead of integrating them 
has several advantages:

b) Helps keep FOP focused on its main task: generating great PDF from 
XSL-FO documents

c) If FOP is ever rewritten in another language for performance, these 
converters, being much less compute-intensive, can stay in java and 
keep the same interface to the FOP components that they use

d) assuming I want to write a MIF converter, basing it on XSL-FO input 
instead of on a FOP API allows me to easily include MIF-specific 
constructs for applications where XSL-FO conformance is not needed but 
precise control of the generated MIF is (often a requirement for MIF 
when producing half-finished documents that are typographically 
reviewed before printing).

In conclusion, I think an interface based on XML documents (possibly 
this pr.fo discussed above) is the best choice to use between the FOP 
property resolution stage and the structure renderers like RTF and 
MIF renderers.

The big problem is in defining the p.res step.  How far do you need to 
go with this?  If you require all of the relative lengths resolved, 
e.g., you'll have to wait until the layout is done.  The properties are 
only finalised as the area tree is being constructed.  It's one of the 
things that makes this all so frustrating.

OTOH I agree that using XML between the layout and rendering stages 
doesn't make sense at this stage of FOP development.

Ok.


Due to many other commitments, I don't have time right now (sorry, 
I know you're getting used to hear this) to implement this pr.fo 
interface, but if we agree on its usefulness I'll put this high on my 
list and hopefully give it a shot in the next few weeks...


Peter


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

RE: [PROPOSAL] FOP+iText = FOP-NG

[Matthias Fischer]

Nicola,

you've been right at least to the extent that I have been well inclined to
take another glance at the ASL ;-)
at http://www.apache.org/licenses/LICENSE

My comment did not reflect my intent to ask for any approach or specific
legal outfit of the Apache Software in particular; it aimed at making
developers aware (where my point made any sense at all and would be
perceived as useful) of the following: do anything you consider right, but
where considered useful by you inquire up to which degree of complexity
users would be ready to study (and subject to) legal permissions.
I wasn't aware that http://www.apache.org/licenses/LICENSE contained any
dispositions on sub-licences, but if their use is as easy as that of the
ASL, no problem to me as a user; if my company felt instead that we had to
go to a lawyer to be sure of our entitlements and obligations, we'd probably
convinced ourselves that this was too much of an effort.
In other terms: IMO, the legal dispositions of an open source software
shouldn't be more complex than those of their commercial competitors.

Matthias


-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 3:10 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was:
merging two libraries)


From: Matthias Fischer

 My company, for instance, would have to stop using FOP;
 we would not even take the time to go into studying legal
 aspects, because, as a medium-sized company, we
 don't have the time and money and personnel to do this...

I think you are exaggerating a bit.
Are you using Apache license software? And did you study it with this
scrutiny?

If you are using the Apache license and are confortable with it, then there
is no problem. If Apache can distribute it with APL code, you can do the
same. It's simple as that.
Apache admits only compatible licenses in the CVS for this reason; some
weeks ago there has been a check in the CVS to check this, and you can be
sure that there is zero tolerance on this issue, it is applied very
strictly.

Look at the descriptions on the main apache site and on Jakarta; there are
very important pages IMO that explain as clearly as possible the position
Apache has on this point.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)


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

Re: Image Handling Question

[Keiron Liddle]

On 2002.03.18 12:45 Arved Sandstrom wrote:
 So I don't disagree, although I'd get pedantic and point out that, yes,
 we're setting _a_ size  on the viewport, but that is not necessarily the
 size of the image. But layout doesn't care - it only cares about the size
 of
 the viewport.

Yes there are the two different sizes, the image and the content size of 
the viewport.

 Using the URL as a cache key clears other things up, too. Thanks.
 
 Is it safe to assume that when we refer to the image being in cache,
 and
 being retrieved from cache with the URL, etc etc, that _this_ image is
 the
 FopAbstractImage or an advanced version of same?

Yes, an implementation of the FopImage interface to be precise.

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

DO NOT REPLY [Bug 4510] - fo:inline common properties ignored?

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4510.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

fo:inline common properties ignored?

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Minor   |Normal
 OS/Version|Solaris |Linux
   Platform|Sun |PC
Summary|background-color=blue |fo:inline common properties
   |ignored on fo:inline|ignored?
Version|0.15|0.20.3



--- Additional Comments From [EMAIL PROTECTED]  2002-03-18 13:05 ---
Maybe all common properties are now ignored by fo:inline...
I'm experiencing this problem with border  margin properties, but I read that 
also fo:inline background does not have an implementation on fop.

take a look to:
http://www.w3.org/Style/XSL/TestSuite/results/6/testresults.html

I'm using v0.20.3

regards,
Tomas Espeleta.

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

Re: [PROPOSAL] FOP+iText = FOP-NG

[Nicola Ken Barozzi]

From: Matthias Fischer [EMAIL PROTECTED]

 In other terms: IMO, the legal dispositions of an open source software
 shouldn't be more complex than those of their commercial competitors.

You're right.
In fact, the ASF is less complex.

The ASF distributes software that can be 100% sure to be usable as the APL
license says, which basically is do what you want but give us credit and
don't blame us.
The libraries are usable in the format they are distributed in as if they
were APL, since this is what compatible means.

If you have other questions regarding the license, or want to make these
suggestions to the ASF, you are welcome.
Taken from http://jakarta.apache.org/site/contact.html :

The Jakarta Project is an effort of the Apache Software Foundation. The
address for general ASF correspondence and licensing questions is:
[EMAIL PROTECTED]
You can find more contact information for the Apache Software Foundation on
the contact page of the main Apache site.


--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

Re: FAQ Answers please

[Joerg Pietschmann]

alex [EMAIL PROTECTED] wrote:
 Firstly lets set up a mailing list for discussing Apache FAQs. I think it
 would be a Good Thing.

I think public discussions relevant to the FOP FAQ could be
held on this list, everything else by email. Or did you think
of a discussion on how to do FAQs in general?

 AFAIK there is no official XML schema or DTD for FAQs, but we can come up
 with one.
 There is something called xdocs which is what most Apache documentation
 is written in. I am not sure if it is suitable for FAQs.
There is a docs/xml-docs/fop/faq.xml, the structure of which,
however, doesn't quite match neither the source nor the result
of docs/xml-docs/stylesheets/faq2document.

Nevertheless the structure given by the mentioned style sheet is
not unreasonable.

An interesting alternative would be DocBook qandaset. I wouldn't
have trouble providing any of the formats. DocBook comes with markup
for indexing, which is valuable for a FAQ.

 HOWEVER do we want the FAQ in the CVS tree? It means that it is a lot
 harder to add new answers.

I don't think using CVS automatically makes it harder to update
the FAQ. We just have to set up the publication process properly.
Of course it's easier if just one person uses only the ressources
at his disposal.

Some possibilities:
1. Update the FAQ in the docs subdirectory. Of course, changes
in the CVS should be mirrored by publishing the generated HTML
on xml.apache.org/fop. Actually, who does this publishing currently?
2. Provide a separate branch or even a CVS project for the FAQ
3. No CVS.
In either case, we will have to agree on responsibilities and
set up an event mechanism so that the publicly visible FAQ is
kept in sync with what's archived somewhere.

I personally would like to work on the FAQ distributed with
FOP and published on xml.apache.org/fop. The server is reliable,
and we would have a FAQ in the distribution which is in sync
with the distributed code.

Questions:
- Who is currently responsible for publishing FOP docs on
 xml.apache.org?
- Whom and by which mechanism should i send the material
 or notifications about changes in the repository?
 Possible mechanisms: Email, FTP upload, CVS checkin.
- Who will be responsible for transforming the XML source
 into the publishing format?
- Where will the ultimate source be archived? (N/A in
 case of CVS)

 plugAnyone in London or nearby want some FOP consultancy?/plug
I've some experience to sell as well...

Regards
J.Pietschmann

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

need help in generating PDF and WordFiles...

[AjayKumar Kanukuntla]

Title: Message




Can some body help me with the procedures, 
on creating pdf and word documents from xml files using FO. i tried doing it 
using Fop.class file, but the generated pdf file was not 
readable.
The following error message is flashed when 
the program is run...

E:\FOPjava 
org.apache.fop.apps.Fop atom.xml atom.pdf[INFO]: FOP 0.20.3[INFO]: 
building formatting object tree[ERROR]: Unknown formatting object 
^root[ERROR]: Root element must be root, not 
(none):root

plz help me out. givesome 
examples.

thnx :)

with regards,

K. AjayKumar
Software Developer
Pass IT Consulting Pvt Ltd
Hyderabad, India
[EMAIL PROTECTED]

Re: FAQ Answers please

[Joerg Pietschmann]

Nicola Ken Barozzi [EMAIL PROTECTED] wrote:
 There is a new project in Apache called Forrest, that is redesigning the
 whole xml.apache.org site to become useful as a Sourceforge on steroids.
 We are at the beginning, and it would be cool if you join us there!

Well, there are already GNUforge and PostNuke
I hope you havn't fall prey to the NIH syndrome.

 Currently, there is a mailing list, forrest-dev and a CVS module xml.forrest

Would it still be possible to use established mechanisms
as long as forrest is not put into production?

It would be nice if you could give a short note about the
current state and how the forrest project will influence
the publication of FOP docs in the future (to keep it on
topic for this list :-).

Regards
J.Pietschmann

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

Re: problems with keep-with-next

[Joerg Pietschmann]

Stephen Bannasch [EMAIL PROTECTED] wrote:
 keep-with-next still doesn't work on 0.20.3

It is implemented only for table rows.

 The problem is very annoying when I have a figure
 with a title on one page and the image on the next.

Put stuff that should be kept together in a one column
blind table and use keep-with-next on the rows. Be careful,
overdoing this could send FOP into an unterminating loop.

Please post followup questions on fop-user.

HTH
J.Pietschmann

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

Going in the _Forrest_ (was Re: FAQ Answers please)

[Nicola Ken Barozzi]

From: Joerg Pietschmann [EMAIL PROTECTED]

 Nicola Ken Barozzi [EMAIL PROTECTED] wrote:
  There is a new project in Apache called Forrest, that is redesigning the
  whole xml.apache.org site to become useful as a Sourceforge on steroids.
  We are at the beginning, and it would be cool if you join us there!

 Well, there are already GNUforge and PostNuke
 I hope you havn't fall prey to the NIH syndrome.

I hope too.
But *GNU stuff is off limits for Apache, as you know.
We have reviewed other projects, but they don't even come close to what we
envision.
If you have APL compatible projects that can help us, please let us know
([EMAIL PROTECTED]).

  Currently, there is a mailing list, forrest-dev and a CVS module
xml.forrest

 Would it still be possible to use established mechanisms
 as long as forrest is not put into production?

Of course.
Forrest will be an *option*, not an obligation.
It is *our* goal to do the work for you, not viceversa.

BTW, if you want, in the meantime I can make a patch to your build to use
Cocoon and the new slim xml.apache.org style that is in current Cocoon cvs.
It has the same LF of the current one but doesn't make use of batik, and
site is much slimmer.
The libs would be an additional 1.4 Mb, comprising the Avalon framework and
Excalibur jars that you will need anyways. The Cocoon jar itself is less
than 1Mb.

 It would be nice if you could give a short note about the
 current state and how the forrest project will influence
 the publication of FOP docs in the future (to keep it on
 topic for this list :-).

:-)

Forrest will make the FOP site pubblication a _piece of cake_, and we are
working with GUMP to integrate the two processes.
Basically, all you will need is to register up for forrest docs generation,
and that's it.

Forrest will trigger regularly on GUMP and:
 -get the xdocs from your CVS
 -get the results from the gump build
 -generate xml javadocs
 -massage everything with new slimfast stylesheets
 -deploy the site
 -mail nags to the mailing lists like:
   - pending patches
   - pending bugs
   - please suggest ;-)


This is the first phase.
Subsequent releases will grow based on demand and the Forrest project scope
in the README.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

Re: Area tree - renderer (pr.fo for structure renderers)

[Bertrand Delacretaz]

On Monday 18 March 2002 13:37, Peter B. West wrote:
. . .
 Bertrand Delacretaz wrote:
 In conclusion, I think an interface based on XML documents (possibly
 this pr.fo discussed above) is the best choice to use between the
  FOP property resolution stage and the structure renderers like
  RTF and MIF renderers.

 The big problem is in defining the p.res step.  How far do you need
 to go with this?  If you require all of the relative lengths
 resolved, e.g., you'll have to wait until the layout is done.  The
 properties are only finalised as the area tree is being constructed. 
 It's one of the things that makes this all so frustrating.

ok I see.
I'll try to play with this for RTF rendering based on jfor, to get a 
feel for how hard/useful this is. 

In case of jfor, what is needed is mostly property inheritance, for 
which AFAIK rules are well defined in FOP. 

I guess relative lengths will probably stay relative in the RTF code, 
but I'll have to play with it to be positive about this.

-Bertrand

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

Triggering WH2FO from inside Word(R)

[Matthias Fischer]

Would you think it a good idea to write a VB for Word(R) which:
1) Finds out the path/name of the active file
2) Automatically triggers WH2FO to transform the Word file

As an extension of this idea, would you consider it useful to insert into
the Word(R) menu a series of commands such as:
- Generate XHTML file
- Generate XML file
- Extract XSL file
- Generate XML and XSL files

Matthias


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

URI resolving

[Joerg Pietschmann]

Hi,
i did some thinking about FOP interfaces and especially
the URI resolving problem last weekend.

In JAXP you can do some rather geeky things with the
URIResolver:
- implement caches
- implement URL redirections
- implement your own protocols for synthetic XML
As an example for the latter,  use a filelist:/foo/bar
URL to produce a directory listing XML like
 filelist
   filebaz/file
 ...
by looping over File(/foo/bar).list() and fire SAX events.
This way you can XMLify all kind of odd external data and
pump it into the transformation process without bothering
with temporary files. This is possible because the URI resolving
method returns a javax.transform.Source, you can provide
your own implementation for an XMLReader and a sax.InputSource
and put them into a javax.xml.transform.sax.SAXInputSource
to get the effect described above (a more elaborate description
is in the XSL list archive).

In FOP, unfortunately, we have to deal with both XML sources
mainly for SVG and binary sources for most other formats. Well,
there's also PostScript which is a sort of character source.

It would be interesting to keep the possibility for dynamically
creating SVG or other XML based formats out of thin air by
directly firing SAX events or by providing a DOM tree, while
also having the ability to deal with non-XML formats.
One solution could be a delegation model

class XMLURIResolver {
  XMLURIResolver(BinaryStreamURIResolver bsur) {
   theBinaryStreamURIResolver=bsur;
  }
  Source resolve(String baseURI,String relURI) {
   return new SAXSource(getXMLReader(),
theBinaryStreamURIResolver.resolve(baseURI,relURI))
  }
}

The fo:externalGraphics handling code would somehow have to decide
whether the graphics is XML and invoke theXMLURIResolver.resolve(),
otherwise call theBinaryStreamURIResolver.resolve() directly. (It
may be an idea to provide an additional layer for character sources
like PostScript)
I'm not quite sure how FOP decides how to handle a certain input
for an external-graphic, i have faint memories that it first looks
at the content-type attribute and if there is none, it tries to
guess a content type from the URL. It may be an idea to give the
user hooks for this two mappings as well (content-type - content
handler and URL - content type).

Does this sound reasonable?
It would be interesting to see how JAXP will deal with XSLT 2.0,
there is also the possibility to import non-XML data.

There is another point: JAXP uses a factory pattern where the
factory creates a transformer for a single use holding the
compiled style sheet. The factory uses an URIResolver for resolving
URIs encoutered in xsl:include and xsl:import elements in the style
sheet. A transformer inherits the URIResolver form the factory, but
it is possible to set another URIResolver for resolving URIs
encountered during transformation.
In FOP, the analogs are resolving URIs which are part of the
configuration, like URIs pointig to font descriptions, and do not
depend on the FO input, and URIs which are encountered while
processing FO input. There are some arguments in favor of splitting
resolving responsibilities in FOP in a similar way, in particular if
a similar factory/processor pattern is choosen for  the FOP API.
The advantage of such a pattern would be that the factory instance
could efficiently cache configuration data while still having a
convenient way to override particular settings for individual
processor runs.

Regards
J.Pietschmann

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

printing problem with generated pdf

[Joerg Zielsdorf]

Hello,
I have got this problem:
when I generate a pdf via fop 0.20.03rc and want to print it from Acrobat
Reader on a post script printer HP LJ 8000, the characters in bold where
printed not in the right way. I use Win2K and Acrobat Reader 4.0.
One thing is that I use Arial font as in this list described. Whith Times
there is no problem.
Does anybody knows something about this?
Thanks,

Joerg


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


something.fo
Description: Binary data

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

FO to PDF XSL tranformation

[Libor Kramolis]

Hello all,

I am new to this mailing list, so excuse me if I ask already answered question.

Does anybody know about some XSL tranformation from Formatting Objects to 
PDF or other formats? If I correctly understand FOP is java implementation 
of such transformation. Don't you plan to rewrite FOP to set of 
transformations processed by xalan for example? Excuse me my questions. Why 
have you decided to implement fo2xxx as Java classes and not as XSLT? Is 
that reason bad speed of transformation engines? Or Java is more readable 
than xml file?

Thanks a lot.

Libor
-- 
Libor Kramolis, Software Engineer  | [EMAIL PROTECTED]
NetBeans/Sun Microsystems, XML Project | http://xml.netbeans.org/


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

Re: FO to PDF XSL tranformation

[alex]

At 17:16 18/03/02, Libor Kramolis wrote:
  Does anybody know about some XSL tranformation from Formatting Objects 
 to PDF or other  formats?


FOP is an implementation of part of the XSL spec - so is Xalan, but 
different parts of the spec.
Xalan converts XML to XML, and FOP converts XSL:FO (which is XML) to other 
formats which usually are not XML. They are both written in Java because 
the authors like Java :-)

Does that help explain things?


Alex


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

Re: Area tree - renderer (pr.fo for structure renderers)

[Peter B. West]

Bertrand,

There's another gotcha - markers.  The properties in markers are 
resolved relative to the retrieve-marker invocation point.

Peter

Bertrand Delacretaz wrote:

On Monday 18 March 2002 13:37, Peter B. West wrote:

The big problem is in defining the p.res step.  How far do you need
to go with this?  If you require all of the relative lengths
resolved, e.g., you'll have to wait until the layout is done.  The
properties are only finalised as the area tree is being constructed. 
It's one of the things that makes this all so frustrating.


ok I see.
I'll try to play with this for RTF rendering based on jfor, to get a 
feel for how hard/useful this is. 

In case of jfor, what is needed is mostly property inheritance, for 
which AFAIK rules are well defined in FOP. 

I guess relative lengths will probably stay relative in the RTF code, 
but I'll have to play with it to be positive about this.




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

Re: Area tree - renderer (pr.fo for structure renderers)

[Bertrand Delacretaz]

Hi Peter,

On Monday 18 March 2002 22:06, Peter B. West wrote:
. . .
 There's another gotcha - markers.  The properties in markers are
 resolved relative to the retrieve-marker invocation point.
. . .

Thanks - I'll keep this in mind when I get to play with this stuff..

-Bertrand

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

Suggestions for the How to get Help page

[Peter S. Housel]

1. In item 1, the word embed is spelled incorrectly.

2. The word get in the title should probably be capitalized.

3. A link to ESR's How to Ask Questions the Smart Way
(http://www.tuxedo.org/~esr/faqs/smart-questions.html) might be helpful.

Cheers,
-Peter S. Housel-   [EMAIL PROTECTED]


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

Using FOP with xmlspy

[Malcolm Sinclair]

Please excuse my asking this question on a developer's forum -- I realise it's 
off-topic.

Can you give me some hints, or can you put me in touch with someone who has 
successfully produced PDFs from .xml files in xmlspy? I have done this quite 
satisfactorily with fop-0.20.3 from the command line, but not from WITHIN xmlspy.

A few details:
   + I'm using the evaluation version of xmlspy,
   + I'm in touch with Altova's support people; they are trying to help, but as yet 
nothing resolved,
   + I'm a tech writer (novice in XML and no Java knowledge whatsoever)

I suspect the root of the problem is my unfamiliarity with XML; however, your 
suggestions could be very helpful just now


Thank you for your time

Malcolm


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

RE: Using FOP with xmlspy

[Savino, Matt C]

I know FOP through XMLSpy doesn't work on NT, I think that may apply to
Win98/95 as well.

Matt Savino



 -Original Message-
 From: Malcolm Sinclair [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 18, 2002 3:08 PM
 To: [EMAIL PROTECTED]
 Subject: Using FOP with xmlspy
 
 
 Please excuse my asking this question on a developer's forum 
 -- I realise it's off-topic.
 
 Can you give me some hints, or can you put me in touch with 
 someone who has successfully produced PDFs from .xml files in 
 xmlspy? I have done this quite satisfactorily with fop-0.20.3 
 from the command line, but not from WITHIN xmlspy.
 
 A few details:
+ I'm using the evaluation version of xmlspy,
+ I'm in touch with Altova's support people; they are 
 trying to help, but as yet nothing resolved,
+ I'm a tech writer (novice in XML and no Java knowledge 
 whatsoever)
 
 I suspect the root of the problem is my unfamiliarity with 
 XML; however, your suggestions could be very helpful just now
 
 
 Thank you for your time
 
 Malcolm
 
 
 -
 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: URI resolving

[Arved Sandstrom]

Comments below.

-Original Message-
From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]]
Sent: March 18, 2002 12:09 PM
To: FOP Dev
Subject: URI resolving

[ SNIP ]

The fo:externalGraphics handling code would somehow have to decide
whether the graphics is XML and invoke theXMLURIResolver.resolve(),
otherwise call theBinaryStreamURIResolver.resolve() directly. (It
may be an idea to provide an additional layer for character sources
like PostScript)
I'm not quite sure how FOP decides how to handle a certain input
for an external-graphic, i have faint memories that it first looks
at the content-type attribute and if there is none, it tries to
guess a content type from the URL. It may be an idea to give the
user hooks for this two mappings as well (content-type - content
handler and URL - content type).

[ SNIP ]

-End of Original Message-

Hi, Joerg

I snipped out the part that dealt with URI resolution; this is obviously
important, but since we have a 2-part problem - WHERE is the image and WHAT
is it - I'd rather deal with the WHAT first. Which is why I presently
addressing the above comments of yours.

However FOP does it now, all I know is that I personally distrust external
information - content-types and what have you. Let's keep in mind that
although we are using URI terminology a lot of these are going to be file:
URLs and the path of the file is going to be just about all we have to work
with. The file extension is reliable enough that it can be used for a first
guess but that is about it. But my current thought process is that FOP
doesn't worry about the WHAT at all - that's what the image library is for.

I came across this excellent list that Marco Schmidt has created:
http://www.geocities.com/marcoschmidt.geo/java-image-coding.html. Seems to
me that with this embarrassment of image-library riches all we should have
to do is define a simple interface that image readers must follow, and that
we then can write adapters that target some of the more useful libraries, as
required. From my viewpoint we'd be doing a good job if we can write
FOP-side code that doesn't even know what a JPEG or PNG or WMF or anything
else is. If the library of choice can't tell us that much, nor tell us about
the basic geometry that we need for layout, then what good is it?

This may turn out to be too simplistic and naive but I hold it up as a
desirable target. I have to research libraries that are available, and do
some coding and testing, to see if I am just talking through my hat, but I'd
sure like to see a situation where format-specific FOP classes disappear.

URI resolution is another matter. I haven't put any thought into it, other
than having read your comments. The one thing I'd mention right now is that
we need to look at how the available libraries expect to see image input.
Again, if most of the otherwise useful ones tend to fall short in this area
then we can always write adapters - which can be the same classes as the
adapters mentioned above.

Regards,
Arved Sandstrom


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

Re: Using FOP with xmlspy

[Joe Sytniak]

According to tech support, FOP only works with Win2k

- Original Message - 
From: Savino, Matt C [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 18, 2002 6:11 PM
Subject: RE: Using FOP with xmlspy


 I know FOP through XMLSpy doesn't work on NT, I think that may apply to
 Win98/95 as well.
 
 Matt Savino
 
 
 
  -Original Message-
  From: Malcolm Sinclair [mailto:[EMAIL PROTECTED]]
  Sent: Monday, March 18, 2002 3:08 PM
  To: [EMAIL PROTECTED]
  Subject: Using FOP with xmlspy
  
  
  Please excuse my asking this question on a developer's forum 
  -- I realise it's off-topic.
  
  Can you give me some hints, or can you put me in touch with 
  someone who has successfully produced PDFs from .xml files in 
  xmlspy? I have done this quite satisfactorily with fop-0.20.3 
  from the command line, but not from WITHIN xmlspy.
  
  A few details:
 + I'm using the evaluation version of xmlspy,
 + I'm in touch with Altova's support people; they are 
  trying to help, but as yet nothing resolved,
 + I'm a tech writer (novice in XML and no Java knowledge 
  whatsoever)
  
  I suspect the root of the problem is my unfamiliarity with 
  XML; however, your suggestions could be very helpful just now
  
  
  Thank you for your time
  
  Malcolm
  
  
  -
  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: Using FOP with xmlspy

[Malcolm Sinclair]

Thanks Matt -- since I'm using NT, that's certainly shortened my suffering!

Malcolm


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

Colon character problematic in xsl:template match=StringContainingColon ??

[Joe Sytniak]

All -I am using ADO to produce XML. This tends to get created as 
such: ?xml-stylesheet 
type="text/xsl"? xml 
xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" 
xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 
xmlns:rs="urn:schemas-microsoft-com:rowset" 
xmlns:z="#RowsetSchema" s:Schema 
id="RowsetSchema" . 
clipped schema elements 
/s:Schema 
rs:data z:row 
atributes go here/z:row 
/rs:dataI am able to create XSL for normal transformations to 
HTML just fine. But inorder to get XSLFO to work, I must change the names of 
the 'rs:data' and'z:row' nodes to something that does not contain a colon 
charater (ie.rs-data  z-row). This seems to indicate that it is the 
colon character thatis causing the problem. Not sure if it could be anything 
else. I suppose Icould copy nodes to another more friendly node, but it 
seems that thisshould not be necessary.Anyone have a better way of 
dealing with this?TIAJoe SytniakPhase Forward, 
Inc.

RE: Using FOP with xmlspy

[Art Welch]

Is that XMLSpy that only works with Win2k? FOP most definitely is NOT
limited to Win2k.

FOP should work on any platform with full JDK 1.2+ and AWT support.

-Original Message-
From: Joe Sytniak [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 18, 2002 6:19 PM
To: [EMAIL PROTECTED]
Subject: Re: Using FOP with xmlspy


According to tech support, FOP only works with Win2k

- Original Message - 
From: Savino, Matt C [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 18, 2002 6:11 PM
Subject: RE: Using FOP with xmlspy


 I know FOP through XMLSpy doesn't work on NT, I think that may apply to
 Win98/95 as well.
 
 Matt Savino
 
 
 
  -Original Message-
  From: Malcolm Sinclair [mailto:[EMAIL PROTECTED]]
  Sent: Monday, March 18, 2002 3:08 PM
  To: [EMAIL PROTECTED]
  Subject: Using FOP with xmlspy
  
  
  Please excuse my asking this question on a developer's forum 
  -- I realise it's off-topic.
  
  Can you give me some hints, or can you put me in touch with 
  someone who has successfully produced PDFs from .xml files in 
  xmlspy? I have done this quite satisfactorily with fop-0.20.3 
  from the command line, but not from WITHIN xmlspy.
  
  A few details:
 + I'm using the evaluation version of xmlspy,
 + I'm in touch with Altova's support people; they are 
  trying to help, but as yet nothing resolved,
 + I'm a tech writer (novice in XML and no Java knowledge 
  whatsoever)
  
  I suspect the root of the problem is my unfamiliarity with 
  XML; however, your suggestions could be very helpful just now
  
  
  Thank you for your time
  
  Malcolm
  
  
  -
  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]

Re: Using FOP with xmlspy

[Joe Sytniak]

No - it is an xmlspy limitation. To me, it appears that they do not support
the hook into the java vm with anything but win2k.

I too am running NT. FOP from the command line works fine. Cannot call it
from xmlspy.


- Original Message -
From: Art Welch [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 18, 2002 6:27 PM
Subject: RE: Using FOP with xmlspy


 Is that XMLSpy that only works with Win2k? FOP most definitely is NOT
 limited to Win2k.

 FOP should work on any platform with full JDK 1.2+ and AWT support.

 -Original Message-
 From: Joe Sytniak [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 18, 2002 6:19 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Using FOP with xmlspy


 According to tech support, FOP only works with Win2k

 - Original Message -
 From: Savino, Matt C [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, March 18, 2002 6:11 PM
 Subject: RE: Using FOP with xmlspy


  I know FOP through XMLSpy doesn't work on NT, I think that may apply to
  Win98/95 as well.
 
  Matt Savino
 
 
 
   -Original Message-
   From: Malcolm Sinclair [mailto:[EMAIL PROTECTED]]
   Sent: Monday, March 18, 2002 3:08 PM
   To: [EMAIL PROTECTED]
   Subject: Using FOP with xmlspy
  
  
   Please excuse my asking this question on a developer's forum
   -- I realise it's off-topic.
  
   Can you give me some hints, or can you put me in touch with
   someone who has successfully produced PDFs from .xml files in
   xmlspy? I have done this quite satisfactorily with fop-0.20.3
   from the command line, but not from WITHIN xmlspy.
  
   A few details:
  + I'm using the evaluation version of xmlspy,
  + I'm in touch with Altova's support people; they are
   trying to help, but as yet nothing resolved,
  + I'm a tech writer (novice in XML and no Java knowledge
   whatsoever)
  
   I suspect the root of the problem is my unfamiliarity with
   XML; however, your suggestions could be very helpful just now
  
  
   Thank you for your time
  
   Malcolm
  
  
   -
   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]



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

Plan for page-height and writing-mode

[Miya Chiharu]

Hello,

I want to use "indefinite" for page-height and "rl-tb" for writing-mode, 
but I can't use these value in fop.
Is there any plan to implement these features ?


-
Miya Chiharu


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

RE: Colon character problematic in xsl:templatematch=StringContainingColon ??

[Marylynne Henry]

Similarly, I 
am having problems with the '' character. Is there a way to escape this 
character when it appears in the text?

Thank 
you

Marylynne 
Henry


  -Original Message-From: Joe Sytniak 
  [mailto:[EMAIL PROTECTED]]Sent: Monday, March 18, 2002 5:22 
  PMTo: [EMAIL PROTECTED]Subject: Colon character 
  problematic in xsl:template match="StringContainingColon" 
  ??
  All -I am using ADO to produce XML. This tends to get created as 
  such: ?xml-stylesheet 
  type="text/xsl"? xml 
  xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" 
  xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 
  xmlns:rs="urn:schemas-microsoft-com:rowset" 
  xmlns:z="#RowsetSchema" s:Schema 
  id="RowsetSchema" . 
  clipped schema elements 
  /s:Schema 
  rs:data z:row 
  atributes go here/z:row 
  /rs:dataI am able to create XSL for normal transformations to 
  HTML just fine. But inorder to get XSLFO to work, I must change the names 
  of the 'rs:data' and'z:row' nodes to something that does not contain a 
  colon charater (ie.rs-data  z-row). This seems to indicate that it is 
  the colon character thatis causing the problem. Not sure if it could be 
  anything else. I suppose Icould copy nodes to another more friendly node, 
  but it seems that thisshould not be necessary.Anyone have a better 
  way of dealing with this?TIAJoe SytniakPhase Forward, 
  Inc.

Logging work: examples compilation fixes

[Michael Gratton]

The attached patch fixes the embedding examples so they compile again.

Mike.

-- 
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555


Index: docs/examples/embedding/FopServlet.java
===
RCS file: /home/cvspublic/xml-fop/docs/examples/embedding/FopServlet.java,v
retrieving revision 1.4.2.1
diff -u -r1.4.2.1 FopServlet.java
--- docs/examples/embedding/FopServlet.java 1 Mar 2002 12:44:39 -   1.4.2.1
+++ docs/examples/embedding/FopServlet.java 19 Mar 2002 04:19:09 -
@@ -16,8 +16,10 @@
 import org.apache.fop.apps.Driver;
 import org.apache.fop.apps.Version;
 import org.apache.fop.apps.XSLTInputHandler;
+import org.apache.fop.messaging.MessageHandler;
 
-import org.apache.log.*;
+import org.apache.avalon.framework.logger.ConsoleLogger;
+import org.apache.avalon.framework.logger.Logger;
 
 /**
  * Example servlet to generate a PDF from a servlet.
@@ -32,14 +34,13 @@
  * - servlet_2_2.jar
  * - fop.jar
  * - sax api
- * - logkit jar
+ * - avalon-framework-x.jar (where x is the version found the FOP lib dir)
  *
  * Running: you will need in the WEB-INF/lib/ directory:
  * - fop.jar
  * - batik.jar
- * - avalon-framework-4.0.jar
- * - logkit-1.0.jar
  * - xalan-2.0.0.jar
+ * - avalon-framework-x.jar (where x is the version found the FOP lib dir)
  */
 public class FopServlet extends HttpServlet {
 public static final String FO_REQUEST_PARAM = fo;
@@ -50,9 +51,8 @@
 public void doGet(HttpServletRequest request,
   HttpServletResponse response) throws ServletException {
 if(log == null) {
-Hierarchy hierarchy = Hierarchy.getDefaultHierarchy();
-log = hierarchy.getLoggerFor(fop);
-log.setPriority(Priority.WARN);
+log = new ConsoleLogger(ConsoleLogger.LEVEL_WARN);
+MessageHandler.setScreenLogger(log);
 }
 try {
 String foParam = request.getParameter(FO_REQUEST_PARAM);
Index: docs/examples/embedding/FopPrintServlet.java
===
RCS file: /home/cvspublic/xml-fop/docs/examples/embedding/Attic/FopPrintServlet.java,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 FopPrintServlet.java
--- docs/examples/embedding/FopPrintServlet.java1 Mar 2002 12:44:39 -  
 1.1.2.2
+++ docs/examples/embedding/FopPrintServlet.java19 Mar 2002 04:19:09 -
@@ -21,10 +21,12 @@
 import org.apache.fop.layout.Page;
 import org.apache.fop.apps.Version;
 import org.apache.fop.apps.XSLTInputHandler;
+import org.apache.fop.messaging.MessageHandler;
 
 import org.apache.fop.render.awt.AWTRenderer ;
 
-import org.apache.log.*;
+import org.apache.avalon.framework.logger.ConsoleLogger;
+import org.apache.avalon.framework.logger.Logger;
 
 /**
  * Example servlet to generate a fop printout from a servlet.
@@ -40,13 +42,12 @@
  * - servlet_2_2.jar
  * - fop.jar
  * - sax api
- * - logkit jar
+ * - avalon-framework-x.jar (where x is the version found the FOP lib dir)
  *
  * Running: you will need in the WEB-INF/lib/ directory:
  * - fop.jar
  * - batik.jar
- * - avalon-framework-4.0.jar
- * - logkit-1.0.jar
+ * - avalon-framework-x.jar (where x is the version found the FOP lib dir)
  * - xalan-2.0.0.jar
  */
  
@@ -62,9 +63,8 @@
   {
 if (log == null) 
   {
-Hierarchy hierarchy = Hierarchy.getDefaultHierarchy();
-log = hierarchy.getLoggerFor(fop);
-log.setPriority(Priority.WARN);
+log = new ConsoleLogger(ConsoleLogger.LEVEL_WARN);
+MessageHandler.setScreenLogger(log);
   }
 
 try  



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Logging work: MessageHandler patch

[Michael Gratton]

Michael Gratton wrote:
 
 Attached is a patch (for the 'fop-0_20_2-maintain' branch) for 
 MessageHandler

There was a problem with MessageHandler.error() in that patch. The 
attached patch fixes that and makes MessageHandler.log() a bit more 
readable. It also includes a fix for the outstanding 
ToBeImplementedProperty problem - by using MessageHandler.

Note that the document patch on the previous message is still valid.

Mike.
-- 
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555


Index: src/org/apache/fop/messaging/MessageHandler.java
===
RCS file: 
/home/cvspublic/xml-fop/src/org/apache/fop/messaging/Attic/MessageHandler.java,v
retrieving revision 1.6.2.1
diff -u -r1.6.2.1 MessageHandler.java
--- src/org/apache/fop/messaging/MessageHandler.java17 Mar 2002 23:37:07 - 
 1.6.2.1
+++ src/org/apache/fop/messaging/MessageHandler.java19 Mar 2002 04:46:04 -
@@ -48,6 +48,7 @@
 public static final int EVENT = 2;
 public static final int NONE = 3;// this should always be the last method
 
+private static Logger logger = null;
 private static String logfileName = fop.log;
 private static PrintWriter writer;
 private static int outputMethod = SCREEN;
@@ -81,47 +82,47 @@
 }
 }
 
-// temp workaround
-private static Logger logger = null;
-
 /**
  * informs the user of the message
  * @param message the message for the user
  */
 public static void log(String message) {
-if (!quiet) {
-if(logger == null) {
-logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
-}
-setMessage(message);
-switch (outputMethod) {
-case SCREEN:
-logger.debug(getMessage());
-break;
-case FILE:
-if (fileOpened) {
-writer.print(getMessage());
-writer.flush();
-} else {
-openFile();
-writer.print(getMessage());
-writer.flush();
-}
-break;
-case EVENT:
-setMessage(message);
-Enumeration enum = listeners.elements();
-while (enum.hasMoreElements()) {
-((MessageListener)enum.nextElement()).processMessage(new 
MessageEvent(getMessage()));
-}
-break;
-case NONE:
-// do nothing
-break;
-default:
-logger.debug(message);
-}
-}
+if (quiet)
+   return;
+
+   if (logger == null) {
+   logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
+   logger.warn(Screen logger not set.);
+   }
+   
+   setMessage(message);
+   switch (outputMethod) {
+   case SCREEN:
+   logger.debug(getMessage());
+   break;
+   case FILE:
+   if (fileOpened) {
+   writer.print(getMessage());
+   writer.flush();
+   } else {
+   openFile();
+   writer.print(getMessage());
+   writer.flush();
+   }
+   break;
+   case EVENT:
+   setMessage(message);
+   Enumeration enum = listeners.elements();
+   while (enum.hasMoreElements()) {
+   ((MessageListener)enum.nextElement()).processMessage(new 
+MessageEvent(getMessage()));
+   }
+   break;
+   case NONE:
+   // do nothing
+   break;
+   default:
+   logger.debug(message);
+   }
 }
 
 /**
@@ -138,9 +139,11 @@
  */
 
 public static void error(String errorMessage) {
-if(logger == null) {
-logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
-}
+   if (logger == null) {
+   logger = new ConsoleLogger(ConsoleLogger.LEVEL_INFO);
+   logger.warn(Screen logger not set.);
+   }
+
 setMessage(errorMessage);
 switch (outputMethod) {
 case SCREEN:
@@ -195,6 +198,16 @@
  */
 public static void removeListener(MessageListener listener) {
 listeners.removeElement(listener);
+}
+
+/**
+ * Sets the Logger used for the screen output method.
+ * @param newLogger a logger for screen output. This may not be null.
+ */
+public static void setScreenLogger(Logger newLogger) {
+   if (newLogger == null)
+   throw new NullPointerException();
+   logger = newLogger;
 }
 
 /**
Index: src/org/apache/fop/apps/CommandLineOptions.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/apps/CommandLineOptions.java,v
retrieving revision 

RE: Colon character problematic in xsl:template match=StringContainingColon ??

[Adrian Edwards]

Dear 
Joe,

You 
have opened a can of worms. See the last QA at:

 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/htm/xslt_starter_8f3o.asp

which 
shows you how to make the transformation work with MSXML, but I'm not sure the 
fragment identifier as namespace identifier ('#RowsetSchema') will work with 
Xalan. The namespace issues that Microsoft have built into their ADO 
persisted XML have sparked long and controversial discussions among greater 
minds than ours. Perhaps it's time to move to ADO.NET?

You 
say that you are "able to create XSL for normal transformations to HTML just 
fine", but I assume that you are using MSXML as your XSLT engine (probably 
through IE?). Try using any other XSLT engine and I'll wager your "normal" 
transformation to HTML won't work.

BTW, 
is this really a question for fop-dev? Perhaps you aren't aware of the [EMAIL PROTECTED]mailing 
list... Even then, the issue really has little to do with fop, 
being largely a general XSLT issue. That is, you would have the same 
problem transforming ADO persisted XML to any schema, not just 
XSL-FO.

Still, 
happy to help initially.

Adrian 
Edwards
Netimpact Online Publishing
http://www.netimpact.com.au

  -Original Message-From: Joe Sytniak 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, 19 March 2002 10:22 
  AMTo: [EMAIL PROTECTED]Subject: Colon character 
  problematic in xsl:template match="StringContainingColon" 
  ??
  All -I am using ADO to produce XML. This tends to get created as 
  such: ?xml-stylesheet 
  type="text/xsl"? xml 
  xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" 
  xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 
  xmlns:rs="urn:schemas-microsoft-com:rowset" 
  xmlns:z="#RowsetSchema" s:Schema 
  id="RowsetSchema" . 
  clipped schema elements 
  /s:Schema 
  rs:data z:row 
  atributes go here/z:row 
  /rs:dataI am able to create XSL for normal transformations to 
  HTML just fine. But inorder to get XSLFO to work, I must change the names 
  of the 'rs:data' and'z:row' nodes to something that does not contain a 
  colon charater (ie.rs-data  z-row). This seems to indicate that it is 
  the colon character thatis causing the problem. Not sure if it could be 
  anything else. I suppose Icould copy nodes to another more friendly node, 
  but it seems that thisshould not be necessary.Anyone have a better 
  way of dealing with this?TIAJoe SytniakPhase Forward, 
  Inc.