Hi,
I am running on Mint 19.3 and my installation has /etc/xml and xsltproc
apparently standard, so I ran the xsltproc with the --path option set
to '/etc/xml' resulting in the following timings:
ruurd@Paradigit2:~/oorexxdocs$ xsltproc --timing --xinclude --path
'/etc/xml' -o fo_files/rxmath.fo pdf.xsl
/home/ruurd/oorexxdocs/source/rxmath/en-US/rxmath.xml
Parsing stylesheet pdf.xsl took 1 ms
Parsing document /home/ruurd/oorexxdocs/source/rxmath/en-US/rxmath.xml
took 14 ms
XInclude processing
/home/ruurd/oorexxdocs/source/rxmath/en-US/rxmath.xml took 190 ms
Making portrait pages on A4 paper (210mmx297mm)
Running stylesheet and saving result took 1904 ms
ruurd@Paradigit2:~/oorexxdocs$
I did not really follow all the discussions with respect to making the
pubs, so I don't know if the difference in timing for the XInclude phase
with poj's effort is significant but thought it might mean more to those
involved in this.
Ruurd
On 4/27/20 7:04 PM, P.O. Jonsson wrote:
Dear Gil,
I have been trying (failing is a better word) to bribe xsltprocess to
accept a local input file, the file referred to in the DOCTYPE
statements (docbookx.dtd)
IS what you have in mind is to replace all those DOCTYPE statement
with a local file? I have that file locally I just cannot get xsltproc
to eat it :-(
If you know the magic ingredient to xsltproc I am eager to hear about it.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se <mailto:oor...@jonases.se>
Am 27.04.2020 um 18:54 schrieb Gil Barmwater <gbarmwa...@alum.rpi.edu
<mailto:gbarmwa...@alum.rpi.edu>>:
If you look at the structure of our "books", you will see that each
"piece" is a separate "document" with a DOCTYPE statement at the
beginning. This means that XSLTPROC must load the DTD that is
specified on that statement for each piece and, of course, that means
getting it from the internet at present. By making the DTDs available
locally, this process should go much faster. We'll see...
Gil
On 4/27/2020 11:59 AM, P.O. Jonsson wrote:
Ok, I would be in favor of a clean Linux solution if we are to go
away from Windows, Cygwin seems to me a „bastard“ that may not be
maintainable in the long run. Windows or Ubuntu are both better
options.
I checked the Jenkins master, it does not have any of the folders
you refer to (/etc/xml et al).
I have tried a lot of different settings to conclude that the step
that takes dramatically more time in doc2fo processing is the
*xinclude* step, is the DTD stuff part of that? Here a run for
rxmath with timing info and then the same again without the
—xinclude option (with and invalid fo file):
Parsing stylesheet pdf.xsl took 15 ms
Parsing document ooRexxDocSVN\rxmath\en-US\rxmath.xml took 10594 ms
XInclude processing ooRexxDocSVN\rxmath\en-US\rxmath.xml took 130844 ms
Making portrait pages on A4 paper (210mmx297mm)
Running stylesheet and saving result took 2125 ms
fo2pdf only takes 3-4 seconds after this.
Once again without —xinclude:
Parsing stylesheet pdf.xsl took 0 ms
Parsing document ooRexxDocSVN\rxmath\en-US\rxmath.xml took 10928 ms
Making portrait pages on A4 paper (210mmx297mm)
Element include in namespace 'http://www.w3.org/2001/XInclude'
encountered in book, but no template matches.
Element include in namespace 'http://www.w3.org/2001/XInclude'
encountered in book, but no template matches.
Element include in namespace 'http://www.w3.org/2001/XInclude'
encountered in book, but no template matches.
Element include in namespace 'http://www.w3.org/2001/XInclude'
encountered in book, but no template matches.
Element include in namespace 'http://www.w3.org/2001/XInclude'
encountered in book, but no template matches.
Element include in namespace 'http://www.w3.org/2001/XInclude'
encountered in book, but no template matches.
Element include in namespace 'http://www.w3.org/2001/XInclude'
encountered in book, but no template matches.
Running stylesheet and saving result took 1939 ms
Obviously the fo does not build correctly (but it does build). BUT I
was starting to think I might be hunting the wrong files? Maybe it
is the downloading of this „element“ that takes time, over and over
again?
Just a thought, input is welcome.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se <mailto:oor...@jonases.se>
Am 27.04.2020 um 17:35 schrieb Rony G. Flatscher
<rony.flatsc...@wu.ac.at <mailto:rony.flatsc...@wu.ac.at>>:
Forgot to give the timings on Ubuntu (an older desktop PC):
rony@rony-linux:~/dev/orx-docs$ sh doc2fo.sh
rexxpg ...
Making portrait pages on A4 paper (210mmx297mm)
*1.04user* 0.03system 0:01.08elapsed 99%CPU (0avgtext+0avgdata
67912maxresident)k
0inputs+3256outputs (0major+18209minor)pagefaults 0swaps
/home/rony/dev/oorexx-code-0/docs/trunk/rexxpg/en-US/Common_Content
rexxref ...
Making portrait pages on A4 paper (210mmx297mm)
18.83user 0.04system 0:18.88elapsed 100%CPU (0avgtext+0avgdata
182656maxresident)k
0inputs+22416outputs (0major+48572minor)pagefaults 0swaps
/home/rony/dev/oorexx-code-0/docs/trunk/rexxref/en-US/Common_Content
rony@rony-linux:~/dev/orx-docs$
So rendering doc->fo gets quite fast. :)
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
<mailto: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
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
<mailto: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
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
