Re: [GUMP] Build Failure - xml-fop
On 02.06.2003 14:12:43 Thomas E Deweese wrote: JM == Jeremias Maerki [EMAIL PROTECTED] writes: JM However, I'm worrying about binary compatibility. At the moment we JM have to tell our users that they have to use the Batik-version JM delivered with FOP. I'd like to see Batik's API stabilize some JM more so people can just download the latest version of Batik and JM replace it in their installation. I realize that FOP is a somehat JM special Batik customer from an API-POV. But let's take Cocoon: It JM contains blocks for Batik and FOP (where FOP uses Batik for SVG JM support). If a Cocoon user needs to use Batik (for generating SVG) JM and FOP (for generating PDF containing SVG graphics) this user is JM constrained to use the Batik version that FOP was compiled JM with. He cannot simply upgrade his Batik version to avoid a bug, JM for example. The very least he has to do is recompile FOP with JM that specific version of Batik he wants to use. Hopefully it JM compiles. To illustrate: Clearly having no interfaces change is a good thing, but we also need to support SVG properly - the equivalent of this change was _required_ to properly support SVG. It could have been done other ways that (I think) would have preserved binary compatibility but they would have had significant drawbacks on performance, maintainability and robustness. I understand. We have similar problems with the transition from maintenance branch to redeign. FOP is a special customer and I am actually quite surprised that you are creating subclasses of GraphicsNode (I understand what is being done there but I could have suggested a couple of 'better' ways to do it I think). Well, it's the way it is done now. It would be great if you could outline better ways to do what we need to do. JM As I said before, the FOP teams produced similar problems in the JM past. After a recent problem between Cocoon and FOP I'm committed JM to watching over FOP's APIs. I'm hoping that the Batik team will JM similarly watch over what happens in their APIs. So you are now committed to not introducing any binary or source incompatibilities? I want to avoid them where possible. I want to help making sure that everyone thinks twice before changing an API. I'm not going to stand in the way of change. But we always have to be aware of our customers' needs. I don't think Batik is in a position to do this yet. I would say that when 1.5 goes final we might be willing to offer that assurance for releases in the '1.5' branch. But we still need at some point to support SMIL Animation I can guarantee you that this will involve incompatible API changes/extensions/etc. Sounds to me like some problems could be avoided by separating non-interactive and interactive APIs. Like subclassing AbstractGraphicsNode to AbstractInteractiveGraphicsNode (which contains the getSensitiveBound() method). Just a thought, I'm not familiar enough with Batik. BTW perhaps I'm missing the point of the 'maintence' build but shouldn't that be done off one of the release versions of Batik? JM I'm under the impression that Gump is intended to check JM code-compatibility between projects in CVS, not against released JM versions. This is to have an early warning about incompatible JM changes (before a release), so they can be resolved (hopefully JM with a compatibility layer) before the release. I guess as long as you can still make changes in the 'maintence' branch it isn't an issue - but I would have thought that a particular version of Batik would have already been targeted for the release of FOP - rather than tracking 'HEAD'. It just seems odd to me that a 'stable' version of FOP would track 'HEAD' on Batik. Not really stable. :-) The branch is more than 20 months old and has seen very active development. It's really two development tracks like Xalan 1 and 2. The older gets discarded eventually. JM With my findings above I think it would even make sense to have an JM additional mechanism to check binary compatibility (just some JM runtime tests using JUnit, for example) between projects (CVS of JM project 1 against release xy of project 2). Binary compatibility is really, really hard to ensure and I think it only makes sense on 'point' releases, so 1.5 and 1.5.1 _should_ be binary compatible, 1.5 and 1.6 may not be (and similarly 1.5b4 and 1.5b5 do not need to be) - all of course IMHO - other Batik developers may (and probably will :) disagree. Batik's in beta mode, FOP's in release candidate modefor a very long time. :-) That basically makes each beta/rc releases quite important. But you're right, except that I would expect compatibility over a full version (1.x). I think you're missing my point about that idea: Testing a project CVS against dependent releases may be a good way to make a developer think twice (TM). That's basically the only thing I ask. Anyway, it was just an idea. Jeremias
Re: [GUMP] Build Failure - xml-fop
JM == Jeremias Maerki [EMAIL PROTECTED] writes: FOP is a special customer and I am actually quite surprised that you are creating subclasses of GraphicsNode (I understand what is being done there but I could have suggested a couple of 'better' ways to do it I think). JM Well, it's the way it is done now. It would be great if you could JM outline better ways to do what we need to do. I would have simply attached the JpegImage as a rendering hint on the standard Batik RasterImageNode. Then the PDF Graphics can check if the hint is present when drawImage is called, if so use that hint. Alternately, I would have derived off the existing RasterImageNode (a known concrete class) rather than creating a new subclass of an abstract class. Both of these preserve the normal workings of the rendering engine yet enables you to annotate the GraphicsNode tree with your additional information. We also should have made the construction of the RasterImageGraphcisNode a method you could easily override. I don't think Batik is in a position to do this yet. I would say that when 1.5 goes final we might be willing to offer that assurance for releases in the '1.5' branch. But we still need at some point to support SMIL Animation I can guarantee you that this will involve incompatible API changes/extensions/etc. JM Sounds to me like some problems could be avoided by separating JM non-interactive and interactive APIs. Like subclassing JM AbstractGraphicsNode to AbstractInteractiveGraphicsNode (which JM contains the getSensitiveBound() method). Just a thought, I'm not JM familiar enough with Batik. If we had done this from the start this might have helped FOP in this particular case but the addition still would have hurt anyone extending the existing dynamic portion of Batik. So it might have limited the impact but it would not have eliminated it, and I had already considered the fact that the impact was limited to people who were extending GraphicsNode which is already a _very_small_ population AFAIK (as I said I was a bit surprised that even FOP, who I knew was pretty deeply involved with Batik, was extending Graphics Nodes). JM With my findings above I think it would even make sense to have an JM additional mechanism to check binary compatibility (just some JM runtime tests using JUnit, for example) between projects (CVS of JM project 1 against release xy of project 2). Binary compatibility is really, really hard to ensure and I think it only makes sense on 'point' releases, so 1.5 and 1.5.1 _should_ be binary compatible, 1.5 and 1.6 may not be (and similarly 1.5b4 and 1.5b5 do not need to be) - all of course IMHO - other Batik developers may (and probably will :) disagree. JM Batik's in beta mode, FOP's in release candidate modefor a JM very long time. :-) That basically makes each beta/rc releases JM quite important. But you're right, except that I would expect JM compatibility over a full version (1.x). This then just becomes a 'naming issue'. JM I think you're missing my point about that idea: Testing a project JM CVS against dependent releases may be a good way to make a JM developer think twice (TM). That's basically the only thing I JM ask. Anyway, it was just an idea. I think it's better of developers just think twice (TM). BTW I did think twice about about this change but it really is needed. I am sorry about the trouble. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
Looks like your message simply got stuck in the moderator's queue. On 30.05.2003 18:17:31 Thomas DeWeeese wrote: Jeremias Maerki wrote: Hi Batik-Devs, the latest changes in Batik broke both the maintenance branch and HEAD of FOP: http://cvs.apache.org/builds/gump/2003-05-30/xml-fop.html http://cvs.apache.org/builds/gump/2003-05-30/xml-fop-maintenance.html Is there any possibility to adjust the changes so they don't break third-party dependencies? It would be possible to define AbstractGraphicsNode.getSensitiveBounds to return what ever AbstractGraphicsNode.getPrimitiveBounds would return, but I would rather leave it as an abstract method because just like the other bounds methods people who derive should give careful consideration to the proper value to return for the specific type of graphics node involved. The additional method is required for proper support of pointer-events in SVG. I see your point. In this case it is very simple to define the method (it should I think just return getPrimitiveBounds). That's true and I'm going to do that. However, I'm worrying about binary compatibility. At the moment we have to tell our users that they have to use the Batik-version delivered with FOP. I'd like to see Batik's API stabilize some more so people can just download the latest version of Batik and replace it in their installation. I realize that FOP is a somehat special Batik customer from an API-POV. But let's take Cocoon: It contains blocks for Batik and FOP (where FOP uses Batik for SVG support). If a Cocoon user needs to use Batik (for generating SVG) and FOP (for generating PDF containing SVG graphics) this user is constrained to use the Batik version that FOP was compiled with. He cannot simply upgrade his Batik version to avoid a bug, for example. The very least he has to do is recompile FOP with that specific version of Batik he wants to use. Hopefully it compiles. To illustrate: A few minutes ago a took FOP 0.20.5rc3a and put in batik-all.jar (built from CVS today). It turns out that binary compatibility got broken in March already: http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/bridge/UnitProcessor.java.diff?r1=1.10r2=1.11diff_format=h I got the following when running FOP (without recompile because this would have solved the problem): Exception in thread main java.lang.NoSuchMethodError: org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/util/UnitProcessor$Context; at org.apache.fop.svg.SVGElement.layout(SVGElement.java:218) As I said before, the FOP teams produced similar problems in the past. After a recent problem between Cocoon and FOP I'm committed to watching over FOP's APIs. I'm hoping that the Batik team will similarly watch over what happens in their APIs. BTW perhaps I'm missing the point of the 'maintence' build but shouldn't that be done off one of the release versions of Batik? I'm under the impression that Gump is intended to check code-compatibility between projects in CVS, not against released versions. This is to have an early warning about incompatible changes (before a release), so they can be resolved (hopefully with a compatibility layer) before the release. With my findings above I think it would even make sense to have an additional mechanism to check binary compatibility (just some runtime tests using JUnit, for example) between projects (CVS of project 1 against release xy of project 2). FOP's maintenance branch is where our latest release candidate originated. FOP 0.20.5 will also be based on the maintenance branch. The trunk of the xml-fop CVS module is home of our redesign effort. This is also the place where you get the PDF transcoder from because that's where Keiron Liddle has done a lot of refactoring work for the SVG support. So, we have two lines of development. After the 0.20.5 release the maintenance branch will be frozen. More details here: http://xml.apache.org/fop/dev/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
JM == Jeremias Maerki [EMAIL PROTECTED] writes: JM However, I'm worrying about binary compatibility. At the moment we JM have to tell our users that they have to use the Batik-version JM delivered with FOP. I'd like to see Batik's API stabilize some JM more so people can just download the latest version of Batik and JM replace it in their installation. I realize that FOP is a somehat JM special Batik customer from an API-POV. But let's take Cocoon: It JM contains blocks for Batik and FOP (where FOP uses Batik for SVG JM support). If a Cocoon user needs to use Batik (for generating SVG) JM and FOP (for generating PDF containing SVG graphics) this user is JM constrained to use the Batik version that FOP was compiled JM with. He cannot simply upgrade his Batik version to avoid a bug, JM for example. The very least he has to do is recompile FOP with JM that specific version of Batik he wants to use. Hopefully it JM compiles. To illustrate: Clearly having no interfaces change is a good thing, but we also need to support SVG properly - the equivalent of this change was _required_ to properly support SVG. It could have been done other ways that (I think) would have preserved binary compatibility but they would have had significant drawbacks on performance, maintainability and robustness. FOP is a special customer and I am actually quite surprised that you are creating subclasses of GraphicsNode (I understand what is being done there but I could have suggested a couple of 'better' ways to do it I think). JM As I said before, the FOP teams produced similar problems in the JM past. After a recent problem between Cocoon and FOP I'm committed JM to watching over FOP's APIs. I'm hoping that the Batik team will JM similarly watch over what happens in their APIs. So you are now committed to not introducing any binary or source incompatibilities? I don't think Batik is in a position to do this yet. I would say that when 1.5 goes final we might be willing to offer that assurance for releases in the '1.5' branch. But we still need at some point to support SMIL Animation I can guarantee you that this will involve incompatible API changes/extensions/etc. BTW perhaps I'm missing the point of the 'maintence' build but shouldn't that be done off one of the release versions of Batik? JM I'm under the impression that Gump is intended to check JM code-compatibility between projects in CVS, not against released JM versions. This is to have an early warning about incompatible JM changes (before a release), so they can be resolved (hopefully JM with a compatibility layer) before the release. I guess as long as you can still make changes in the 'maintence' branch it isn't an issue - but I would have thought that a particular version of Batik would have already been targeted for the release of FOP - rather than tracking 'HEAD'. It just seems odd to me that a 'stable' version of FOP would track 'HEAD' on Batik. JM With my findings above I think it would even make sense to have an JM additional mechanism to check binary compatibility (just some JM runtime tests using JUnit, for example) between projects (CVS of JM project 1 against release xy of project 2). Binary compatibility is really, really hard to ensure and I think it only makes sense on 'point' releases, so 1.5 and 1.5.1 _should_ be binary compatible, 1.5 and 1.6 may not be (and similarly 1.5b4 and 1.5b5 do not need to be) - all of course IMHO - other Batik developers may (and probably will :) disagree. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
Of course, we could simply add the method and hope nothing breaks in the
process. The whole Gump thing is about getting the projects to talk to
each other. We got barked at in the past because we changed our API
without thinking about third-party dependencies. Now I'm informing the
Batik guys about the consequences of their latest changes.
You see, your code below could simply be added to Batik's
AbstractGraphicsNode, I think, and everything would be in order again
(without us having to change anything).
It may very well be that FOP 0.20.5rc3 will not work with the current
CVS version of Batik because it lacks the getSensitiveBounds() method.
If something in the Batik code calls that method, boom,
NoSuchMethodError. But I haven't tested it, yet, so I can't tell for
sure.
Both projects, Batik and FOP, have changed their APIs in their past.
That is allowed but the projects should care about their customers and
avoid generating unnecessary problems. So, before I change anything in
our code I want to see if there are other possibilities.
On 30.05.2003 17:38:50 Glen Mazza wrote:
This doesn't appear to be Batik's fault--they're just
recoding their classes, and their GraphicsNode
interface has two more functions in it, one of which
needs implementing in FOP's PDFJpegNode class.
If Gump links to Batik's latest and greatest when
building FOP, then FOP will need to update whenever
Batik changes. Could/should that be changed so Gump
will only link to the Batik library that we get on a
cvs checkout?
Thankfully, it appears that if this is added to FOP's
PDFJpegNode it will at least compile against both
versions--library Batik and latest-and-greatest Batik:
public Rectangle2D getSensitiveBounds() {
return getGeometryBounds();
}
(code from
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/gvt/TextNode.java?rev=1.27sortby=datecontent-type=text/vnd.viewcvs-markup
-- a Batik class that needed changing itself as a
result to the new functions in GraphicsNode)
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Hi Batik-Devs,
the latest changes in Batik broke both the
maintenance branch and HEAD
of FOP:
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
--- Jeremias Maerki [EMAIL PROTECTED] wrote: You see, your code below could simply be added to Batik's AbstractGraphicsNode, I think, and everything would be in order again (without us having to change anything). They did that for one of the two functions that were added to the GraphicsNode interface, but that other function is too subclass-dependent. I looked at the subclasses--one explicitly returns NULL, some do more advanced calculations, etc., for that function. (I'm not even sure if what I copied is best for the FOP subclass--but it is probably sufficient.) With what it knows about its subclasses, the best AGN could probably do is return NULL. That would have allowed FOP's code to quietly compile, but would probably have caused severe logical errors later while running. So they possibly did us a favor by not implementing it in AGN. Both projects, Batik and FOP, have changed their APIs in their past. That is allowed but the projects should care about their customers and avoid generating unnecessary problems. I agree--I'm angry about this irresponsible treatment from the Batik team too! Let's get revenge on them and remove FOP's TRAX/XSLTInputHandler!!! ;) Glen __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop-maintenance
Sam Ruby wrote: BUILD FAILED I've already sent a message to Batik because of this. Unfortunately, I'm on vacation next week. Anybody beside Keiron who is subscribed to batik-dev and who can watch how this unfolds? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop-maintenance
Ha, I was first! :-) Didn't you see my message? I'm subscribed and will watch over the issue. Enjoy your vacation! On 30.05.2003 21:10:33 J.Pietschmann wrote: Sam Ruby wrote: BUILD FAILED I've already sent a message to Batik because of this. Unfortunately, I'm on vacation next week. Anybody beside Keiron who is subscribed to batik-dev and who can watch how this unfolds? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop-maintenance
Jeremias Maerki wrote: Ha, I was first! :-) Didn't you see my message? No: the crossposted message was filed into the FOP folder. Any idea how Moz could file crossposted messages correctly, one into the A and the other into the B folder...they just end up both in the A folder if the filter for A has higher precedence than B...another example of a simple solution not quite living up to user expectations... :-/ I'm subscribed and will watch over the issue. Enjoy your vacation! Thanks! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop-maintenance
I don't use Moz (which is my personal short for Mozzarella BTW) but I use the list-post or List-Post header to separate crossposts. On 30.05.2003 21:52:41 J.Pietschmann wrote: Jeremias Maerki wrote: Ha, I was first! :-) Didn't you see my message? No: the crossposted message was filed into the FOP folder. Any idea how Moz could file crossposted messages correctly, one into the A and the other into the B folder...they just end up both in the A folder if the filter for A has higher precedence than B...another example of a simple solution not quite living up to user expectations... :-/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop-maintenance
Jeremias Maerki wrote: I don't use Moz (which is my personal short for Mozzarella BTW) but I use the list-post or List-Post header to separate crossposts. Clever, works perfectly! I always thought of a general tool chest wiki page, with how to set up eclipse for apache committers (including templates) and all kinds of other clues. If I ever get around to do this, the trick above will definitely be included in the mail clients section. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
FYI: Stefan Bodewig (Thank you!!!) contacted me on this one. He has already fixed the Gump descriptor so it should work next time. On 13.03.2003 11:51:39 Sam Ruby wrote: BUILD FAILED file:///home/rubys/jakarta/xml-fop/build.xml:430: taskdef class org.apache.fop.tools.anttasks.SerializeHyphPattern cannot be found Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
Sam Ruby wrote: [javac] /home/rubys/jakarta/xml-fop/src/org/apache/fop/layoutmgr/PageLayoutManager.java:421: BEFORE has protected access in org.apache.fop.fo.pagination.Region [javac] layoutStaticContent(spm.getRegion(Region.BEFORE), RegionReference.BEFORE); [javac] ^ [javac] /home/rubys/jakarta/xml-fop/src/org/apache/fop/layoutmgr/PageLayoutManager.java:422: AFTER has protected access in org.apache.fop.fo.pagination.Region [javac] layoutStaticContent(spm.getRegion(Region.AFTER), RegionReference.AFTER); [javac] ^ [javac] /home/rubys/jakarta/xml-fop/src/org/apache/fop/layoutmgr/PageLayoutManager.java:423: START has protected access in org.apache.fop.fo.pagination.Region [javac] layoutStaticContent(spm.getRegion(Region.START), RegionReference.START); [javac] ^ [javac] /home/rubys/jakarta/xml-fop/src/org/apache/fop/layoutmgr/PageLayoutManager.java:424: END has protected access in org.apache.fop.fo.pagination.Region [javac] layoutStaticContent(spm.getRegion(Region.END), RegionReference.END); [javac] ^ Oh boy, that's my fault, I made these fields protected and probably didn't clean before rebuilding FOP. I'm behind a firewall right now, so I'll fix it at the evening. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
Looks like the Batik guys have changed the TextPainter interface without
thinking about dependencies on other projects. Keiron, shall we make the
changes to conform to their new interface or should they reconsider this
change?
This is the link to TextPainter in Batik's CVS:
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/gvt/TextPainter.java
On 14.08.2002 12:36:22 Sam Ruby wrote:
[javac]
/home/rubys/jakarta/xml-fop/build/src/org/apache/fop/svg/PDFTextPainter.java:41:
class org.apache.fop.svg.PDFTextPainter must be declared abstract. It does not define
java.awt.geom.Rectangle2D getBounds2D(org.apache.batik.gvt.TextNode) from interface
org.apache.batik.gvt.TextPainter.
[javac] public class PDFTextPainter implements TextPainter {
[javac] ^
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
Hi,
On Mon, 2002-06-24 at 15:20, Sam Ruby wrote:
[style] Transforming into
/home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts
[style] Processing /home/rubys/jakarta/xml-fop/src/codegen/CourierBold.xml to
/home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/CourierBold.java
[style] Loading stylesheet
/home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl
[style] Processing /home/rubys/jakarta/xml-fop/src/codegen/Courier.xml to
/home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/Courier.java
[style] home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl:0:0: Fatal
Error! java.lang.RuntimeException: Programmer assertion is incorrect! - Namespace
context can not be null! Cause: java.lang.RuntimeException: Programmer assertion is
incorrect! - Namespace context can not be null!
[style] Failed to process /home/rubys/jakarta/xml-fop/src/codegen/Courier.xml
If you need some info to fix this.
I tried the latest releases of the xalan (and ant, xerces, xml-apis) and
the same problem occurs.
This is the statment in ant that is causing the problem:
style basedir=src/codegen includes=*.xml
style=${fontfile.xsl}
destdir=${build.src}/${replacestring}/render/pdf/fonts/
extension=.java/
The first transform is working correctly (so if I keep running it it
will eventually transform all of the files) but the second transform
gets the exception.
So it would appear to be a problem with some value not being reset.
Do you need any more info?
Keiron.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - xml-fop
Shane Curcuru wrote: So this is Sam resetting the nag for the xml-fop GUMP build to point to xalan-dev, since he thinks it's a several-days-old Xalan problem, correct? Correct - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
