Framemaker server and loading illustrations

[_Edwin_Walter_]

Hi all,

we're using Framemaker server to automatically process large manuals with heavy illustrations into PDF. We do a number of automated actions on the Framefiles after we've started Frame and loaded the XML.

The problem we're facing is that the performance can be so much better if Framemaker wouldn't load all the illustrations while parsing the XML, opening the frame files, etc UNTIL it's ready for printing the TPS file, when the actual illustrations should be written. It seems to us, this is something only really required for the desktop version where the illustrations need to be displayed.

Would there be anyone out there who has encountered this problem and knows of a secret registry setting or another amazing workaround to boost Frame?

If not, is this something which is easy to implement in a future update?

Regards,
Edwin Walter.

[frameexpert]

If you open a FrameMaker file and choose View > Options, you can uncheck the Graphics checkbox at the bottom and click Set. You would have to do this in your template, since this is a document-level setting. I don't know if this will solve your problem, but it is worth a try.

Rick Quatro
rick at frameexpert dot com
585-659-8267

[juan_souza]

Edwin,

Since you are configuring an automated system, I am guessing you need a solution that doesn't involve manual tweaking in the middle of the publishing process. I would add to Rick's suggestion that you use FrameScript to change the View > Options setting dynamic ally, once the document has been parsed and is fully loaded in Frame. At least you could see what is really slowing down the processing. You might be surprised to find out that it is not the image rendering.

If the rendering does happen to be the reason behind the slow response, you could reference a low-resolution version of your images when you first load the XML file, then you save a MIF file and close the document. Finally, you process the MIF text file to change the reference to the high-resolution images and open the resulting MIF file in Frame Server. It doesn't go through the full parsing any more, so it doesn't take as long. And then you are all set to print. All this can be automated using FrameScript.

However, what has worked for me in more than one occasion is my last suggestion: make your documents smaller. You can break them down into documents of lower-level elements (chapters, sections, or whatever structural component is available below your current document level). This really helps reduce the time FrameMaker takes to parse and load files. You will probably see that the difference is literally exponential.

Regards,
Juan Souza

[_Edwin_Walter_]

Thanks for your replies.

I don't think setting the option will help us a lot. We will give it a go though. But it's the loading of the illustrations that is causing the trouble which is done even when you uncheck the Graphics option. Actually, when I do this manually, I will need to check the box again before printing otherwise my illustrations are not in the PDF.

Same for the MIF solution. The XML parsing isn't the main issue.

We've tried using dummy illustrations in the XML and then loading goes VERY fast. Before printing we replace the references to the real illustrations again and in the end it didn't give us any performance enhancements, because at that point it is still going to load the large illustrations.

I understand that scaling down and using a different illustration format will make the performance also a lot better bet lets assume for now that this is not an option and out of our control at the moment.

So the processing is not the problem. We think it's the fact that Frame loads the illustrations in a certain way which is NOT required for printing to TPS but only for viewing on screen. So, internally frame loads, converts, scales, and performs a number of actions on the illustrations (JUST for viewing on screen) and then copies the illustrations in the TPS just as they are (without scaling, etc) and then Distiller has to do the scaling, rendering, etc, all over again. So, if Frame server would be able to stop doing that and keep treating the illustration as a link only to use them during printing and leave the rest to Distiller...... Wouldn't that be something!

[_Edwin_Walter_]

Rick,
we tried this and it seems to behave exactly as what I wished for in my last post in the last paragraph! We added it to the template (we disabled all views) and it's brilliant. Performance has gone up big time.

If you're ever in the neighbourhood of Hengelo, The Netherlands I'll buy you a beer!

[_Edwin_Walter_]

Some further testing shows that my initial enthousiasm was probably caused by caching or a momentary lapse of concentration. Using the View Graphic option in the end does not seem to do the trick for us. Frame still completely loads the illustration.

We confirmed this by loading a dummy illustration during parsing of the XML and replacing it with the actual picture after parsing (using some custom API functions). When we let Framemaker load the original illustrations with the View graphics checked Framemaker took just as long loading the illustration as with the View Graphics unchecked.

We'll open up a new topic in this forum with a proper desciption of what we are really looking for to see if someone has come across this issue before.