I'm curious too about the olink problem you mentioned. Olink
collection and olink resolution should both take place after any XIncludes have
been processed and resolved, so I'm not clear how an XInclude with an XPointer
would create a problem. Can you provide any more specifics about that
----- Original Message -----
Sent: Saturday, March 10, 2012 3:23
Subject: Re: [docbook-apps] Re:
VirtualBox DocBook 5.0 VM
Maybe I am not understanding the depth of the issue because I use
XIncludes and XPointers and they work for me both in xsltproc and Saxon/Xerces
(I maintain both in my development environment).
I have also used profiling in the past and had no problem. However, maybe
you have come across an issue that I have not seen yet.
I'm using single-pass
profiling. I've tried using two-pass profiling, and that allows me to
generate our larger books with xsltproc, but when I do that the olinks to
any XIncludes that use XPointers don't get resolved correctly. XPointers
remain a problem for me whether I use xsltproc or Saxon-Xerces-J (which
doesn't support xml:id syntax). Not sure what I should do, other than avoid
I use XIncludes, and not olinks or profiling (on the file I just used).
The only difference in the switches is that I use --novalid which skips
the skips the Dtd loading phase.
Are you using single pass profiling or two-pass?
In a message dated 3/9/2012 10:57:20 P.M. Pacific Standard Time,
Hmm, my docs are tiny
compared to that. Are you using XIncludes, olinks, and
Here's how I'm calling xsltproc in my build.bat
--stringparam profile.condition %conditions%
--stringparam olink.debug 0
--stringparam collect.xref.targets "no"
--stringparam current.docid %doc_id%
To: DeanNelson@aol.com; Jeff Powanda;
Re: [docbook-apps] Re: VirtualBox DocBook 5.0 VM
One more bit
of info. I just ran a 1200 page doc (XP/2Gb/xsltproc) and it used about
230 MB of memory to churn through that doc.
In a message dated
3/9/2012 2:44:36 P.M. Pacific Standard Time, DeanNelson@aol.com
routinely process books over 400 pages (XP/2Gb/xsltproc) and rarely see a
memory error. However, when I DO see one, it is because I have done
something wacky in the XSL or have done something in the XML that was
"legal" but not supported in the XSL. Rare though.
What command line switches are you using?
In a message dated 3/9/2012 2:22:48 P.M. Pacific
Standard Time, email@example.com writes:
I'm using the Windows version of
xsltproc worked fine on our smaller manuals (~50 pages), but it wasn't
able to handle our largest books (~400 pages). I need to be able to build
all the manuals on the writers' machines, which are Windows 7 or Windows
XP laptops with only 2 GB of RAM. Xsltproc couldn't seem to handle those
constraints. Saxon+Xerces can.
If other people are using xsltproc under similar
constraints on Windows and it's working fine, perhaps I'm doing something
From: Tom Browder [mailto:firstname.lastname@example.org]
Sent: 2012-03-09 09:31
To: Jeff Powanda
Apps Help list
Subject: Re: [docbook-apps]
Re: VirtualBox DocBook 5.0 VM
On Fri, Mar 9, 2012 at 11:25, Jeff Powanda
thanks. I switched from xsltproc a few years ago when it was
> unable to process our largest manuals (it ran
out of memory).
Was that a Windows version, or *unix?
Size of manual?
I'm sure libxslt
folks would love to hear about that whichever system it was on.
To unsubscribe, e-mail:
For additional commands, e-mail: