Two days ago I asked a question about Oxygen's ability to process lots
of images. Thanks for the reply by the way with the tip about XEP.
I have a related question which is annoying me, and I think it is an
Oxygen-related question (and not an XEP question).
In Docbook 5 I am using xincludes, and I am using 300 dpi images (with
dimensions ranging from 1200 x 1500 more or less). They are jpg file
at 100% quality and range from 600K to 1 MB. One of the files is
2300x1500
In my Docbook 5 project I scale the image so that the size when
printed is about 3 inches.
But here's the thing. After I add as few as three images to a chapter
(and sometimes less), XML Author pretty much grinds to a halt. The
chapter is an xinclude file. (I'm in Windows Vista 64 bit and have 4
gigs RAM, and RAM usage by Oxygen goes up to about 700,000 or 800,000
MB RAM. I can continue editing, but very slowly. Once I switch back to
XML mode, everything is fine. I have gotten no validation errors or
anything like that, and the xml file itself is not overly big (30 K).
I've tried to open the same xml file on a different machine, a 64 bit
Windows 7 with 4 Gigs RAM. I receive the same slowdown.
Is this typical? Do you have any suggestions about how to avoid
this slowdown? It's gotten so bad that I've had to comment out the
images until I have to produce the PDF (a real pain).
At the moment each of my mediaobjects have 2 imageobjects. The 2nd is
an empty folder for a web version of the same image. If worse comes to
worse, I could delete this extra imageobject, but eventually I need to
add it.
<screenshot>
<mediaobject>
<imageobject role="html">
<imagedata fileref="web-images/"/>
</imageobject>
<imageobject role="fo">
<imagedata
fileref="fo-images/history-byline.jpg" contentwidth="10cm"/>
</imageobject>
<textobject>
<phrase>.</phrase>
</textobject>
<caption>
<para>If your content is being versioned, you
will see a History hyperlink
near the byline. </para>
</caption>
</mediaobject>
</screenshot>
--
Robert Nagle