Re: failure to produce PDF documentation

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

On 7/10/24 03:46, Andrey Semashev wrote:
> 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.

Try changing that URL to https. I.e., to this:

https://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl

It looks like the redirection is from http to https.