If I did every topic separately and added more for chunks smaller than a topic, I'd be around 1000. I'm the lone writer so I don't work on the network. My current work is always local (regular backups made to other locations of course!) so that's not part of the speed problem. All I know is when I built a book with 3 chapter files that had a total of about 300 insets, everything slowed *way* down and FM was all I had running!
Richard has suggested that I keep fewer fm files, each with multiple insets in different flows. That would simplify opening/closing files as well as organizing so many files so that I can find them easily. I've also begun putting some of these topics back together because, at least for now, they all appear together in all outputs. There's no real reason to keep them all individually. I think I have to assimilate all of these ideas and give those first 3 chapters another try! Thanks so much! Judy Art Campbell wrote: > Judy, so how many insets is that? Tens, or hundreds, or thousands? > > To me, 50% utilization isn't much and I wouldn't be concerned... but > when you start juggling hundreds of files, there's a corresponding hit > on the operating system and network traffic; it's larger than just in > FM. Within FM, you can also pick up some speed if you toggle automatic > updating of the insets to Off, if you can -- probably depends on how > often the content of the insets changes. > > Art > > Art Campbell > art.campbell at gmail.com > "... In my opinion, there's nothing in this world beats a '52 > Vincent and a redheaded girl." -- Richard Thompson > No disclaimers apply. > DoD 358 > > > > On Tue, Jun 2, 2009 at 12:31 PM, Judy <judy at hypack.com> wrote: > >> Art and Richard both recommended the idea of insetting topic body text >> between the headings in a container doc. My biggest qualm about using >> container docs with all of the headings then insetting the body text is the >> sheer number of insets. >> I recently tried breaking my doc set into topic-sized fm docs, then building >> the different outputs with the topic fm's as insets to a chapter container. >> It worked great w/ 1 chapter, but when I tested it with the first 3 >> chapters, FM couldn't handle it. (50% CPU usage on a 2 Ghz CPU w/ 2Gb RAM >> and only FM was open. Plenty of hard drive space too.) I may be able to >> compromise, in this case, and inset only those whose headings change though. >> >> Ted also suggested a tool by Silicon Prairie Software that uses mapping >> tables to convert 1 para style to another. It sounds like I could keep a >> book of those topics whose headings need to shift levels and use this tool >> to set the correct heading level before generating the final output. That >> sounds easy enough. Does anyone see any "gotchas" with that approach? >> >> Thank you all for your thoughts on this question. I always learn so much >> from you on this list and I appreciate the time you take to make it what it >> is. I hope someday, I'll have gained enough experience and wisdom to return >> the favor. >> Judy >> >> Combs, Richard wrote: >> >>> Judy wrote: >>> >>>> The challenge is how to best handle those topics that appear in more >>>> than 1 output, but at different heading levels--most commonly an H3 in >>>> the full manual becomes an H2 in the quickstarts. >>>> >>>> I've thought about: >>>> - Multiple conditionalized headings, but that would cause xref >>>> >>>> >>> issues. >>> >>> >>>> - Building a container doc for each output where the headings are >>>> entered directly but topic content inset by reference. This may work, >>>> but I'm not sure it's the best answer. Does anyone else have any >>>> >>>> >>> ideas? >>> >>> By all means, put the headings in the container and only the body text >>> in the text inset source. Even in the absence of your heading-level >>> conflict, this is a pretty good idea. Cross-references to pgfs inside a >>> text inset are a pain. Keeping the section headings in the container doc >>> lets you point xrefs to those headings. >>> I prefer to have the section headings in the container doc and only the >>> content under them in the text inset source. Haven't seen a downside. >>> YMMV, of course... >>> Richard >>> >>> >>> Richard G. Combs >>> Senior Technical Writer >>> Polycom, Inc. >>> richardDOTcombs AT polycomDOTcom >>> 303-223-5111 >>> ------ >>> rgcombs AT gmailDOTcom >>> 303-777-0436 >>> ------ >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > > >
