Re: failure to produce PDF documentation

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-07-10 00:46:35

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/13ca3d6dd36db1aac2d6b5caca2c281d15c881ad/doc/boostbook/bb2db.xsl#L3
> 
> <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/13ca3d6dd36db1aac2d6b5caca2c281d15c881ad/doc/boostbook/db2fo.xsl#L9

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.