Re: Adobe Framemaker Practical Uses

Subject: Re: Adobe Framemaker Practical Uses
From: Chris <cud -at- telecable -dot- es>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 20 Dec 2001 10:57:53 +0100

Time for my 0.02 euros...

Where FrameMaker is *required* by people is in the industrial strength area. Examples that I have experienced in 2001:

Cell library datasheets (EDA fru-fra) comprised of 500+ cells. The client sends me 30+ Meg of MIF generated by their simulation processes. I update/edit the introductory discussions, import their data, generate TOC and other lists, then generate PDF. The result is in the area of 1000 pages for each library, with individual files up to 200 pp comprised almost entirely of tables. Using Maker, I can turn a job around in about 4 hours. I hate to think how that would work in a product that was not "industrial strength". The templates were designed by a graphic designer and look really nice, so while it's industrial strength, the project also incorporates aesthetics.

The British Parliament writes their bills in SGML - they use Maker+SGML. Maker+SGML is interesting to them because the formatting (page/type design) is reasonable, and so is the SGML editing environment. I developed a plugin that automates some of their processes. Again, we're talking about many pages, plus SGML, which is app-independent.

A manufacturing company writes their docs in SGML, and stores chunks of it in a doc database. They author in Maker+SGML - I produced a plugin that attunes xref management to the doc database. Then they assemble the chunks into a publication in Maker+SGML. SGML and many pages, yet again.

Aviation maintenence manuals - I developed a plugin that generates a list of effective pages and a print job for just the loose-leaf pages that have been changed (the "effective" pages). Not SGML, but many pages, yet again.

A common theme is some sort of automation. In fact, for this year of (?) recession (?) I have seen little writing work and much programming work. Automation is very interesting these days. So FrameMaker is also interesting because it offers two basic routes for automation - you can generate MIF via some process, and you can automate processes within the product via an API. Of course, this is not just a FrameMaker thing - Word has VBasic and RTF, for example. But it is a recurring theme in the FrameMaker arena. So as you use FrameMaker, you should get used to thinking about your *process* and keep an eye open for two things:

How to design/author documents in ways that are open to automation. What I mean is, how to keep the document data "normalized", and how to identify data by type, not just by appearance. The more you do that, the easier it will be to automate any given authoring process. This is considered "good citizenship" in the FrameMaker world. Specific example: Design your char and pgf formats, and don't use format overrides.

What processes do you repeat often, and can they be automated? If you constantly repeat a specific set of steps, then you're asking for errors and wasting time. Automation may be called for. Just keep that in the back of your mind. (Is this a shameless advertising ploy? Yes and no - Whether or not I get the contract, I still think it's a good idea. The more we all think in terms of automation, the sooner we will all develop environments that are more friendly to SGML/XML - see below.)

I would look forward to more action in the SGML/XML area in the near future. B2B (the recent failure notwithstanding) is waiting for net bandwidth - when that comes there will be an XML explosion. XML will divide into (at least) two general categories - short snippets that get zipped around the net, and large publications that get frozen in a specific state (read "paginated") to represent the known information at a given point in time. Microsoft + .NET + Word will try (and probably succeed) to dominate the former. My guess is that until the current concept of "document" changes radically (which it must as a result of XML - 4 years from now?), FrameMaker will be included in many SGML/XML authoring systems, and will be used to build many of these large, frozen publications.
So I suggest you pony up for Maker+SGML, and get comfortable with that. If you can make an EDD that automatically formats your text depending on where you put it in the document's structure, you are well on your way to understanding SGML/XML.

cud

--
Chris Despopoulos, maker of CudSpan Freeware...
Plugins to Enhance FrameMaker & FrameMaker+SGML
http://www.telecable.es/personales/cud/
cud -at- telecable -dot- es



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Be a published author! iUniverse gives you: a high-quality paperback, a
custom cover design, and distribution to 25,000 retailers. And it's
affordable. Join our almost 10,000 published authors today.
http://www.iuniverse.com/media/techwr

Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.



Previous by Author: Re: Batch converting image references in Frame
Next by Author: RE: Hacko and process
Previous by Thread: RE: Adobe Framemaker Practical Uses
Next by Thread: ForeHelp Help


What this post helpful? Share it with friends and colleagues:


Sponsored Ads