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