Re: DOCBOOK-APPS: xsltproc segfaults with 1.51.1
Hi, The following is my version that segfaults: - Using libxml 20420, libxslt 10018 and libexslt 709 xsltproc was compiled against libxml 20421, libxslt 10018 and libexslt 709 libxslt 10018 was compiled against libxml 20421 libexslt 709 was compiled against libxml 20421 - Indeed using ftp://ftp.gnome.org/pub/GNOME/stable/redhat/i386/libxslt/libxslt-1.0.18-1.i386.rpm I don't get anymore segfault, just: - Error Undefined namespace prefix xmlXPathCompiledEval: evaluation failed - And this version looks slightly older than Mandrake (above) one: - Using libxml 20420, libxslt 10018 and libexslt 709 xsltproc was compiled against libxml 20419, libxslt 10018 and libexslt 709 libxslt 10018 was compiled against libxml 20419 libexslt 709 was compiled against libxml 20419 - So now, what's the problem(s): - a bug in libxslt ? - a bug in the 1.51.1 XSL? - a bug in the compilation/packaging step? Camille. Michael Smith wrote: Daniel Veillard [EMAIL PROTECTED] writes: On Wed, Jun 05, 2002 at 06:09:39AM -0500, Michael Smith wrote: Camille Bégnis [EMAIL PROTECTED] writes: Hmm, tracking down to the code causing the error was easier than I thought: the following sample works fine with 1.48 and makes xsltproc 1.0.18 segfault with 1.51.1 html (works with FO). Yep -- I just tried the same doc instance below on my environment with xsltproc and the current (cvs) version of the stylesheets (html/docbook.xsl) and reproduced the same segfault. Hum, I can't reproduce it here: paphio:~/XSLT/tests/docbook - /usr/bin/xsltproc ~/tmp/docbook-xsl-1.51.1/html/docbook.xsl tst.xml Error Undefined namespace prefix xmlXPathCompiledEval: evaluation failed htmlheadmeta content=text/html; charset=ISO-8859-1 http-equiv=Content-Typetitlexsltproc segfault test/titlemeta name=generator content=DocBook XSL Stylesheets V1.51.1/headbody bgcolor=white text=black link=#FF vlink=#840084 alink=#FFdiv class=articlediv class=titlepagedivh2 class=titlea name=id2760937/axsltproc segfault test/h2/divhr/div/div/body/html paphio:~/XSLT/tests/docbook - /usr/bin/xsltproc --version Using libxml 20422, libxslt 10018 and libexslt 709 xsltproc was compiled against libxml 20419, libxslt 10018 and libexslt 709 libxslt 10018 was compiled against libxml 20419 libexslt 709 was compiled against libxml 20419 paphio:~/XSLT/tests/docbook - Same for my development version from libxslt/libxml2 CVS, I will dig up about the Undefined namespace prefix error ... but can you check first with the RPMs from ftp://xmlsoft.org/ I compiled from latest release source (libxslt-1.0.18) I get no segfault running xsltproc built from that on the same test file (only error is the 'Undefined namespace prefix' thing). The xsltproc version I got the segfault from was: Using libxml 20417, libxslt 10013 and libexslt 705 xsltproc was compiled against libxml 20417, libxslt 10013 and libexslt 705 libxslt 10013 was compiled against libxml 20417 libexslt 705 was compiled against libxml 20417 But I get no segfault with newer-but-not-the-latest version on another machine: Using libxml 20419, libxslt 10016 and libexslt 707 xsltproc was compiled against libxml 20419, libxslt 10016 and libexslt 707 libxslt 10016 was compiled against libxml 20419 libexslt 707 was compiled against libxml 20419 That's the latest version packaged for Debian. Don't know what the latest are for other distros are, but it looks like if they're = 1.0.16 won't get the segfault at least. --Mike
Re: DOCBOOK-APPS: xsltproc segfaults with 1.51.1
On Thu, Jun 06, 2002 at 11:07:31AM +0200, Camille Bégnis wrote: So now, what's the problem(s): - a bug in libxslt ? possibly, one that got fixed in the latest release (it took me one month to make that release, so there is a number of bug fixes in it !). - a bug in the 1.51.1 XSL? should not make the library crash in any way - a bug in the compilation/packaging step? I didn't do any regression test with gcc-3.1, just the normal ones for the RPM build, if there is on-going problems that might be something to check. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: About DB2LaTeX
Ramon Casellas [EMAIL PROTECTED] writes: Many of the comments and bug reports I receive about DB2LaTeX concern the escaping of characters as well as internationalization. I'm thinking about how I could improve the package, and using external modules with java and/or C++ is an option. However, dropping the XSL only approach may mean compatibility problems, and that some XSL processors are supported and others aren't. So my questions are: - Should I add extension modules in order to make DB2LaTeX to make it perform better and faster? FWIW, I'd vote for keeping the XSL only approach. I think there's a big value in it -- in enabling people to get transformations done with just a minimal system (just the stylesheets and an XSLT engine) that will work on any platform and is free from other dependencies. (I realize DB2LaTeX has the big dependency of requiring users to have a working TeX setup if they want to be able to do anything with the generated LaTeX it produces, but that's a different sort of thing.) Just as an example: I don't think that because Steve Cheng's docbook2x utilities (for converting DocBook to roff man pages and Texinfo) have Perl/module dependencies, they're not as widely used as they ought to be. I guess a lot of users just can't/don't want to deal with getting the extra dependencies installed and working in order to use it. Martijn van Beers has been developing a pure XSLT-based DocBook-to-man solution that I expect will end up being used by a lot more people. [...] - Should I focus in providing support for the 1 or 2 most widely used XSLT processors in benefit of the number of features supported? [...] You might want to aim just for xsltproc and Saxon. If you can judge by postings to docbook-apps, xsltproc and Saxon are the engines most DocBook users are using; other than those and Xalan, XT, and 4XSLT, I can't think offhand of mention of any other engines showing up much on docbook-apps. As far as the other engines go, the current versions of the DocBook XSL stylesheets don't work reliably with Xalan (because of bugs in Xalan, I think, not bugs in the stylesheets), XT isn't supported because it can't handle keys, and 4XSLT works with the stylesheets (I think) but doesn't seem to be nearly as widely used by DocBook users (for now, at least) as xsltproc and Saxon. HTH, --Mike
DOCBOOK-APPS: Re: Treatment of links in print
/ Thomas Colby [EMAIL PROTECTED] was heard to say: | I'm currently using the docbook DSSSL stylesheets 1.72 | with openjade and tex to produce pdf and postscript documents. | | Any suggestions on rendering links on paper would be welcome, | Thanks in advance, It can be done, but you'll probably have to do a little customization. Basically, you need to change the xref generating text to output (element-page-number-sosofo target) where target is the element pointed to by the linkend. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | The hour which gives us life http://www.oasis-open.org/docbook/ | begins to take it away.--Seneca Chair, DocBook Technical Committee |
DOCBOOK-APPS: Re: HTML meta description tags
[ Follow-ups to docbook-apps, please ]
/ Aaron Isotton [EMAIL PROTECTED] was heard to say:
| Sorry, I don't understand. I just grepped through the docbook
| documentation for user. but didn't find anything like that. Could
| you give me a pointer please?
Use this template in your customization layer. This will be part of
the next release. :-)
xsl:param name=generate.meta.abstract select=1/
xsl:template name=head.content
xsl:param name=node select=./
title
xsl:apply-templates select=$node mode=object.title.markup.textonly/
/title
xsl:if test=$html.stylesheet
link rel=stylesheet
href={$html.stylesheet}
type={$html.stylesheet.type}/
/xsl:if
xsl:if test=$link.mailto.url != ''
link rev=made
href={$link.mailto.url}/
/xsl:if
xsl:if test=$html.base != ''
base href={$html.base}/
/xsl:if
meta name=generator content=DocBook XSL Stylesheets V{$VERSION}/
xsl:if test=$generate.meta.abstract != 0
xsl:variable name=info select=(articleinfo
|bookinfo
|prefaceinfo
|chapterinfo
|appendixinfo
|sectioninfo
|sect1info
|sect2info
|sect3info
|sect4info
|sect5info
|referenceinfo
|refentryinfo
|partinfo
|docinfo)[1]/
xsl:if test=$info and $info/abstract
meta name=description
xsl:attribute name=content
xsl:for-each select=$info/abstract[1]/*
xsl:value-of select=./
xsl:if test=position() lt; last()
xsl:text /xsl:text
/xsl:if
/xsl:for-each
/xsl:attribute
/meta
/xsl:if
/xsl:if
xsl:if test=ancestor-or-self::*[@status][1]/@status = 'draft'
and $draft.watermark.image != ''
style type=text/cssxsl:text
body { background-image: url(/xsl:text
xsl:value-of select=$draft.watermark.image/xsl:text);
background-repeat: no-repeat;
background-position: top left;
/* The following properties make the watermark fixed on the page. */
/* I think that's just a bit too distracting for the reader... */
/* background-attachment: fixed; */
/* background-position: center center; */
/xsl:text
/style
/xsl:if
xsl:apply-templates select=. mode=head.keywords.content/
/xsl:template
Be seeing you,
norm
--
Norman Walsh [EMAIL PROTECTED] | Our life gets as complicated as a
http://www.oasis-open.org/docbook/ | comedy as it goes on, but the
Chair, DocBook Technical Committee | complications get gradually
| resolved: see that the curtain
| comes down on a good
| denouement.--Graci\'an
Re: DOCBOOK-APPS: About DB2LaTeX
On Thu, 6 Jun 2002, Michael Smith wrote: Ramon Casellas [EMAIL PROTECTED] writes: [snip] - Should I add extension modules in order to make DB2LaTeX to make it perform better and faster? FWIW, I'd vote for keeping the XSL only approach. I think there's a big value in it -- in enabling people to get transformations done with just a minimal system (just the stylesheets and an XSLT engine) that will work on any platform and is free from other dependencies. I agree, but I would like to ask one question about XSLT stylesheets. How to translate docbook's amp; to LaTeX's \ using XSLT only? [snip] - Should I focus in providing support for the 1 or 2 most widely used XSLT processors in benefit of the number of features supported? [...] You might want to aim just for xsltproc and Saxon. If you can judge by postings to docbook-apps, xsltproc and Saxon are the engines most DocBook users are using; other than those and Xalan, XT, and 4XSLT, I can't think offhand of mention of any other engines showing up much on docbook-apps. I would like to see all the stylesheets working with Sablotron (http://www.gingerall.com). It is very, very fast and the PHP XSLT functions are based on this engine. Regards, Andrzej -- http://kokosz.horyzont.net http://www.earthdawn.pl
DOCBOOK-APPS: Re: Problem with Next/Prev links when usinghtml/chunk.xml
/ Vincent Hikida [EMAIL PROTECTED] was heard to say: | I'm having a problem in the html created using chunk.xml. | | Basically, the next and prev links are often wrong. An example is that | the next link may be ch03s02.htmlch04.htmlch04s02.html when it should be | ch03s02.html | I've documented my problem at http://www.vhikida.com/docbook/docbook.html | Can anyone tell me what I am doing wrong? This turned out to be a bug in 1.50.0. It's fixed in 1.51.x. (I introduced the bug trying to work around the Xalan problem. Grr) Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | To others we are not ourselves but http://www.oasis-open.org/docbook/ | a performer in their lives cast Chair, DocBook Technical Committee | for a part we do not even know we | are playing.--Elizabeth Bibesco
RE: DOCBOOK-APPS: Re: Problem with Next/Prev links when usinghtml/chunk.xml
/ Vincent Hikida [EMAIL PROTECTED] was heard to say: | I'm having a problem in the html created using chunk.xml. | | Basically, the next and prev links are often wrong. An example is that | the next link may be ch03s02.htmlch04.htmlch04s02.html when it should be | ch03s02.html | I've documented my problem at http://www.vhikida.com/docbook/docbook.html | Can anyone tell me what I am doing wrong? This turned out to be a bug in 1.50.0. It's fixed in 1.51.x. (I introduced the bug trying to work around the Xalan problem. Grr) Be seeing you, norm vincent Oops my previous reply only went to Norm and not the rest of the list. Using 1.51.1 fixed the problem. /vincent
