At 12:48 AM 2/6/2006, John Pitt wrote:
>  Until now I've been developing my FM and WebWorks templates using a 
> subset of the data available, which produces a book of about 1250 pages 
> (one chapter of >1000pp and 4 smaller ones which mostly consist of xref 
> "lists" that are pointing to the main chapter). The previous xml files 
> were about 2 Mb; the latest file is 24Mb.
>Both of my attempts to open/convert the big bugger have failed. After 
>about 90 min, Task Manager's Performance window shows a rapid rise in MEM 
>Usage from about 700Mb to 2.15 Gb, and Frame displays one of its "Hmmm. 
>Dunno what's happening, but send us the error file and we'll look at it 
>(but we won't let you know the outcome)" messages. Killing that message 
>kills Frame.
>Q1 Is the file too big for Frame? I can remember opening bigger files on 
>UNIX FM 5.1.
>Q2 Will I gain anything by grovelling for another Gb or two of DRAM?
>Q3 Is there anything I can do? We would prefer not to cut up the xml file 
>as we want all chapters to talk to each other without spending long 
>periods resolving broken xrefs.

   Your XML application is set up to create a book from the single XML 
document? 1000+ pages is pretty big for one structured file. I suspect the 
problem is in the number of elements in that chapter rather than in the 
cross-references. You can confirm that theory by creating an XML document 
with just that chapter and importing it.
   If that is indeed the problem, you might try setting up the application 
to divide it into 4 or 5 book components. You may need to modify the DTD a 
bit to do so (easy to do with DocBook by changing parameter entities). I 
sometimes allow a chapter to have a structure such as:


where <chapterstart> has the chapter title, introductory paragraphs, and 
first sections and each <chapterpart> contains one or more sections 
(possibly preceded by paragraphs, lists, etc. if the <chapterstart> doesn't 
contain sections). Thus, the structure of <chapterstart> is just like a 
usual chapter, and that of <chapterpart> is the same without a title.


Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development, 
and training
lprice at  
voice/fax: (510) 583-1505      cell phone: (510) 421-2284 

Reply via email to