On 7/10/24 03:29, Andrey Semashev wrote:
On 7/10/24 01:00, Robert Ramey via Boost wrote:
For many years, I've been using the xslt based system for converting boostbook xml into html an pdf files. Once I got it set up, I've never had a problem.
But now, it is failing with some error messages provoked by the contents of some xml files which are part of boost book. A casual review of the correspondng github repository shows the that the some of these files have been "maintained" recently ... some as recently as 3 days ago. Could someone (probably the maintainer) look into this.
I noticed that when I try to appy this to the safe numerics library. The following should reproduce the problem:
cd /Users/robertramey/WorkingProjects/modular-boost/libs/safe_numerics/doc/boostbook
$ls *.sh makeepub.sh makehtml.sh makepdf.sh makeproposal.sh
$echo $PATH /Volumes/public/fop-2.1:.:/Volumes/public/menu_bash:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin
$./makepdf.sh [Fatal Error] docbook.xsl:6:3: The element type "hr" must be terminated by the matching end-tag "</hr>". http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl; Line #6; Column #3; org.xml.sax.SAXParseException; systemId: http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl; lineNumber: 6; columnNumber: 3; The element type "hr" must be terminated by the matching end-tag "</hr>". Jul 09, 2024 2:58:38 PM org.apache.fop.cli.Main startFOP SEVERE: Exception ...
I think the problem is caused by the fact that you are importing the stylesheets using HTTP URLs. For example, here:
https://github.com/boostorg/safe_numerics/blob/13ca3d6dd36db1aac2d6b5caca2c2...
<xsl:import href="http://www.boost.org/tools/boostbook/xsl/docbook.xsl"/>
This URL produces an HTML page that presents formatted docbook.xsl instead of raw XSLT that is expected by xsltproc. Changing that to:
<xsl:import href="../../../../tools/boostbook/xsl/docbook.xsl"/>
allows the command to proceed, but it then breaks on other imports that use HTTP URLs.
I'm not sure how it worked before or what changed. Perhaps, the website used to serve raw BoostBook XSLTs before?
In any case, I don't see how my changes to BoostBook stylesheets could have caused this. I don't control how the website serves content.
Actually, your error refers to this URL: http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl presumably, from this line: https://github.com/boostorg/safe_numerics/blob/13ca3d6dd36db1aac2d6b5caca2c2... which is not part of BoostBook or Boost website. The issue is the same, though. Accessing that URL produces a referrer HTML page with a 301 error code. Presumably, fop doesn't follow the redirection and fails for the same reason I described above - it expects an XSLT but receives an HTML stub page. I'm not sure how to make fop follow redirects. I don't see any relevant options in its man.