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
problem?
----- Original Message -----
Sent: Saturday, March 10, 2012 3:23
PM
Subject: Re: [docbook-apps] Re:
VirtualBox DocBook 5.0 VM
Jeff,
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.
Regards,
Dean Nelson
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
using XPointers.
Regards,
Jeff
Jeff,
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?
Dean
In a message dated 3/9/2012 10:57:20 P.M. Pacific Standard Time,
jpowanda@vocera.com writes:
Hmm, my docs are tiny
compared to that. Are you using XIncludes, olinks, and
profiling?
Here's how I'm calling xsltproc in my build.bat
file:
call xsltproc.exe --nonet
--xinclude --stringparam profile.condition %conditions%
--stringparam olink.debug 0
--stringparam collect.xref.targets "no" --output
%output_file% --stringparam
insert.xref.page.number yes --stringparam
insert.olink.page.number maybe --stringparam
target.database.document %olink_file%
--stringparam current.docid %doc_id% %xsl_file%
%book_file%
Regards, Jeff
________________________________
From:
DeanNelson@aol.com [mailto:DeanNelson@aol.com] Sent: 2012-03-09
03:06 To: DeanNelson@aol.com; Jeff Powanda;
tom.browder@gmail.com Cc: docbook-apps@lists.oasis-open.org Subject:
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
writes:
Jeff, I
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?
Regards, Dean Nelson
In a message dated 3/9/2012 2:22:48 P.M. Pacific
Standard Time, jpowanda@vocera.com writes:
I'm using the Windows version of
xsltproc.
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
wrong.
Regards, Jeff
-----Original Message-----
From: Tom Browder [mailto:tom.browder@gmail.com]
Sent: 2012-03-09 09:31
To: Jeff Powanda Cc: Docbook
Apps Help list Subject: Re: [docbook-apps]
Re: VirtualBox DocBook 5.0 VM
On Fri, Mar 9, 2012 at 11:25, Jeff Powanda
<jpowanda@vocera.com> wrote: > Ok,
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.
-Tom
---------------------------------------------------------------------
To unsubscribe, e-mail:
docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
docbook-apps-help@lists.oasis-open.org
=
|