[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

RE: Updating large books



> I ran some tests on a large book with 280+ files, 2000+ pages using both Unix FM7 and FM5.5.6 run on files out on our Unix network using a SunBlade 100. Results using FM7 and FM5.5.6 files are very similar in most areas. There is a problem when opening a book composed of FM5.5.6 files with FM7. This problem can be solved by converting all the files to FM7 via fmbatch before opening the book. 
> 
> [Note: These particular test files in this book are each logging a font substitution message while being opened for the mif<->fm conversions. This may be slowing the process a bit more than would be usual if the files were "clean" and no warning messages were posted.]
> =========
> Opening book files:
> FM7 native files: book file opens in a couple of seconds (certainly in under 5 seconds).
> FM5.5.6 native files: book file opens within a second or two (a bit faster than the FM7 version).
> 
> The following situation produced a delay that was unacceptable. 
> FM7 opening FM5.5.6 book: book takes 5 minutes to open (delay caused as book ticks through the FM5.5.6 files in the book).
> However, if we were going to transfer a file to FM7 we would batch the process of conversion of all files to the FM7 native format, in which case we would get the acceptable results listed above.  
> =========
> Batch conversions from fm to mif and mif to fm:
> Batching results FM7
> fm556 to fm7mif all files: 8 min. 8 sec
> fm7mif to fm7binary: 7 min. 08 sec.
> 
> Batching results FM5.5.6, all are native 5.5.6 files, mif or fm (binary)
> fm to mif: 7 min. 20 sec.
> mif to fm: 7 min. 06 sec.
> 
> The batch results indicate that conversion to the new format takes no significant extra time, so the thing to do is convert all your files to FM7 binary before opening the books. The differences shown here are small enough that they may be the result of other processes running on the machine and/or higher network traffic at the time of a particular test.
> =========
> Generation/update times (all files opened beforehand):
> About 8 minutes (both 5.5.6 and 7, though on a subsequent generate I got FM7 down to about 2 min. 20 sec. That was probably due to a lower load on the machine and/or the network.)
> No significant differences between FM5.5.6 and 7 when working with their native binary files.
> =========
> Adding 280+ files to a new book:
> FM5.5.6 almost instantaneous (about 5 seconds)
> FM7: 5 minutes 
> The method used for adding files was not drag & drop. I used Add-> Files -> (typed *.fm in the selection line to show only those files), checked "Add All Listed Files to Book" and clicked Add. (I wouldn't know how to use drag & drop in the FM Unix environment.)
> 
> Adding large numbers of files to a book is definitely slower in FM7. For legacy documents this is not a problem though since a conversion via batching results in a book with all the files already present within it. In our work we rarely build books with 200+ files. Even at that size a 5 minute build time is not too excessive. 
> 
> Large books can be constructed via scripts by MIF snippet additions to an empty template book that "fill in" the filenames as mif statements. This is rather kludgy, but works, resulting in a book that takes only a few seconds to open in FM7. It is enough to put the following 3 MIF lines for each file you want to add before the final  > # End of Book statement (in the appropriate sequence, of course) .  Here's hoping the < and > come thorough in the mailing):
> 
> line 1: <BookComponent 
> line 2: <FileName `<c\>cover.fm'>
> line 3: > # end of BookComponent
> ... (repeat in sequence desired for all files)
> # End of Book
> 
> Of course you could decorate up these insertions to make certain files appear as generated files or have specific numbering characteristics for such things as Chapter and Page. You could also do this after the fact manually once you open the resulting book.> 
> =========
> Best,
> 
> Craig
> 	 -----Original Message-----
> 	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 	Subject: RE: Updating large books
> 	From: eric.dunn@ca.transport.bombardier.com
> 	Date: Tue, 13 May 2003 11:22:54 -0400
> 	X-Message-Number: 17
> 
> 
> 
> 	Now. I admit that I'm still using FrameMaker 5.5.6 but my exploratory forays
> 	into FM7 were not encouraging when it comes to large book files. Seems that a
> 	number of rather dubious improvements were added that add significant time and
> 	questionable utility to book generation and opening. I make that assertion as
> 	the only thing that's an immediately obvious possible cause is the addition of
> 	the page range to the book status bar.
> 
> 	I once tried to create a giant book using FM7 because of the drag-and-drop
> 	interface. Grabbing all the files from a find dialog and dropping them in the
> 	book window resulted in a seven hour wait as the computer was bogged down doing
> 	god-knows what.
> 
> 	Copying all the files to one folder and using FM5.5.6 and right-click>Add
> 	File>Ctrl-A, resulted in a complete book in a minute or so. I am NOT looking
> 	forward to when we migrate all our work to newer versions of FM. Simply opening
> 	many of the books we currently work on with ease will take possible hours for
> 	the first time open to update the files to FM7. It's probably going to be a
> 	horrendous hit to productivity even once all the files are updated. Creating new
> 	files is going to be particularly onerous.
> 
> 	Here's a request for Adobe: Make more options available to the users. Let us
> 	turn off this added 'functionality' for one. Another area I'd like to see
> 	options is in 'Save as MIF'. Let us save as mif without the paragraph format or
> 	other catalogues. Allow the dropping of any combination of all mif elements till
> 	you arrive at pure content tagging. Heck, a little work and mif would be fully
> 	XML compliant.
> 
> 
> 
> 	Eric L. Dunn
> 
> 
> 


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **