You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Mikael St�ldal <d9...@d.kth.se> on 2000/08/15 23:20:13 UTC
Problem with SAX2 in FOP 0.14.0
FOP 0.14.0 doesn't seems to handle SAX2 and namespaces correctly, the
following program (using Xerces 1.1.2):
import java.io.*;
import org.xml.sax.*;
import org.apache.fop.apps.*;
import org.apache.xerces.parsers.*;
public class FOPandSAX2
{
public static void main(String[] args) throws Exception
{
Driver driver = new Driver();
driver.setRenderer("org.apache.fop.render.pdf.PDFRenderer",
Version.getVersion());
driver.addElementMapping("org.apache.fop.fo.StandardElementMapping");
driver.addElementMapping("org.apache.fop.svg.SVGElementMapping");
driver.setWriter(new PrintWriter(new FileWriter(args[1])));
XMLReader parser = new SAXParser();
parser.setContentHandler(driver.getContentHandler());
parser.parse(new InputSource(args[0]));
driver.format();
driver.render();
}
}
gives:
org.apache.fop.apps.FOPException: Unknown namespace prefix fo
at java.lang.Throwable.<init>(Throwable.java:63)
at java.lang.Exception.<init>(Exception.java:28)
at org.xml.sax.SAXException.<init>(SAXException.java:61)
at org.apache.fop.fo.FOTreeBuilder.mapName(FOTreeBuilder.java:148)
at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:251)
at
org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1361)
with a FO file which is correctly processed by using
org.apache.fop.apps.CommandLine.
I had a quick look at the code, and it seems like that the
FOTreeBuilder expect that the rawName attribute in the SAX2
ContentHandler.startElement event to be present. It can be the empty
string according to the SAX2 docs. FOP should make use of the uri and
localName attributes instead.
--
/****************************************************************\
* You have just read a message from Mikael Ståldal. *
* *
* Remove "-ingen-reklam" from the address before mail replying. *
\****************************************************************/
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Stefano Mazzocchi <st...@apache.org>.
Karen Lease wrote:
>
> Arved Sandstrom wrote:
> >
> > On Tue, 22 Aug 2000, Karen Lease wrote:
> > > Well I can certainly tell that I'm outnumbered here!
> >
> > You have a strong point of view that almost nobody else agrees with. :-) I've
> > been in that boat hundreds of times.
>
> It's not my first time either, so don't worry about it scaring me off!
>
> SNIP SNIP
> [Arved]
> > To me the important thing is that everyone, yourself included, is happy with
> > this whole thing before we proceed with doing properties. As a matter of fact,
> > since you have devoted serious time to this area already, I consider it
> > particularly important that you are easy with FOP as a complete FO processor
> > according to the XSL spec.
> >
> > I personally consider the naming of XSL and XSLT to be unfortunate. An XML
> > "stylesheet", to me, is the specific combination of an XSLT file containing an
> > <xsl:stylesheet> element and its kids, which never should have been called a
> > stylesheet, _and_ literal result elements in the
> > http://www.w3.org/1999/XSL/Format namespace. If it's not that exact combination
> > then it's not a stylesheet, element names and popular usage be hanged.
> >
> > Half of our discussion here has to do, I believe, with this bad choice of
> > language. If XSLT was called XMLT, and XSL was called XML-FO, then we'd be
> > happier. Well, I'd be happier. :-)
> >
> > To me the key thing about XSLT is that it should know nothing about result
> > namespaces, and do no processing for nodes in those result namespaces.
> > XSLT bowed to real life in transgressing this, by introducing an HTML output
> > mode, but now that we have XHTML hopefully that idea will die. I see an
> > absolute separation between production of the raw FO tree and its formatting -
> > the former happens however it happens and XSL covers the latter, which is the
> > charter of FOP.
> >
> > I hope you don't feel overwhelmed by this. You're coming in from SGML and
> > DSSSL, and the divisions of duties are different there. I welcome the debate
> > and I think the discussion has forced us to revisit what FOP does, should do,
> > and what it doesn't do (the latter being equally important). I also highly
> > value your contribution so far and I hope that your work on properties (past,
> > present and future) figures prominently in FOP.
> >
> > Regards, Arved
> > --
> > Senior Developer
> > e-plicity.com (www.e-plicity.com)
> > Halifax, Nova Scotia
> > "B2B Wireless in Canada's Ocean Playground"
>
> I'm very happy to have had this e-discussion, and I will certainly
> continue to think about your very clearly expressed position. But for
> the moment I'm also finally trying to get my table code working so that
> we can have columns and row spans, and I think I will give preference to
> that.
I agree. Let's get things done first, then we'll see how "pure" they are
in respect on different visions around.
> This is my first totally email-based group project and I find it takes a
> lot of time and energy to participate in discussions - and is certainly
> less efficient that face-to-face talking in many cases. (Probably
> quieter though, especially since this group isn't too prone to
> flame-throwing...) I now see better where you (and apparently most other
> FOP'ers) are coming from... but there are still some things I'm not sure
> I agree with. But they'll wait.. on with FOP!
It's for sure less efficient in terms of time, but, believe me, it's
much more efficient in term of energy involved and results to achieve:
how else would you manage to work with hundreds of people scattered all
around a planet as big as ours? :)
Sure, it would be just wonderful if we all lived in the same block (like
ancient greeks in Athens) and talked every evening, but it would get
boring and the diversities that make us such a nice group of individuals
will simply fade away.
It takes time to get used to it, but believe me, there is nothing
inefficient in distributed development if it's done in the right way and
with the right attitude (no group under Apache is prone to
flame-throwing: respect is the ultimate engine for us).
Anyway, I'm happy to preach to the converted :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Karen Lease <kl...@club-internet.fr>.
Arved Sandstrom wrote:
>
> On Tue, 22 Aug 2000, Karen Lease wrote:
> > Well I can certainly tell that I'm outnumbered here!
>
> You have a strong point of view that almost nobody else agrees with. :-) I've
> been in that boat hundreds of times.
It's not my first time either, so don't worry about it scaring me off!
SNIP SNIP
[Arved]
> To me the important thing is that everyone, yourself included, is happy with
> this whole thing before we proceed with doing properties. As a matter of fact,
> since you have devoted serious time to this area already, I consider it
> particularly important that you are easy with FOP as a complete FO processor
> according to the XSL spec.
>
> I personally consider the naming of XSL and XSLT to be unfortunate. An XML
> "stylesheet", to me, is the specific combination of an XSLT file containing an
> <xsl:stylesheet> element and its kids, which never should have been called a
> stylesheet, _and_ literal result elements in the
> http://www.w3.org/1999/XSL/Format namespace. If it's not that exact combination
> then it's not a stylesheet, element names and popular usage be hanged.
>
> Half of our discussion here has to do, I believe, with this bad choice of
> language. If XSLT was called XMLT, and XSL was called XML-FO, then we'd be
> happier. Well, I'd be happier. :-)
>
> To me the key thing about XSLT is that it should know nothing about result
> namespaces, and do no processing for nodes in those result namespaces.
> XSLT bowed to real life in transgressing this, by introducing an HTML output
> mode, but now that we have XHTML hopefully that idea will die. I see an
> absolute separation between production of the raw FO tree and its formatting -
> the former happens however it happens and XSL covers the latter, which is the
> charter of FOP.
>
> I hope you don't feel overwhelmed by this. You're coming in from SGML and
> DSSSL, and the divisions of duties are different there. I welcome the debate
> and I think the discussion has forced us to revisit what FOP does, should do,
> and what it doesn't do (the latter being equally important). I also highly
> value your contribution so far and I hope that your work on properties (past,
> present and future) figures prominently in FOP.
>
> Regards, Arved
> --
> Senior Developer
> e-plicity.com (www.e-plicity.com)
> Halifax, Nova Scotia
> "B2B Wireless in Canada's Ocean Playground"
I'm very happy to have had this e-discussion, and I will certainly
continue to think about your very clearly expressed position. But for
the moment I'm also finally trying to get my table code working so that
we can have columns and row spans, and I think I will give preference to
that.
This is my first totally email-based group project and I find it takes a
lot of time and energy to participate in discussions - and is certainly
less efficient that face-to-face talking in many cases. (Probably
quieter though, especially since this group isn't too prone to
flame-throwing...) I now see better where you (and apparently most other
FOP'ers) are coming from... but there are still some things I'm not sure
I agree with. But they'll wait.. on with FOP!
Best regards,
Karen
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
On Tue, 22 Aug 2000, Karen Lease wrote:
> Well I can certainly tell that I'm outnumbered here!
You have a strong point of view that almost nobody else agrees with. :-) I've
been in that boat hundreds of times.
> What I mean is not to tie FOP to an XSLT processor but to a real XSL
> (FO) processor, one which would implement the XSL Draft or (hopefully,
> some day) XSL Recommendation.
> When I talk about extending an XSLT processor, the idea is to turn it
> into an XSLFO processor, or rather the front end of one. I see FOP as
> the backend of an XSLFO processor, the one the does the layout and
> rendering based on the description of the flow objects. I think we all
> agree on that.
I'm not so sure that I do. The FOP charter is to be an FO processor. According
to the XSL spec FO processing starts with unrefined formatting objects, and the
actual phases of formatting are objectifying, refinement and area-tree
production. Rendering is really a follow-on.
XSLT processors implementing the XSLT Recommendation do very little for us, in
the general picture. There is one small chunk of a secondary part of XPath that
overlaps, but what you are describing is a processor that does XSLT and the
first half of XSL. Nothing illegal about that; it's just that the left-over bit
would not be an FO processor and it would be hard to call it FOP. :-) It would
just be a layout engine.
> I will also admit that some of the XSL-defined functions seem to need
> not only property information but some layout information. This is
> harder to handle, and in fact, I tend to think that it's a bad idea
> because it makes it harder to separate FO specification from FO
> processing.
I missed seeing any so far. I stand to be corrected, though.
> I see FOP's current state of development as the result of the fact that
> there is no XSLFO processor, only XSLT processors. So we have made the
> best of a bad situation by reading "FO" files. We can keep on doing
> this, regardless of what tool makes them. I am simply arguing that it is
> NOT FOP's business to handle expressions in the property attribute
> values. It has enough work to do just trying to build areas, especially
> if we need to do some intelligent page layout (keeps, breaks...) and
> handle other writing modes.
Ahh, but the XSL spec _makes_ expression handling in property attributes the
business of a formatting object processor. If we were to re-charter FOP just to
be a layout engine, _then_ it would not be FOP's business. :-)
> My experiment with XT/FOP interaction was based on defining an interface
> which describes the XSL specific functions. FOP (or any other FO tool)
> implements this to allow it to provide information to any XSL engine
> (using the XSLT extension function mechanism for example). So the idea
> is certainly not to tie FOP to any particular processing front-end.
>
> Whew, so much for being lazy!
>
> Karen
To me the important thing is that everyone, yourself included, is happy with
this whole thing before we proceed with doing properties. As a matter of fact,
since you have devoted serious time to this area already, I consider it
particularly important that you are easy with FOP as a complete FO processor
according to the XSL spec.
I personally consider the naming of XSL and XSLT to be unfortunate. An XML
"stylesheet", to me, is the specific combination of an XSLT file containing an
<xsl:stylesheet> element and its kids, which never should have been called a
stylesheet, _and_ literal result elements in the
http://www.w3.org/1999/XSL/Format namespace. If it's not that exact combination
then it's not a stylesheet, element names and popular usage be hanged.
Half of our discussion here has to do, I believe, with this bad choice of
language. If XSLT was called XMLT, and XSL was called XML-FO, then we'd be
happier. Well, I'd be happier. :-)
To me the key thing about XSLT is that it should know nothing about result
namespaces, and do no processing for nodes in those result namespaces.
XSLT bowed to real life in transgressing this, by introducing an HTML output
mode, but now that we have XHTML hopefully that idea will die. I see an
absolute separation between production of the raw FO tree and its formatting -
the former happens however it happens and XSL covers the latter, which is the
charter of FOP.
I hope you don't feel overwhelmed by this. You're coming in from SGML and
DSSSL, and the divisions of duties are different there. I welcome the debate
and I think the discussion has forced us to revisit what FOP does, should do,
and what it doesn't do (the latter being equally important). I also highly
value your contribution so far and I hope that your work on properties (past,
present and future) figures prominently in FOP.
Regards, Arved
--
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Max Froumentin <mf...@w3.org>.
The XSL spec states that "an implementation is free to process the
source document in any way that produces the same result as if it were
processed using the conceptual XSL processing model." My understanding
of this is that what you call a "full XSL processor" cannot do
something that can't be done using XSLT + FO. This implies that
whatever your processor does, it must be able to be described as
XSLT+FO, i.e. unit arithmetic must be defined to go in either xslt or
fo.
Even if XSLT was intended for styling in the first place, its use is
now too general to handle a particular problem such as handling unit
conversion. My opinion is that FOTreeBuilder should handle that.
I am not convinced that value arithmetic is so important with the FO
model. Your example is actually the only problem I've come across
where explicit arithmetic is needed, and I believe that's because FO
lacks a table rendering method (RenderX have even wrote extension
functions to format tables). If you can convince me otherwise with
more test cases, I'll revise my judgment, and I'll bring the issue to
the XSL working group.
Max.
--
Max Froumentin - W3C
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Karen Lease <kl...@club-internet.fr>.
You all wrote....my answer is at the end :-)
Stefano Mazzocchi wrote:
>
> Arved Sandstrom wrote:
> >
> > At 10:40 AM 8/22/00 +0200, Fotis Jannidis wrote:
> >
> > Karen wrote:
> > >> Yes, and I don't want to start a war tonight :-).
> > >> My main motivation is laziness. We would have to duplicate a lot of
> > >> expression handling inside FOP attribute parsing. I have always thought
> > >> of XSL being the main specification and the XSLT part being just a means
> > >> to the end. Maybe I see it this way because I was familiar with DSSSL
> > >> before XSL, and in particular with J. Clark's jade implementation. The
> > >> front end interpreter did all the expression handling and the back end
> > >> formatters only had to deal with the resulting value for each property.
> > >> However, I will think more about your point of view.
> > >
[Fotis]
> > >Maybe I misunderstood Karen's argument, but doesn't her proposal
> > >tie Fop quite closely to xslt, that is Fop then would expect as input
> > >xml+xslt files? Wouldn't it be cleaner to say: Fop gets as input xsl:fo
> > >files and we don't care how they are created (Certainly most of them
> > >via xml+xslt, but I still think that xml+css will also be way, or even
> > >directly generated fo files)? Or do you want to use an xslt processor
> > >on the xsl:fo file?
> > >
> > >Fotis
> > >
[Arved]
> > The argument that Fotis presents accords with mine, I think. We have to
> > assume that we may start with FO files, with all elements being in the
> > http://www.w3.org/1999/XSL/Format namespace. XSLT may not be in the picture
> > at all.
[Stefano]
> Totally agreed.
>
> It's not only laziness, it's an engineering practice and it's called
> "separation of concerns": FOP should not be concerned about "what"
> produced markup that it renders, just do its rendering job the best it
> can.
>
> However, if FOP requires access to XPath facilities "internally", well,
> I'm a member of the Sun JAXP working group that is in charge of defyning
> the "javax.xml" API for the future JDKs and any input/request is welcome
> and will be pushed forward.
>
[Karen]
Well I can certainly tell that I'm outnumbered here! (And on a totally
off-track subject, I'd sure like my email reader to color all our voices
differently...)
What I mean is not to tie FOP to an XSLT processor but to a real XSL
(FO) processor, one which would implement the XSL Draft or (hopefully,
some day) XSL Recommendation.
When I talk about extending an XSLT processor, the idea is to turn it
into an XSLFO processor, or rather the front end of one. I see FOP as
the backend of an XSLFO processor, the one the does the layout and
rendering based on the description of the flow objects. I think we all
agree on that.
The main difference between an XSLT processor and a full XSL processor
is that the latter understands the property semantics of the result tree
which it is building. This lets it deal with functions involving
inherited values. A typical example is something like:
<fo:block start-indent='inherited-property-value("start-indent") + 1pc'>
To handle this, the XSL processor needs to know how to do arithmetic on
quantity values (1pc) and it needs to know where to find the inherited
value of start-indent, which means that it has access to the path from
this fo:block which is being created and to its ancestors up to the root
level. This is basically equivalent to the FOTreeBuilder process in FOP.
(Actually, an XSL processor doesn't need to build the whole tree; it
just needs to maintain state for the current path. This is pretty much
how jade works and it means that the back-end processors handle only raw
property datatypes.)
So you say, why not just implement these functions in FOP, which will
interpret them as it is building the FO tree and before laying it out?
Look at the following example, which I actually wrote to generate
absolute column-widths for FOP's table layout. This expression must be
evaluated by the XSL processor because it uses values from the input XML
tree.
<xsl:variable name="pagewidth" select="16cm"/>
....
<xsl:template match="col">
<fo:table-column>
<xsl:attribute name="column-width">
<xsl:value-of select='$pagewidth * @relwidth div
sum(../col/@relwidth)' />
</xsl:attribute>
<xsl:apply-templates/>
</fo:table-column>
</xsl:template>
The only way to do it with a "straight" XSLT processor is this, where
the "cm" has moved from the variable into the attribute specification.
<xsl:variable name="pagewidth" select="16"/>
...
<xsl:template match="col">
<!--<fo:table-column column-width="{@width}">-->
<fo:table-column>
<xsl:attribute name="column-width">
<xsl:value-of select='$pagewidth * @relwidth div
sum(../col/@relwidth)' />cm</xsl:attribute>
<xsl:apply-templates/>
</fo:table-column>
</xsl:template>
I admit that this isn't a very pretty example, but I hope you'll agree
that the first way of writing it is a lot more natural!
I will also admit that some of the XSL-defined functions seem to need
not only property information but some layout information. This is
harder to handle, and in fact, I tend to think that it's a bad idea
because it makes it harder to separate FO specification from FO
processing.
I see FOP's current state of development as the result of the fact that
there is no XSLFO processor, only XSLT processors. So we have made the
best of a bad situation by reading "FO" files. We can keep on doing
this, regardless of what tool makes them. I am simply arguing that it is
NOT FOP's business to handle expressions in the property attribute
values. It has enough work to do just trying to build areas, especially
if we need to do some intelligent page layout (keeps, breaks...) and
handle other writing modes.
My experiment with XT/FOP interaction was based on defining an interface
which describes the XSL specific functions. FOP (or any other FO tool)
implements this to allow it to provide information to any XSL engine
(using the XSLT extension function mechanism for example). So the idea
is certainly not to tie FOP to any particular processing front-end.
Whew, so much for being lazy!
Karen
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Stefano Mazzocchi <st...@apache.org>.
Arved Sandstrom wrote:
>
> At 10:40 AM 8/22/00 +0200, Fotis Jannidis wrote:
>
> Karen wrote:
> >> Yes, and I don't want to start a war tonight :-).
> >> My main motivation is laziness. We would have to duplicate a lot of
> >> expression handling inside FOP attribute parsing. I have always thought
> >> of XSL being the main specification and the XSLT part being just a means
> >> to the end. Maybe I see it this way because I was familiar with DSSSL
> >> before XSL, and in particular with J. Clark's jade implementation. The
> >> front end interpreter did all the expression handling and the back end
> >> formatters only had to deal with the resulting value for each property.
> >> However, I will think more about your point of view.
> >
> >Maybe I misunderstood Karen's argument, but doesn't her proposal
> >tie Fop quite closely to xslt, that is Fop then would expect as input
> >xml+xslt files? Wouldn't it be cleaner to say: Fop gets as input xsl:fo
> >files and we don't care how they are created (Certainly most of them
> >via xml+xslt, but I still think that xml+css will also be way, or even
> >directly generated fo files)? Or do you want to use an xslt processor
> >on the xsl:fo file?
> >
> >Fotis
> >
> >BTW: Karen as committer +1
>
> And my +1 also. I'll give it a day or 2 more, wait for some extra votes, and
> contact Brian with a list, since that seems to be expected.
>
> The argument that Fotis presents accords with mine, I think. We have to
> assume that we may start with FO files, with all elements being in the
> http://www.w3.org/1999/XSL/Format namespace. XSLT may not be in the picture
> at all.
Totally agreed.
It's not only laziness, it's an engineering practice and it's called
"separation of concerns": FOP should not be concerned about "what"
produced markup that it renders, just do its rendering job the best it
can.
However, if FOP requires access to XPath facilities "internally", well,
I'm a member of the Sun JAXP working group that is in charge of defyning
the "javax.xml" API for the future JDKs and any input/request is welcome
and will be pushed forward.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 10:40 AM 8/22/00 +0200, Fotis Jannidis wrote:
Karen wrote:
>> Yes, and I don't want to start a war tonight :-).
>> My main motivation is laziness. We would have to duplicate a lot of
>> expression handling inside FOP attribute parsing. I have always thought
>> of XSL being the main specification and the XSLT part being just a means
>> to the end. Maybe I see it this way because I was familiar with DSSSL
>> before XSL, and in particular with J. Clark's jade implementation. The
>> front end interpreter did all the expression handling and the back end
>> formatters only had to deal with the resulting value for each property.
>> However, I will think more about your point of view.
>
>Maybe I misunderstood Karen's argument, but doesn't her proposal
>tie Fop quite closely to xslt, that is Fop then would expect as input
>xml+xslt files? Wouldn't it be cleaner to say: Fop gets as input xsl:fo
>files and we don't care how they are created (Certainly most of them
>via xml+xslt, but I still think that xml+css will also be way, or even
>directly generated fo files)? Or do you want to use an xslt processor
>on the xsl:fo file?
>
>Fotis
>
>BTW: Karen as committer +1
And my +1 also. I'll give it a day or 2 more, wait for some extra votes, and
contact Brian with a list, since that seems to be expected.
The argument that Fotis presents accords with mine, I think. We have to
assume that we may start with FO files, with all elements being in the
http://www.w3.org/1999/XSL/Format namespace. XSLT may not be in the picture
at all.
When I look at the spec section on expressions I see commonality only with
the most basic stuff - simple arithmetic and simple arithmetic core
functions. Most of the stuff is peculiar to XSL-FO. What I think we might
end up borrowing, if at all, is a simple expression parser; XPath is
overkill, let alone XSLT.
It's been a while since I used Jade but my impression there was that the
division of labour between the processing stages was indeed different.
I'm personally always receptive to the laziness argument; in this case I'm
not sure that we have much to gain.
Arved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.
> > >KL: Are you referring to the stuff I mentioned a few months ago?
> > >Actually, what I had done was modify XT's basic expression handling so
> > >that it knew how to handle quantities with units, mixed with other
> > >expressions. I strongly think this code belongs in the basic XSL(T/FO)
> > >engine and not in the FOP part. So this works in my private XT. I
> > >haven't looked at what it would take to do that kind of modification in
> > >Xalan.
> > Arved:
> > If we consider the stages to be (1) FO tree production with properties
> > refinement/resolution, (2) area-tree production, and (3) rendering, then I
> > agree that big chunks of (1), particularly arithmetic expressions and many
> > of the core functions, look like stuff that XSLT is doing.
> >
> > I'm thinking that the similarities may be somewhat superficial. The context
> > within which XSLFO expressions are evaluated is quite different than that
> > which obtains for XSLT. We may wish to explore access to an XPath processor
> > but I don't know if trying to integrate tightly with an existing XSLT
> > processor will be worth it.
> >
> > My viewpoint is based on the fact that XSLT could care less about what XML
> > it is churning out, whether it be FO's or ArvedML. There is a clean
> > separation between XSLT and XSLFO. There may be a language thing here, too -
> > it depends on what you consider to be the basic "engine". If you mean the
> > stuff that produces the FO tree, then yes; but this is not XSLT either.
> >
> > I don't doubt but that there will be heated discussion about this one.
>
> Yes, and I don't want to start a war tonight :-).
> My main motivation is laziness. We would have to duplicate a lot of
> expression handling inside FOP attribute parsing. I have always thought
> of XSL being the main specification and the XSLT part being just a means
> to the end. Maybe I see it this way because I was familiar with DSSSL
> before XSL, and in particular with J. Clark's jade implementation. The
> front end interpreter did all the expression handling and the back end
> formatters only had to deal with the resulting value for each property.
> However, I will think more about your point of view.
Maybe I misunderstood Karen's argument, but doesn't her proposal
tie Fop quite closely to xslt, that is Fop then would expect as input
xml+xslt files? Wouldn't it be cleaner to say: Fop gets as input xsl:fo
files and we don't care how they are created (Certainly most of them
via xml+xslt, but I still think that xml+css will also be way, or even
directly generated fo files)? Or do you want to use an xslt processor
on the xsl:fo file?
Fotis
BTW: Karen as committer +1
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Karen Lease <kl...@club-internet.fr>.
On Mon, 21 Aug 2000 06:41:58 -0300, Arved Sandstrom wrote:
>
> At 12:30 AM 8/21/00 +0200, Karen Lease wrote:
> >Arved Sandstrom wrote:
> >
> >> On a related note, I was thinking through our plan of attack for FOP. I'll
> >> be putting out a planning document shortly that talks about that. In the
> >> interim, it occurs to me that we can start putting _every_ property in
> >> place, starting with properties.xml, and ensuring that the datatypes are
> >> there to support those properties (I wrote an Orientation class, for
> >> example, to support 90 deg multiple angles).
> >
> >KL: I have started to write some new datatypes too: LengthRange, Space,
> >Keep, Precedence. Also, I have done quite a lot of thinking about
> >several other aspects of properties.xml:
>
> OK, this sounds real good. I sort of see full properties support as being
> the first phase, although aspects of other FOP development can proceed
> independently. I'll accelerate the production of a properties implementation
> plan, specifically.
>
> >1. handling "corresponding" properties (Western-writing mode centric
> >ones like "top", "left" and the their neutral equivalents like "before",
> >"start". We need to be able to compute one from the other. I have done a
> >few tests with some XSL expressions to generate code for this.
>
> "top", "left" etc aren't Western-centric per se, just "absolute" - the
> others are "relative". What _is_ Western-centric is our assumption that
> "top" == "before".
Yes, of course.
> >2. handling properties with components (space-before.minimum, etc) in a
> >general way
> >
> >3. handling all keyword values for non-enumerated properties, like
> >border-width, font-size, etc.
>
> I assume you are referring to shorthands?
Not only shorthands. There are a lot of core and extended properties
which have simple keyword values. Look at "border-top-width" (7.6.21)
for example. It's a Length type of property, but it can also be
specified as "thin", "medium" and "thick". As the XSL draft says, these
values depend on the user agent. I was thinking of mapping these to
actual Length values in properties.xml. The layout code which is looking
at properties only deals with the raw Length value and not these
enumerated values. I can make a list of all these, if someone else
hasn't already.
> >But I was getting kind of bogged down in the details, and tables weren't
> >progressing, so I shelved it for now. I'd be more than happy to work on
> >details of that with you.
>
> Absolutely. I'm delighted that we have a base to start with.
>
> >> I know you were working on expressions. How is that coming along?
> >>
> >KL: Are you referring to the stuff I mentioned a few months ago?
> >Actually, what I had done was modify XT's basic expression handling so
> >that it knew how to handle quantities with units, mixed with other
> >expressions. I strongly think this code belongs in the basic XSL(T/FO)
> >engine and not in the FOP part. So this works in my private XT. I
> >haven't looked at what it would take to do that kind of modification in
> >Xalan.
>
> If we consider the stages to be (1) FO tree production with properties
> refinement/resolution, (2) area-tree production, and (3) rendering, then I
> agree that big chunks of (1), particularly arithmetic expressions and many
> of the core functions, look like stuff that XSLT is doing.
>
> I'm thinking that the similarities may be somewhat superficial. The context
> within which XSLFO expressions are evaluated is quite different than that
> which obtains for XSLT. We may wish to explore access to an XPath processor
> but I don't know if trying to integrate tightly with an existing XSLT
> processor will be worth it.
>
> My viewpoint is based on the fact that XSLT could care less about what XML
> it is churning out, whether it be FO's or ArvedML. There is a clean
> separation between XSLT and XSLFO. There may be a language thing here, too -
> it depends on what you consider to be the basic "engine". If you mean the
> stuff that produces the FO tree, then yes; but this is not XSLT either.
>
> I don't doubt but that there will be heated discussion about this one.
Yes, and I don't want to start a war tonight :-).
My main motivation is laziness. We would have to duplicate a lot of
expression handling inside FOP attribute parsing. I have always thought
of XSL being the main specification and the XSLT part being just a means
to the end. Maybe I see it this way because I was familiar with DSSSL
before XSL, and in particular with J. Clark's jade implementation. The
front end interpreter did all the expression handling and the back end
formatters only had to deal with the resulting value for each property.
However, I will think more about your point of view.
> >> All of the above would tie into other stuff that I'm working on now,
> where I
> >> am ensuring that areas have all traits in place that make sense to them,
> and
> >> that we have all the areas to support any FO in the spec.
> >>
> >> Once that is done we can start looking at FO's, and ensure that they are
> >> properly refining and resolving every property that applies. Only then
> >> should we proceed to handling actual layout.
> >>
> >> I'm sort of thinking of the above horizontal approach, as opposed to a
> >> vertical one where we implement a single FO and just the properties and
> >> layout to support it, because I think we'll move faster that way, and
> >> maintain better coordination. As I say, I'll have a more detailed proposed
> >> plan in a few days.
> >
> >This sounds like a good approach to me. Looking forward to hearing more.
> >-Karen
>
> I am putting wings on it. :-)
>
> Arved
>
> Senior Developer
> e-plicity.com (www.e-plicity.com)
> Halifax, Nova Scotia
> "B2B Wireless in Canada's Ocean Playground"
Karen
Re: Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 12:30 AM 8/21/00 +0200, Karen Lease wrote:
>Arved Sandstrom wrote:
>
>> On a related note, I was thinking through our plan of attack for FOP. I'll
>> be putting out a planning document shortly that talks about that. In the
>> interim, it occurs to me that we can start putting _every_ property in
>> place, starting with properties.xml, and ensuring that the datatypes are
>> there to support those properties (I wrote an Orientation class, for
>> example, to support 90 deg multiple angles).
>
>KL: I have started to write some new datatypes too: LengthRange, Space,
>Keep, Precedence. Also, I have done quite a lot of thinking about
>several other aspects of properties.xml:
OK, this sounds real good. I sort of see full properties support as being
the first phase, although aspects of other FOP development can proceed
independently. I'll accelerate the production of a properties implementation
plan, specifically.
>1. handling "corresponding" properties (Western-writing mode centric
>ones like "top", "left" and the their neutral equivalents like "before",
>"start". We need to be able to compute one from the other. I have done a
>few tests with some XSL expressions to generate code for this.
"top", "left" etc aren't Western-centric per se, just "absolute" - the
others are "relative". What _is_ Western-centric is our assumption that
"top" == "before".
>2. handling properties with components (space-before.minimum, etc) in a
>general way
>
>3. handling all keyword values for non-enumerated properties, like
>border-width, font-size, etc.
I assume you are referring to shorthands?
>But I was getting kind of bogged down in the details, and tables weren't
>progressing, so I shelved it for now. I'd be more than happy to work on
>details of that with you.
Absolutely. I'm delighted that we have a base to start with.
>> I know you were working on expressions. How is that coming along?
>>
>KL: Are you referring to the stuff I mentioned a few months ago?
>Actually, what I had done was modify XT's basic expression handling so
>that it knew how to handle quantities with units, mixed with other
>expressions. I strongly think this code belongs in the basic XSL(T/FO)
>engine and not in the FOP part. So this works in my private XT. I
>haven't looked at what it would take to do that kind of modification in
>Xalan.
If we consider the stages to be (1) FO tree production with properties
refinement/resolution, (2) area-tree production, and (3) rendering, then I
agree that big chunks of (1), particularly arithmetic expressions and many
of the core functions, look like stuff that XSLT is doing.
I'm thinking that the similarities may be somewhat superficial. The context
within which XSLFO expressions are evaluated is quite different than that
which obtains for XSLT. We may wish to explore access to an XPath processor
but I don't know if trying to integrate tightly with an existing XSLT
processor will be worth it.
My viewpoint is based on the fact that XSLT could care less about what XML
it is churning out, whether it be FO's or ArvedML. There is a clean
separation between XSLT and XSLFO. There may be a language thing here, too -
it depends on what you consider to be the basic "engine". If you mean the
stuff that produces the FO tree, then yes; but this is not XSLT either.
I don't doubt but that there will be heated discussion about this one.
>> All of the above would tie into other stuff that I'm working on now,
where I
>> am ensuring that areas have all traits in place that make sense to them,
and
>> that we have all the areas to support any FO in the spec.
>>
>> Once that is done we can start looking at FO's, and ensure that they are
>> properly refining and resolving every property that applies. Only then
>> should we proceed to handling actual layout.
>>
>> I'm sort of thinking of the above horizontal approach, as opposed to a
>> vertical one where we implement a single FO and just the properties and
>> layout to support it, because I think we'll move faster that way, and
>> maintain better coordination. As I say, I'll have a more detailed proposed
>> plan in a few days.
>
>This sounds like a good approach to me. Looking forward to hearing more.
>-Karen
I am putting wings on it. :-)
Arved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Plan of Attack (was Re: Problem with SAX2 in FOP 0.14.0)
Posted by Karen Lease <kl...@club-internet.fr>.
Arved Sandstrom wrote:
>
> On a related note, I was thinking through our plan of attack for FOP. I'll
> be putting out a planning document shortly that talks about that. In the
> interim, it occurs to me that we can start putting _every_ property in
> place, starting with properties.xml, and ensuring that the datatypes are
> there to support those properties (I wrote an Orientation class, for
> example, to support 90 deg multiple angles).
KL: I have started to write some new datatypes too: LengthRange, Space,
Keep, Precedence. Also, I have done quite a lot of thinking about
several other aspects of properties.xml:
1. handling "corresponding" properties (Western-writing mode centric
ones like "top", "left" and the their neutral equivalents like "before",
"start". We need to be able to compute one from the other. I have done a
few tests with some XSL expressions to generate code for this.
2. handling properties with components (space-before.minimum, etc) in a
general way
3. handling all keyword values for non-enumerated properties, like
border-width, font-size, etc.
But I was getting kind of bogged down in the details, and tables weren't
progressing, so I shelved it for now. I'd be more than happy to work on
details of that with you.
> I know you were working on expressions. How is that coming along?
>
KL: Are you referring to the stuff I mentioned a few months ago?
Actually, what I had done was modify XT's basic expression handling so
that it knew how to handle quantities with units, mixed with other
expressions. I strongly think this code belongs in the basic XSL(T/FO)
engine and not in the FOP part. So this works in my private XT. I
haven't looked at what it would take to do that kind of modification in
Xalan.
> All of the above would tie into other stuff that I'm working on now, where I
> am ensuring that areas have all traits in place that make sense to them, and
> that we have all the areas to support any FO in the spec.
>
> Once that is done we can start looking at FO's, and ensure that they are
> properly refining and resolving every property that applies. Only then
> should we proceed to handling actual layout.
>
> I'm sort of thinking of the above horizontal approach, as opposed to a
> vertical one where we implement a single FO and just the properties and
> layout to support it, because I think we'll move faster that way, and
> maintain better coordination. As I say, I'll have a more detailed proposed
> plan in a few days.
This sounds like a good approach to me. Looking forward to hearing more.
-Karen
> rved
>
> Senior Developer
> e-plicity.com (www.e-plicity.com)
> Halifax, Nova Scotia
> "B2B Wireless in Canada's Ocean Playground"
Re: FIX for FOTreeBuilder (and XTFOTreeBuilder, XTDriver)
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 12:13 AM 8/21/00 +0200, Karen Lease wrote:
>
>3 Patch files attached. Please let me know if this is the correct way to
>submit changes.
Yes, it is. The big FIX in the subject line helps considerably.
Arved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: FIX for FOTreeBuilder (and XTFOTreeBuilder, XTDriver)
Posted by Stefano Mazzocchi <st...@apache.org>.
Karen Lease wrote:
>
> I have modified FOTreeBuilder.java to use the URI and localName, rather
> than the Qname (with the prefix). All of the SAX1-type namespace
> handling stuff is just commented out for now. Whoever gets to commit
> this can zap it if that is more conform to usual practice. I ran the
> basic .fo tests against it and it passed.
Don't you simply love when you submit a bug report and the solution came
"before" the bug report arrived? :)
Thanks Karen, you made my day.
> While I was changing this, I also modified the XT-specific versions so
> that they work again. I modified XTFOTreeBuilder by making it subclass
> FOTreeBuilder and implement the other SAX1 DocumentHandler methods.
> Basically, it uses the old namespace handling code to interpret the
> prefixes and then passes it to the SAX2 equivalent in its superclass
> FOTreeBuilder. This way, XTDriver doesn't need to use a specific
> XTElementMapping interface, so I modified that too.
>
> 3 Patch files attached. Please let me know if this is the correct way to
> submit changes.
I clearly think Karen deserves commit access, what about you?
Count my vote +1 :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
FIX for FOTreeBuilder (and XTFOTreeBuilder, XTDriver)
Posted by Karen Lease <kl...@club-internet.fr>.
I have modified FOTreeBuilder.java to use the URI and localName, rather
than the Qname (with the prefix). All of the SAX1-type namespace
handling stuff is just commented out for now. Whoever gets to commit
this can zap it if that is more conform to usual practice. I ran the
basic .fo tests against it and it passed.
While I was changing this, I also modified the XT-specific versions so
that they work again. I modified XTFOTreeBuilder by making it subclass
FOTreeBuilder and implement the other SAX1 DocumentHandler methods.
Basically, it uses the old namespace handling code to interpret the
prefixes and then passes it to the SAX2 equivalent in its superclass
FOTreeBuilder. This way, XTDriver doesn't need to use a specific
XTElementMapping interface, so I modified that too.
3 Patch files attached. Please let me know if this is the correct way to
submit changes.
THanks,
Karen
On Sun, 20 Aug 2000 10:28:11 -0300, Arved Sandstrom wrote:
>
> At 11:03 PM 8/18/00 +0200, Karen Lease wrote:
> >Arved,
> >
> >By fix, are you thinking of handling both of the SAX2 namespace cases?
> >
> >I think by default, a SAX2 parser sends the URI and the local name and
> >isn't obliged to send the prefixed form, nor the xmlns attributes. When
> >namespace-prefixes is set to true, it must send the prefixed form and
> >isn't obliged to send the full namespace. The current code uses both the
> >prefixed form (Qname or rawName) and the namespace URI, which works with
> >Xalan when namespace-prefixes=true.
> >
> >I think the best solution is to say that the "namespaces" features must
> >be set to true (required default for SAX2 XMLReader), and to use the URI
> >and local name and make no assumptions about Qname and xmlns attributes
> >being present. If this is OK, I will do this.
>
> This sounds good to me. Please go ahead.
Re: Problem with SAX2 in FOP 0.14.0
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 11:03 PM 8/18/00 +0200, Karen Lease wrote:
>Arved,
>
>By fix, are you thinking of handling both of the SAX2 namespace cases?
>
>I think by default, a SAX2 parser sends the URI and the local name and
>isn't obliged to send the prefixed form, nor the xmlns attributes. When
>namespace-prefixes is set to true, it must send the prefixed form and
>isn't obliged to send the full namespace. The current code uses both the
>prefixed form (Qname or rawName) and the namespace URI, which works with
>Xalan when namespace-prefixes=true.
>
>I think the best solution is to say that the "namespaces" features must
>be set to true (required default for SAX2 XMLReader), and to use the URI
>and local name and make no assumptions about Qname and xmlns attributes
>being present. If this is OK, I will do this.
This sounds good to me. Please go ahead.
>On a related subject, is it known that the XT support is not only
>deprecated, but broken in the latest FOP? I see that there are new XT
>specific classes for Driver, FOTreeBuilder and ElementMapping, but I get
>errors when I try to run XTCommandLine. Just to explain why I'm so
>attached to XT: on my Mac 7500 (running PPCLinux) XT is A LOT FASTER
>than Xalan, something like 3 to 5 times faster depending on what I do. I
>have actually looked at upgrading XT's XSLProcessor to provide SAX2
>events, but it means modifying a fair amount of XT's output handler
>logic.
I'll run that myself and see what we can do.
On a related note, I was thinking through our plan of attack for FOP. I'll
be putting out a planning document shortly that talks about that. In the
interim, it occurs to me that we can start putting _every_ property in
place, starting with properties.xml, and ensuring that the datatypes are
there to support those properties (I wrote an Orientation class, for
example, to support 90 deg multiple angles).
I know you were working on expressions. How is that coming along?
All of the above would tie into other stuff that I'm working on now, where I
am ensuring that areas have all traits in place that make sense to them, and
that we have all the areas to support any FO in the spec.
Once that is done we can start looking at FO's, and ensure that they are
properly refining and resolving every property that applies. Only then
should we proceed to handling actual layout.
I'm sort of thinking of the above horizontal approach, as opposed to a
vertical one where we implement a single FO and just the properties and
layout to support it, because I think we'll move faster that way, and
maintain better coordination. As I say, I'll have a more detailed proposed
plan in a few days.
rved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: Problem with SAX2 in FOP 0.14.0
Posted by Karen Lease <kl...@club-internet.fr>.
Arved,
By fix, are you thinking of handling both of the SAX2 namespace cases?
I think by default, a SAX2 parser sends the URI and the local name and
isn't obliged to send the prefixed form, nor the xmlns attributes. When
namespace-prefixes is set to true, it must send the prefixed form and
isn't obliged to send the full namespace. The current code uses both the
prefixed form (Qname or rawName) and the namespace URI, which works with
Xalan when namespace-prefixes=true.
I think the best solution is to say that the "namespaces" features must
be set to true (required default for SAX2 XMLReader), and to use the URI
and local name and make no assumptions about Qname and xmlns attributes
being present. If this is OK, I will do this.
On a related subject, is it known that the XT support is not only
deprecated, but broken in the latest FOP? I see that there are new XT
specific classes for Driver, FOTreeBuilder and ElementMapping, but I get
errors when I try to run XTCommandLine. Just to explain why I'm so
attached to XT: on my Mac 7500 (running PPCLinux) XT is A LOT FASTER
than Xalan, something like 3 to 5 times faster depending on what I do. I
have actually looked at upgrading XT's XSLProcessor to provide SAX2
events, but it means modifying a fair amount of XT's output handler
logic.
Regards,
Karen
Arved Sandstrom wrote:
>
> At 11:49 PM 8/17/00 +0200, Karen Lease wrote:
> >Mikael,
> >
> >Your analysis is correct. But you can workaround this by doing the same
> >thing that CommandLine and XalanCommandLine do, namely, tell the parser
> >to generate namespace-prefixes:
> >
> >parser.setFeature("http://xml.org/sax/features/namespace-prefixes",
> >true);
> >
> >But it's true that the FOTreeBuilder class could save some work by using
> >the default setting, which is to pass the URI and local name separately
> >and not the prefixed name. It's still doing the work it had to do when
> >using SAX1.
> >
> >-Karen
>
> OK, I guess we want to fix this forthwith. :-) Karen, since you recently
> looked at it, d'you want to?
>
> Arved
Re: Problem with SAX2 in FOP 0.14.0
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 11:49 PM 8/17/00 +0200, Karen Lease wrote:
>Mikael,
>
>Your analysis is correct. But you can workaround this by doing the same
>thing that CommandLine and XalanCommandLine do, namely, tell the parser
>to generate namespace-prefixes:
>
>parser.setFeature("http://xml.org/sax/features/namespace-prefixes",
>true);
>
>But it's true that the FOTreeBuilder class could save some work by using
>the default setting, which is to pass the URI and local name separately
>and not the prefixed name. It's still doing the work it had to do when
>using SAX1.
>
>-Karen
OK, I guess we want to fix this forthwith. :-) Karen, since you recently
looked at it, d'you want to?
Arved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"
Re: Problem with SAX2 in FOP 0.14.0
Posted by Karen Lease <kl...@club-internet.fr>.
Mikael,
Your analysis is correct. But you can workaround this by doing the same
thing that CommandLine and XalanCommandLine do, namely, tell the parser
to generate namespace-prefixes:
parser.setFeature("http://xml.org/sax/features/namespace-prefixes",
true);
But it's true that the FOTreeBuilder class could save some work by using
the default setting, which is to pass the URI and local name separately
and not the prefixed name. It's still doing the work it had to do when
using SAX1.
-Karen
"Mikael Ståldal" wrote:
>
> FOP 0.14.0 doesn't seems to handle SAX2 and namespaces correctly, the
> following program (using Xerces 1.1.2):
>
> import java.io.*;
>
> import org.xml.sax.*;
> import org.apache.fop.apps.*;
> import org.apache.xerces.parsers.*;
>
> public class FOPandSAX2
> {
> public static void main(String[] args) throws Exception
> {
> Driver driver = new Driver();
> driver.setRenderer("org.apache.fop.render.pdf.PDFRenderer",
> Version.getVersion());
> driver.addElementMapping("org.apache.fop.fo.StandardElementMapping");
> driver.addElementMapping("org.apache.fop.svg.SVGElementMapping");
> driver.setWriter(new PrintWriter(new FileWriter(args[1])));
>
> XMLReader parser = new SAXParser();
> parser.setContentHandler(driver.getContentHandler());
> parser.parse(new InputSource(args[0]));
>
> driver.format();
> driver.render();
> }
>
> }
>
> gives:
>
> org.apache.fop.apps.FOPException: Unknown namespace prefix fo
> at java.lang.Throwable.<init>(Throwable.java:63)
> at java.lang.Exception.<init>(Exception.java:28)
> at org.xml.sax.SAXException.<init>(SAXException.java:61)
> at org.apache.fop.fo.FOTreeBuilder.mapName(FOTreeBuilder.java:148)
> at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:251)
> at
> org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1361)
>
> with a FO file which is correctly processed by using
> org.apache.fop.apps.CommandLine.
>
> I had a quick look at the code, and it seems like that the
> FOTreeBuilder expect that the rawName attribute in the SAX2
> ContentHandler.startElement event to be present. It can be the empty
> string according to the SAX2 docs. FOP should make use of the uri and
> localName attributes instead.
>
> --
> /****************************************************************\
> * You have just read a message from Mikael Ståldal. *
> * *
> * Remove "-ingen-reklam" from the address before mail replying. *
> \****************************************************************/
Re: Problem with SAX2 in FOP 0.14.0
Posted by Mikael St�ldal <d9...@d.kth.se>.
In article <39...@elabed.net>,
Hani Elabed <ha...@mail.elabed.net> wrote:
>I have seen this before, You might not have the latest
>source code,
As I said, I have version 0.14.0, which is the latest version I found
in the distribution directory. I have not checked out anything from the
CVS repository.
>if you add the following lines below it might fix your problem.
It made no difference.
--
/****************************************************************\
* You have just read a message from Mikael Ståldal. *
* *
* Remove "-ingen-reklam" from the address before mail replying. *
\****************************************************************/
Re: Problem with SAX2 in FOP 0.14.0
Posted by Hani Elabed <ha...@elabed.net>.
Mikael,
I have seen this before, You might not have the latest
source code, if you add the following lines below
it might fix your problem.
driver.addPropertyList(
"org.apache.fop.fo.StandardPropertyListMapping"
);
driver.addPropertyList(
"org.apache.fop.svg.SVGPropertyListMapping"
);
I am running FOP
with no problems (see where I added them below)...
Good luck
Hani
"Mikael Ståldal" wrote:
> FOP 0.14.0 doesn't seems to handle SAX2 and namespaces correctly, the
> following program (using Xerces 1.1.2):
>
> import java.io.*;
>
> import org.xml.sax.*;
> import org.apache.fop.apps.*;
> import org.apache.xerces.parsers.*;
>
> public class FOPandSAX2
> {
> public static void main(String[] args) throws Exception
> {
> Driver driver = new Driver();
> driver.setRenderer("org.apache.fop.render.pdf.PDFRenderer",
> Version.getVersion());
> driver.addElementMapping("org.apache.fop.fo.StandardElementMapping");
> driver.addElementMapping("org.apache.fop.svg.SVGElementMapping");
>
driver.addPropertyList(
"org.apache.fop.fo.StandardPropertyListMapping"
);
driver.addPropertyList(
"org.apache.fop.svg.SVGPropertyListMapping"
);
> driver.setWriter(new PrintWriter(new FileWriter(args[1])));
>
> XMLReader parser = new SAXParser();
> parser.setContentHandler(driver.getContentHandler());
> parser.parse(new InputSource(args[0]));
>
> driver.format();
> driver.render();
> }
>
> }
>
> gives:
>
> org.apache.fop.apps.FOPException: Unknown namespace prefix fo
> at java.lang.Throwable.<init>(Throwable.java:63)
> at java.lang.Exception.<init>(Exception.java:28)
> at org.xml.sax.SAXException.<init>(SAXException.java:61)
> at org.apache.fop.fo.FOTreeBuilder.mapName(FOTreeBuilder.java:148)
> at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:251)
> at
> org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1361)
>
> with a FO file which is correctly processed by using
> org.apache.fop.apps.CommandLine.
>
> I had a quick look at the code, and it seems like that the
> FOTreeBuilder expect that the rawName attribute in the SAX2
> ContentHandler.startElement event to be present. It can be the empty
> string according to the SAX2 docs. FOP should make use of the uri and
> localName attributes instead.
>
> --
> /****************************************************************\
> * You have just read a message from Mikael Ståldal. *
> * *
> * Remove "-ingen-reklam" from the address before mail replying. *
> \****************************************************************/