Sorry for cross-posting, but I didn't know which bug was more appropriate. (they are virtually identical, after all!)
I seem to have encountered the same problem, only I was following the article at "http://www.xml.com/pub/a/2000/05/03/dsssl/index.html". I downloaded the two files "http://xml.com/2000/05/03/dsssl/catalog.xml" and "http://xml.com/2000/05/03/dsssl/catalog.dsl", and then ran the command "openjade -t html -wno-valid xml.dcl -d catalog.dsl catalog.xml". I also tried it with openjade1.3, with the same result. This gave me a virtually identical segfault, with no preceding diagnostic; this is most unhelpful. I don't even know whether the problem is that it cannot locate an entity with the PUBLIC identifier "-//Netfolder//DTD DSSSL library//EN", or that it can't find xml.dcl. I think the severity on this bug should be upgraded at least to "important", becuase whileopenjade might work okay when there aren't errors, it is almost completely unusable in situations where it might not be able to find all the files it wants. (Especially considering the lack of debugging symbols.) In fact, I just ran that command again in the wrong directory, and it still gave the exact same error message! Which is much less then helpful. Strangely, somehow this does *not* seem to affect onsgmls... Though it still can't find xml.dcl. Oh, and I also get this when running just "openjade catalog.xml", and never mention xml.dcl. And plain jade has no problem with *that*. (Though it can't find the stylesheet DTD and isn't supposed to support -t html.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]