Phew! I have been trying to replicate your steps in vain for the past two days, I did not want to bother you with my failures. I also found out that making to many failing attempts I „broke“ JAVA so everything after these failures the error messages were completely unpredictable.
On Jenkins everything run smooth so it is only when you mistreat xsltproc that things start go bad. This is what I found out so far: Adding the option —catalogs (minus-minus-catalogs, the spell checker messes with my text), the DTD should be taken from what SGML_CATALOG_FILES points to. I have tried a number of things but nothing really worked. All these did NOT work (and some others also not): set SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/docbook.dtd/" set SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/docbookx.dtd/" set SGML_CATALOG_FILES="C:\Users\po\workspace\ooRexx-docs-build_V2\docbook-xml-4.5\docbookx.dtd" set SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/" set SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/„ What I did notice is that the zipped archive you pointed to does not contain a file docbook.dtd but a file docbookx.dtd I am also not sure if the —catalogs wants a single file, or a number of files, as in docbook-xml-4.5/ (or docbook-xml-4.5) directory, I am not I also read somewhere that you could enter the path to the dtd directly as the first command on the commandline, but I never tried it. The debugging process is very slow since you need to erase all files between runs and wait 3-4 minutes for the quickest files. And indeed if you have a fo file existing and the xsltprocess breaks the fo2pdf will just use the existing fo file, this takes a few seconds only. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 26.04.2020 um 15:58 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>: > > Well, after returning and setting up the environment according to my own > directions it turns out that they are *not* doing what I thought they were! :( > > So please ignore this post. > > ---rony > > P.S.: Not sure what has happened, in the meantime I think it to be possible > that the step doc2fo was skipped and an existing fo file got processed, but > not sure (as a result I added statements to delete the output files before > creating the new ones to the local batch files). > > P.P.S.: Still, I think the solution would be to get xsltproc to pick the dtd > and xls files from the local file system and not from the net. Just adding > "--nonet" will show which files cannot be loaded from the net. > > On 24.04.2020 16:19, Rony G. Flatscher wrote: >> Looked into it and tested a possible solution, here the steps: >> >> download the DocBook 4.5 DTDs from >> <http://www.oasis-open.org/docbook/xml/4.5/> >> <http://www.oasis-open.org/docbook/xml/4.5/>, unzip them, e.g. to >> "F:\work\svn\oorexx\docs\trunk\tools\tmp\docbook4.5\docbook.dtd" >> >> define a new environment variable for xsltproc to point to the directory >> that contains the unzipped document type definitions, but watch out for the >> format on Windows: start out with three slashes and turn all backward >> slashes in the path to forward slashes, also note the trailing slash: >> set >> SGML_CATALOG_FILES=///F:/work/svn/oorexx/docs/trunk/tools/tmp/docbook4.5/docbook.dtd/" >> Create the docs. >> E.g. "rexxref.pdf" now needs appr. 20 seconds to be created compared to more >> than 10 minutes without the local DTDs! >> >> ---rony >> >> >> On 23.04.2020 19:53, Gil Barmwater wrote: >>> I suspect the slow performance might be due to the (repeated) fetching of >>> the DTDs/stylesheets by the xsltproc/transform step. My internet connection >>> is intermittently bad and I would sometimes get "failures" due to the >>> inability of the program to get one of the files it needed. I'd suggest >>> someone look into making the files "local" so that they need not be >>> downloaded multiple times per "book". These files are "ancient" so there is >>> no need to worry about not getting the latest version. >>> >>> Gil >>> On 4/23/2020 1:07 PM, René Jansen wrote: >>>> good work! >>>> >>>> Amazingly slow performance though - needs more memory? >>>> >>>> René >>>> >>>>> On 23 Apr 2020, at 19:04, P.O. Jonsson <oor...@jonases.se >>>>> <mailto:oor...@jonases.se>> wrote: >>>>> >>>>> This is just to say that we now also have a bild of the HTML >>>>> documentation on Jenkins. It takes 1h30 to build the PDF and 1h50 to >>>>> build the HTML and I have set it to build@midnight, PDF first and HTML >>>>> thereafter. This can be changed if needed. All documents seems to build >>>>> just fine. >>>>> >>>>> There is currently no upload of documentation to Sourceforge -> Erich? >>>>> >>>>> To get hold of the documentation log in to Jenkins >>>>> <http://build.oorexx.org/> and select ooRexx-docs-build (PDF) or >>>>> ooRexx-docs-build2 (HTML) and then use the link Last Successful Artifacts >>>>> >>>>> Due to the way Jenkins create new workspaces ooRexx-docs-build >>>>> ooRexx-docs-build2 are identical parallel folders with the same latest >>>>> build tools from Gil, with some minor changes to fit it into Jenkins >>>>> environment. >>>>> >>>>> Hälsningar/Regards/Grüsse, >>>>> P.O. Jonsson >>>>> oor...@jonases.se <mailto:oor...@jonases.se> > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
