structured Frame
The fundamental issue is Return on Investment (ROI), whether the staff is one writer or 100. Here are the major cost factors that must be evaluated: A Realizable positive values of a structured solution. 1. A breakdown of the identifiable costs of the current unstructured methodology which can be reduced or eliminated by a structured approach. Most of these are reducible labor costs. 2. What needed current and future improvements in information management and productivity, not realizable under the unstructured approach, could be implemented under a structured approach. Consider not only current needs, but also predictable future needs which are only feasible under a structured approach. Estimate the long-term positive value to the enterprise of these improvements. B. Estimated negative costs of conversion to the structured approach 1. Cost of new software. 2. Cost of development to initially implement a structured approach. 3. The cost of training activities needed to implement the structured approach. C. Any additional positive and negative cost factors associated with the transition to a strucured approach. One probable positive value is that many employees outside the writing group will discover that they now have much more cost-effective ways to precisely locate and retrieve technical document information they need to perform their tasks. If you can assign realistic positive and negative numbers to the listed factors, and the positive values substantially exceed the new negative costs, you may be able to make the case for a structured approach. =
Registering a new FrameMaker license
I recall recent posts on this subject. Specifically about buying an old version of frame from Ebay, and then registering it with adobe so as to get the upgrade price for the latest version. Apparently, part of the problem is to be sure the copy is not already registered to someone else. How can I be assured that buying the product on Ebay is eligible for registration in my name. Also, I looked aroun on the Adobe website for the subject of how to register Framemaker as the crucial step in buying an upgrade.
Newbie with Questions
--- Kevin Rusnak wrote: > I want to successfully pull in XML into a structured > document. I am not > interested in much else then seeing it work; and > then making the process > more sophisticated after seeing it done. To pull existing XML instances into a structured FrameMaker document, the XML instances you intend to "pull in" must conform to a DTD, or, if the XML instances are coming out of a database, those instances must conform to the database schema, or they must conform to the schema defined by a database query you are issuing for the purpose of retrieving a particular set of "fields" from the database. It sounds like you are doing the latter, where Company Name, Account Rep, and Creation Date are the fields specified in the query, and each such field contains a value (or a null value if a field is not required to have a value). I further infer that the EDD structure should be as follows: Element (Container) CustomerGroup Valid as the highest-level element General rule: ?, Company Name+ Test Format Rules Element paragraph format: Category Comment: This element precedes the first company name in a category of customers, or, as a minimum, it must be the first element in the XML instance. The (if any) describes the name of the category. Element (Container) CompanyName General rule: (, AccountRep?, CreationDate?) Test Format Rules Element paragraph format: Company Name Comment: The CompanyName element is the parent of the (optional) AccountRep and CreationDate elements. Element (Container) AccountRep General rule: Test Format Rules Element paragraph format: Account Rep Element (Container) CreationDate General rule: So far I have a really basic 3 line Frame template > that I built in the > Structured authoring environment. > > 1. Company Name > 2. Account Rep > 3. Creation Date = You may have created those lines in a template created in the structured environment, but unless that template has had an EDD imported into it, it is not a structured template. == > What I am supposed to do next? There are books that > explain DTDs and > EDDs and elements and such. I realize the importance > of these documents. > I am just not sure how to proceed next. This is my > guess. I need to look > at my "structure" and hand code a DTD. I am guessing > that this document > will then allow me to add elements to my document > via the Element > catalogue. > > The whole process reminds me a lot of adding > cascading style sheets to > web pages on Dreamweaver...the one big difference is > I can create the > style sheets in Dreamweaver. I am still not seeing a > way to create the > EDD/DTD in Framemaker...without having a structure > in place. > > I assume this is the most basic of questions and > while many of the > resources that I have looked through elaborately > explain what each of > these items is, I have found very few resources that > will explain how to > tie them all together as a newbie. I have begun > looking through your > archives but thought that I would post the question > hoping for a brief > explanation of how to proceed with my experiment. > > I would really appreciate any finger pointing or > explanation that anyone > has time for. > > Thanks in advance. > > As a side note. I love this software and I love the > idea of what I am > going to eventually do with it. > > > > > Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Newbie with Questions
--- "Lynne A. Price" wrote: >If you are moving XML documents into FrameMaker, > or structured > FrameMaker documents to XML, you almost always need > a DTD. == Based on the "newbie's" description of what he's trying to do, I concluded that he's querying a database, and the query result is output as tagged XML. In other words, this is a database publishing application in which the query itself defines the schema, and the database management system itself inserts the proper XML tags in the delivered query output. Hence, if that is the actual case, there is no need for a separate DTD. Aa EDD would suffice. There isn't even a need for a top-level element to be included as the first element in the query output. Instead, the EDD defines the top-level element, and after the data is imported into Frame, all of the resulting content is wrapped in the EDD-defined top-level element. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Footnote Structured Frame Bug
This bug is in FM+SGML 6, and I'm curious whether it's also in later releases. I have an EDD in which an element of type Footnote (not surprisingly, the element name is also Footnote) is provided for most elements that have in their structure rule. The bug is unaffected by whether the Footnote element is included in the structure rule of those text containers, or is listed as an inclusion under those text containers. All the text container elements which allow footnotes use an element paragraph format named Body. The Footnote element can contain several types of text range elements (e.g., Emphasis). Again, it doesn't matter whether these text range elements are specified in the Footnote element's structure rule or are specified as inclusions in element Footnote. The element paragraph format for Footnote is named Footnote, which specifies a smaller font size than paragraph Body. Here's how the bug is expressed: 1. In insert a footnote element in the text of a Body paragraph. 2. The Footnote paragraph properly appears (in the smaller font size) at the bottom of the page, and I type in the content of the footnote. Everything up to now works as it should. 3. Now, in the footnote text, I select a word or phrase and use the element catalog to select a text range element (e.g., Emphasis) and wrap the selected text with that text range element. When I wrap the selected text with the text range element FrameMaker changes the paragraph format of the Footnote from Footnote to Body (the paragraph format of the text where the footnote was inserted). This anomalous result does not occur randomly--It occurs every single time. Restoring the proper formatting to the footnote text requires re-importing the document's structure rules back into itself. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
TOC Formatting Problem
--- davidaflynn wrote: > I am new to FrameMaker (6.0). Could anyone describe > how we can set / update > / create / modify styles in > > 1. a book > 2. its individual fms === In the top menu bar of FM 6.0, choose File > New. In the New dialog, you'll see that, when FrameMaker was installed on your platform, a number of templates were added to your computer in a set of folders which are listed in the New dialog. Double-click on the Outlines folder to open it, and select the template named OutlineHarvard. Observe that the name of this template now appears in the Use Template slot. Now, click the New button to open a new (empty) document which will be an exact replica of the chosen OutlineHarvard template. To explore what makes up a template, do the following: 1. Choose View > Master Pages. Observe that there are three--Left, Right and First. Note that the Left and Right master pages have 3 text frames--The running header text frame which contains a variable, the Body text frame which is empty and will contain the content you create, and a running footer text frame which also contains a variable. Note that the First master page does not contain a running header, but otherwise is the same as the Left and Right master pages. 2. Next, choose View > Reference Pages. Observe that there are 6 reference pages, each having a name. Pages 3-5 provide the information for converting the document to HTML. Page 1 contains frames that appear above footnotes, page 2 contains the specifications for generating a table of contents, and page 6 defines the paragraph tags associated with each of the 4 hierachical heading levels. 3. Next, choose View > Body Pages, and do the following: A. Choose Format > Paragraphs > Catalog. The paragraph catalog appears, and lists all of the named paragraph formats in the template. Then, choose Format > Paragraphs > Designer. In the paragraph designer you can examine all of the formatting information for each paragraph format listed in the paragraph catalog. B. Choose Format > Characters > Catalog. The character catalog appears, and lists all the named character styles in the template. Then, choose Format > Characters > Designer. In the character designer you can examine all of the formatting information for each character style l(other the default format). C. Choose Table > Table Designer. This dialog serves as both the table catalog and the formatting details for each named format. D. Choose Format > Document. This allows you to set up numbering properties, change bars, footnotes, and miscellaneous text options for your documents. E. Choose Special > Cross Reference to open the Cross Reference dialog. Then, choose Edit Format to open the Edit Cross Reference Format dialog. This dialog allows you to modify the definition and formatting of existing named cross-reference types as well as allowing you to add new named cross reference definitions. F. Choose Special > Variable. This dialog allows you to edit modify the definitions of system variables, and to create your own set of user-defined variables, each having an unique name. G. Choose Special > Marker. This dialog allows you to define your own set of special marker types. The above tour of a typical template gives you a handle on the scope of template design. Usually, it's best to begin with an existing template that's as close as possible to what you require, and then modifying it to meet your requirements. Paragraph Styles - Paragraph Designer. Once you've created a template, you can specify it each time you create a new document in FrameMaker. If, subsequently, you decide to make modifications to your template, you can update existing documents to conform to the modified template by opening both the template and the document to be updated, and choosing File > Import > Formats. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Trick For Creating Graphs in FrameMaker
Im talking about graphs where both the horizontal and/or vertical axes have a linear array of marked values, and the axis lines extend across the graphic. In other words, the background of the graphic looks like a FrameMaker table in which , consisting of rows and columns in which all columns are of equal width, and all rows are of equal height, using the minimum row height setting in the Row Format dialog. All table cells are empty. Here's the procedure: 1. Create a new document in which the right master page has a text frame of the desired width and height. and super-impose on top of that text frame a background text frame, and create the table (as described above) in that background text frame. Be sure to include an extra appropriately sized column on the left side of the table. This column should straddle all rows, and be wide enough to later label the title of the vertical axis, as well as space to put in tick-marks and numbers for each horizontal line in the table. Similarly, create a straddled row at the bottom of the table high enough to later enter the title of the horizontal axis, as well as space to put in tic-marks and numbers for each vertical line in the table. 2. When you are finished creating the empty table, send the bacground text frame to the back. 3. Go to page 1 of the new document. The table you created in step 1 appears. 4. First, you use the FrameMaker text and line-drawing tools to enter the titles, numbers and tic-marks for the harizontal and vertical axes in the the column with straddled rows, and and the row with the straddled columns3. 5. Next, use the drawing tool dwaring tools (curve, polyline, or whatever else0 to draw the graph lines. and smooth or reshape them as needed. 6. Save the 1-page FrameMaker document as a PDF with an appropriate filename. 7. In Acrobat, open the PDF produced in step 6, and use the Acrobat crop tool to crop the page to the size of the graphic image. and then re-save it. 8. Within any document where you want the graph to appear, import the PDF produced in step 7 by reference or copy, as appropriate. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Is there a change in behaviour between FM 5, 6 and 7 EDD?
Are you sure the element named Table is specified as being of type table? If element Table is a container type element, element Tgroup should be specified as the element of type table, and container element Table then produces the anchor paragraph for the table, and the text format rules you describe are setting up the format of that anchor paragraph. If the element named Table is, in fact, the table type element, then the table will be anchored to the end of the text in the container element that precedes element Table, and that's a lousy solution. It is also a common (and in my view good) practice to specify an ElementPgfFormatTag rule for each non-text-range container element, because this stops inheritance of paragraph formats from ancestor elements. Ancestor format inheritance becomes extremely messy when a container element appears in many different contexts having many different ancestor elements. When an ElementPgfFormatTag is specified for each container element, you can then use text format rules (all context or context type) to modify the base paragraph format for each element in different contexts without having to add innumerable paragraph tags in your structured template. The advantage of this approach is that the number of paragraph tags in your structured template can typically be reduced to a dozen or so base paragraph formats in which the main difference is the font (and perhaps a few other immutable properties). Consequently it is a relatively simple task to create different versions of your structured template for different types of deliverables or different customer-required changes to the base set of paragraph properties without having to change youre EDD. To further simplify the EDD, most context rules for individual container elements should reference format change lists which are grouped into titled categories at the end of the EDD. This permits a single format change list to be used to implement parts of the formatting for many different context rules in many different elements. Moreover, a complex set of formatting requirements for a particular element in a particular context can be built up from two or more referenced format change lists. --- Bodvar Bjorgvinsson wrote: > I am NOT asking for a solution. NO help needed, only > curious about the issue. > > I am working with some [legacy] documents from > another company and I > have come across something weird in the EDD: > > There is a table definition that sets the text > formats like this: > > Text format rules > In all contexts. > Basic properties > Paragraph spacing > Space below: -2.0 pt > Line spacing > Height: 3.0 pt > Default font properties > Size: 2.0 pt > > This to me looks like what you would set as a > *paragraph tag for > anchoring*, but this is actually a Table type > element. > > In the original, all text is formatted in the > "normal" way as the rest > of the document, but this is only because of one of > the peculiarities > of the legacy EDD, which is that for every text > element there is a > TextFormatRules setting of ElementPgfFormatTag: > Body, which is the > thing that overrides this in the table cells (and > the annoying setting > that I have removed from most of the elements in my > adaption of the > EDD). > > So does anyone know whether there has been mad a > change here in the > paragraph formatting of a TABLE element between FM 7 > and older? > > Bodvar Bjorgvinsson > Supervisor Publications > Air Atlanta Icelandic > Flight Support > ___ > Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Is there a change in behaviour between FM 5, 6 and 7 EDD?
If your premise is correct, namely that the formatting in element Table will be inherited by the table title and the cells within the table, it's going to be a mighty strange table, because all text will be 2.0 pt with a space below of -2.0 pt. clearly, the intent of this formatting is to create the table anchor. --- "Lynne A. Price" wrote: > Bodvar, >No change. Paragraph formatting defined in a > table element applies to > paragraphs in the table title and cells within the > table. Bodvar wrote: > There is a table definition that sets the text > formats like this: > > Text format rules > In all contexts. > Basic properties > Paragraph spacing > Space below: -2.0 pt > Line spacing > Height: 3.0 pt > Default font properties > Size: 2.0 pt Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Is there a change in behaviour between FM 5, 6 and 7 EDD?
--- Bodvar Bjorgvinsson wrote: > Thanks for the input, Dan. > I mostly agree with you about the rest, but it is > good for reassurance. :-) > > What seems to me unprofessional about the legacy EDD > is that every > element that has anything to do with text is > specifically assigned the > Paragraph Format Tag: Body. (And the EDD is not that > complex. === The effect of specifying paragraph Body in every text container is to prevent ancestor format inheritance. If any ancestor has format rules that modify paragraph Body, those format changes will also be applied to the child element unless ancestor inheritance is stopped by specifying an element paragraph format. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
I Object to sites which demand registration before exposing pricing
Yeserday, Siberlogic sent to the lists an announcement of a new CMS product that integrates FrameMaker. I was acutely interested. The details of the product seemed a bit light, but I proceeded anyway to look at the pricing, which, often, gives you a handle on the scope and breadth of a product. But, to see the pricing, I was required to fill out a registration form, which I refused to do for the obvious danger that the information I provided would be used in ways I would not countenance I got an email back from Siberlogic inviting me to complete the registration form, which means they had captured my email address. I replied by demanding that they remove my email address from their database. Siberlogic complied, and explained that they require registration because of experiences in the past with competitors. That seems pretty lame to me because, obviously, any competitor could easily disguise a pricing probe. Those of you who also object to a requirement for providing personal and job-related information before being allowed to look at product pricing might be interested in joining an effort to stop this practice. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Outsourcing
--- Anne Robotti wrote: > > Greater value? To whom? The consumer, perhaps, > I don't think the companies that are saving money by > outsourcing are > necessarily passing on the savings to the consumer. > I'd have to see some > pretty firm research on that before I'd believe it. == So, you seem to be saying that it requires no research whatsoever to "firmly" conclude that outsourcing does not resule in savings to the consumer, but you demand "firm" research to prove that it does save the consumer money. Rubbish.
Numbering Systems for Technical Service Manuals
--- "Linda G. Gallagher" wrote: > I only use that type of numbering when a client > insists on it. Typically, > those clients are engineers with content targeting > other engineers. == The complaint that prompted Ms. Gallagher's response was that multi-level numbering schemes "looked clunky," the implication being that such numbering offended the writer's esthetic sensibilities. Ms. Gallagher's response is a laughable explanation for when (or why) multi-level numbering of topics (as well as tables and graphics) might be necessary. No doubt most engineers use such numbering schemes because it is the only assured way to avoid ambiguity when you reference something. The legal profession uses such numbering schemes for the same reason. Then there are the military and the Air Trasport Association (ATA) (among many others) which also require such numbering schemes because a number provides a way to double-check that that the user is following the correct procedure. Someone else pointed out (correctly) that the concept of a content management system (CMS) also imposes a requirement for such numbering schemes in order to facilitate the retrieval from a CMS of the particular information needed by a user. To implement this, the value of each level of a multi-level number appears in a separate attribute (ala ATA DTDs, where the attributes are named Chapter, Section, Subject, Page Block, Task, and Subtask). Inspection Work Cards in the ATA system identify the applicable number(s) associated with each task or subtask identified on an individual work card. If the inspection results in the need for some corrective action, the multi-level task number specified on the work card is used to retrieve that task from the CMS. The user can then verify that the number on the delivered content matches the number specified on the work card for that task. This process of number re-verification is an essential ingredient of a zero-tolerance maintenance environment. Producing technical manuals of any substantial size and scope demands an appropriate multi-level numbering scheme, not just for titled text, but also for titled tables and graphics. Even relatively simple on-line help docs should have some sort of numbering scheme. Typically, users who can't figure out something from the on-line help will resort to a customer help line or in-house expert. If the user can give the help specialist the number of the particular on-line help content where the user is stuck, ambiguity is eliminated, a successful resolution of the problem is more likely, and the time to arrive at the correct solution is likely to be minimized. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Numbering Systems for Technical Service Manuals
--- "Linda G. Gallagher" wrote: > I don't think it was necessary to single out my > response and call what I > said laughable. Your unqualified statement that the only people left who use such numbering schemes are engineers communicating with other engineers is what made it laughable, because your statement itself was insulting to the many technical disciplines where such numbering schemes are considered essential. Clearly, many types of technical documentation other than engineer-to-engineer documents are enhanced by using a rational numbering scheme, and I cited many examples in my initial reply. One could infer that your conclusion derives from the fact that your millieu is restricted to on-line help--the realm where shovelware reigns supreme. In general, that regime only works when the product being supported is some relatively simple piece of software, and on-line help is only useful to beginners, who would probably be better off if they could print a complete manual that actually looks like a technical manual when it is printed. The general assumption of on-line help developers seems to be that links are a substitute for a rational numbering scheme. You may be surprised to learn that there are vast realms in which selected technical manual content must be printed out in order to successfully carry out tasks, and thus links no longer work. in those cases, a rational numbering scheme in the printed portion replaces links as the method for finding (and printing) referenced content. That's an unnecessary insult. == Your statement itself insulted those who produce technical content that is far superior to the typical on-line help shovelware. == > As for this particular issue, I know of few writers > and companies who advocate using numbered sections as you suggest. == How many companies or writers do you know who work outside the realm of on-line help shovelware? Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Numbering Systems for Technical Service Manuals
--- Anne Robotti wrote: > Is this a private email from Linda that you posted > to the list? How > completely rude. = My mistake, and I apologize to Linda. The Framer's list, unlike some others, identifies the sender's name, not the list's name as the sender. My default email setup only identifies the sender in the From line, thus, when I hit reply, only the sender's name appears in the To line. Since the thread originated on the Framers list, I presumptively added the list name on the cc line in my reply. I usually check first to see if that is proper, but this time I failed to do so. I'll be more careful in the future. My bad. Nevertheless, this issue about numbering of titled headings, tables and graphics seems to come up frequently. It's a valid issue, and it deserves more discussion on the list. And by the way, I do not apologize for describing most on-line help as shovelware. If that is offensive to some, so be it. The FrameMaker on-line help in versions 4 and earlier was far superior to the shovelware that replaced it in later versions. That, coupled with the much less complete printed manual, makes life more difficult for newbies. Many of the FrameMaker issues which come up over and over again on this list should be answered by declaring RTFM. Unfortuantely, that recommendation no longer applies in many cases. The same goes for the Acrobat manual. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Numbering Systems for Technical Service Manuals
--- Steve Rickaby wrote: > Surely the answer here is 'horses for courses'? > There are many areas where numbering is either > appropriate or essential (engineering manuals,legal > documents, political documents, medical documents, > repair manuals, ya-de-yah), and others where it is > not. Legal is one special case: due to its density, > every *paragraph* is often numbered. == The essence of the reason for numbering in the document types I (and you) cited is multi-fold: 1. It eliminates ambiguity 2. It facilitates rapid access 3. It minimizes mistakes, and speeds up access, particularly when you are working off-line with a paper copy, in which case hyperlinks are unavailable. When you reference something by its title instead of by an unique number, it creates two problems: (a) How do you find it in a large document, whereas referencing by a number tells you exactly where it's located, and (b) technical manualsoften have many instances of very similar titles, and users are more likely to go to the wrong one. For these reasons, I contend that that nearly all technical manuals fall into the same category as engineering documents, legal documents, medical documents, etc., because all of those types share the urgent necessity of avoiding mistakes caused by looking up the wrong reference. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Hypertext Link Strangeness
wrote: > I've got one for you I am making hypertext links > active in the PDF > output by using a "message URL" hypertext marker. I > use a character tag > to identify the text to include in the link. This > has worked fine for me > in the past in unstructured docs. > > I have recently noticed that in my structured doc > the link is not > working the way I expect. In some cases I get only a > part of the address > in the link or no active link at all. = My experience with converting structured docs with hyperlinks to PDF is that the links don't work if you insert the gotolink (or message URL marker) at the before the first text character in a text line. Instead, insert the marker at the end of the highlighted text (i.e., just before the end bracket ]) delineating the end of the character tag. The same goes for newlink markers. Namely, never insert a newlink marker before the first text character in text line. I use EDD-defined structure rules to define the link components, as follows: = GoToExt (a link to another FM document or URL) The structure rule for this element consists of the names of one or more marker-type elements: (FmGotlink | MailLink | whatever else is needed) Each element specified in the structure rule is defined as being a marker of a particular type. Element GotoExt is defined as a text-range element and the format rule specifies colored text. == GoToint (a link to a newlink marker within the same document). The structure rule for this element is: (FmGotolink | whatever else is needed) Each element specified in the structure rule is defined as being a marker of a particular type. = Element NewLink (an element of type newlink marker, which specifies the unique name of a hypertext node within a FrameMaker document. Obviously, no colored text is required in this case. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Columns in middle of chapter
--- "Lisa M. Balbes, Ph.D." wrote: > My client wants one section of a particular chapter > to be in columns, instead of the full page width text of the rest of the chapter. This > section will extend over several pages, and will > probably have things added and deleted as we continue editing the document. They want the > columns to flow like a newspaper - filling both > columns on one page before moving on to the next. There is a viable way to do this in FrameMaker. First, your Left and Right master pages must both be converted from a single-column page layout to a 2-column layout. Second, to make it work, you must have two sets of paragraph formats which at differ in a single setting within the Pagination pane of the Paragraph Designer, namely: 1. the paragraph formats for the ordinary single-column content are all set to "Across All Columns":, 2. The paragraph formats for the 2-column content are set to " In Column". Take note also that you'll need to define 1- and 2-column paragraph formats for graphic and table anchors if the 2-column text contains graphics or tables. With this setup: Each time you switch from a 1-column paragraph style to a 2- column paragraph style, lines of 2-column text are produced. Then, switching back to a 1-column paragraph style will cause the lines of 2-column text above it to be balanced out within the two columns, and the text below will resume the 1-column layout You can switch back and forth between 1- and 2-column text multiple times within a single page, thus you can begin and end the 2-column text anywhere within the same page, or you can start the 2-column text anywhere on a beginning page, and end the 2-column text anywhere on a succeeding page. This solution works best when: A. Single-column text appears at the top of a page, and either fills the page or is followed by 2-column text which fills the rest of the page, or B. The 2-column text appears at the top of a page, and either fills the page, or is followed by 1-column text which fills the rest of the page. If, as you state, there are likely to be subsequent edits which cause both the 1-column text and the 2-column text to shrink or grow in size, you may find it necessary to manually force page breaks more often that usual in order to keep the 2-column text coherent. This, however, should not be much of a problem if all the 2-column text is in one solid, multi-page block that is preceded and/or followed by solid blocks of single-column text. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
general publication quiestion
--- Charles Beck wrote: > Maybe I'm missing something, and then again, maybe > I'm not. I too have > always considered it a strange paradox when I see > the words "This page > intentionally left blank." But there is no need to > use it. == Mis-printed technical documentation has real-world consequences. A printer device can misfeed two or more sheets at once, inserting completely blank double-sided sheets, or, even worse, it may print one side properly, but mis-feed two or more sheets at once on the second pass to produce the backside pages, which results in an incorrect blank backside for one or more pages. The fact that, more and more, technical manuals are being delivered as computer files, not professionally printed and bound paper documents, increases the likelihood of printing errors when users print out all or part of a manual, and thus unambiguous identification of blank pages becomes even more important. In designing technical documentation, technical writers have an obligation to consider the impact of such things as printing and binding errors, particularly when such errors could have life-and-death consequences. How, then, do you prevent such consequences. There's only one way, and that is for users to be trained that any completely blank page or page side constitutes an error that must be corrected. Consequently, every single page must have text. The logical solution for an intentionally blank page is to place the statement "THIS PAGE INTENTIONALLY LEFT BLANK" in the center (not the edges, which may be incorrectly trimmed or mis-printed) of the page.
general publication quiestion
Your "snip" below deleted from my original post the main reason I gave for why intentionally blank pages should be unambiguously labeled. The snipped part was: "The fact that, more and more, technical manuals are being delivered as computer files, not professionally printed and bound paper documents, increases the likelihood of printing errors when users print out all or part of a manual, and thus unambiguous identification of blank pages becomes even more important." "In designing technical documentation, technical writers have an obligation to consider the impact of such things as printing and binding errors, particularly when such errors could have life-and-death consequences." = As the military has learned, some readers of technical documentation are not at the bright end of the mental continuum. Unless blank pages are unambiguously labeled so that even a low-wattage brain will get the message, the military has learned that some very troubling outcomes occur. The US military conducts, as a matter of course, thorough reviews of snafus to identify the causes of the foulups. Instances where poorly designed or written tech manuals contributed to a snafu are extremely common, and corrective actions are often recommended, which result in changes in MIL specs, and/or changes in the validation and verification process for military tech manuals. The standardization on the "THIS PAGE INTENTIONALLY LEFT BLANK" solution was found to be the least ambiguous way to identify blank pages, because it allows a simple training mantra, namely: "If you find a blank page in a manual which does not contain the above statement, something is probably wrong. Stop what you are doing, and seek advice from your superior." The fact is that the US military is the only true laboratory where technical documentation is subjected to extensive post-publication review to determine its effectiveness in the real world. Findings resulting from analyses of actual foul-ups lead to continuing improvements in tech manual instructions. Those who write manuals for non-military applications ought to also take advantage of that laboratory. --- "Combs, Richard" wrote: > Daniel Emory wrote: > > > --- Charles Beck wrote: > > > Maybe I'm missing something, and then again, > maybe I'm not. > > I too have > > > always considered it a strange paradox when I > see the words > > "This page > > > intentionally left blank." But there is no need > to use it. > > == > > Mis-printed technical documentation has real-world > > > consequences. A printer device can misfeed two or > more sheets > > at once, inserting completely blank double-sided > sheets, or, > > even worse, it may print one side properly, but > mis-feed two > > or more sheets at once on the second pass to > produce the > > backside pages, which results in an incorrect > blank backside > > for one or more pages. > > > How, then, do you prevent such consequences. > There's only one > > way, and that is for users to be trained that any > completely > > blank page or page side constitutes an error that > must be > > corrected. Consequently, every single page must > have text. > > The logical solution for an intentionally blank > page is to > > place the statement "THIS PAGE INTENTIONALLY LEFT > BLANK" in > > the center (not the edges, which may be > incorrectly trimmed or > > mis-printed) of the page. > > All this concern over "completely blank" pages > strikes me as odd. But > then, I read Charles Beck's explanation of *why* > there's no need -- the > part about *headers* and *footers* that's > conveniently snipped above. > > And "only one way"? This is beginning to sound more > like a religion than > techwriting advice. > > In the past, I've used a level-1 heading that reads > "Notes" at the top > of the extra page (below the header's ruling line) > -- does that lack the > rigorous user training component that the statement > "THIS PAGE > INTENTIONALLY LEFT BLANK" seems to possess? > > What about this "in the center" bit? Does it have to > be horizontally > centered too, or can it align left in the text > column? For that matter, > if you have wider inside than outside margins, > should it be centered on > the page or in the column? > > For those of us who like the golden ratio, would it > be beyond the pale > to place the statement 1.62 times as far from the > bottom of the page as > from the top? I think that would be more > aesthe
The Page Left Intentionally Blank
--- Shmuel Wolfson wrote: > I always felt that "This Page Intentionally Left > Blank" sounds a bit > weird. Why would you intentionally leave a page > blank? I vote to change > it to "This Page Left Blank for Double-sided > Printing." What about the case where the manual is only delivered as a computer file, and the user prints out all or part of the double-sided manual as a single-sided document on local printer? Now a typical dimwit reader will become confused about what it means. The addition of "For Double-Sided Printing" adds an unnecessary confusion factor which adds nothing to the intended meaning, regardless of whether the manual is printed single- or double-sided.
OT: MIL specs (was RE: general publication quiestion)
Certainly I don't advocate the use of MIL specs for preparing commercial manuals. I do know, however, that most tech writers who produce manuals for commercial products remain blissfully unaware of the problems caused by their outputs. Unlike typical users of commercial products, most users of MIL=SPEC manuals have received thorough training on the systems they will maintain/operate, including classroom exposure to the manuals they will use after they graduate. Nevertheless, they frequently foul up, and sometimes it's because the manual is poorly written or deficient in other ways. Unlike the commercial world, the military reacts by investigating manual-caused snafus, and taking corrective action, which may include modification of both the training and the manuals. All I was trying to say is that tech writers in the non-military world should take advantage of remedial measures taken by the military to minimize foul-ups. One such remedial measure was to require blank pages to have the infamous "THIS PAGE LEFT INTENTIONALLY BLANK" appear in the middle of each empty page. The absence of this statement on a blank page assures that the reader knows something is missing. The military learned the necessity of this measure the hard way, yet the general ridicule this subject receives each time it arises is equivalent to ridiculint the fact that car manufacturers discovered it was wise to prevent idiots from starting their automobile while the shift lever is set to reverse. --- "Combs, Richard" wrote: > Daniel Emory wrote: > > > The fact is that the US military is the only true > laboratory > > where technical documentation is subjected to > extensive > > post-publication review to determine its > effectiveness in the > > real world. Findings resulting from analyses of > actual > > foul-ups lead to continuing improvements in tech > manual > > instructions. Those who write manuals for > non-military > > applications ought to also take advantage of that > laboratory. > > First there was "only one way." Now there's the > "only true laboratory." > I'm seeing a pattern here... > > Ever hear the (chiefly British) expression "horses > for courses"? :-) > > Don't get me wrong -- I'm a huge fan of the US > military (especially when > they're killing Islamofascists). I donate to > Soldier's Angels, the USO, > VFW, PVA, ... > > But if some edict were to declare that henceforth > all technical > documentation everywhere must be done to MIL specs, > I suspect I'd change > professions or retire. At the least, I'd have to go > on anti-depressants. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Converting unstructured to structured FrameMaker
--- Pat Christenson wrote: > I have a large project coming up that involves > converting unstructured > FrameMaker docs to structured FrameMaker (7.1 on > Windows). Does anyone > know of any helpful websites or documentation to get > through this as > quickly and efficiently as possible? First, you have to closely examine the target document set. Were they all created with the same version of the same template. If not, the conversion cost is likely to escalate exponentially as a function of the amount of difference in the templates. Second, did the authors adhere to the template, with minimal format overrides, and consistent application of the designated format for each level of structure. If not, conversion cost will go way up. Third, are there major instances where unstructured tags are used at many different levels of structure. This will result in a one-to-many relationship for a given tag (i.e., the same tag must be converted to more than one structural element). If this is the case, conversion is much more difficult and costly. If the document set passes these tests, it is unlikely that the structure inferrable from the tags will closely match the structure defined by the target EDD/DTD. In that case, it is advisable to perform the conversion table operation by creating an "interim" EDD which closely matches the tagging of the unstructured docs, with element names matching the corresponding tags in the target EDD/DTD. Once the conversion using the "interim" EDD is completed, you import into those converted documents the FrameMaker template file for the target EDD. The resulting document will now be full of structure errors which you correct (mainly) by wrapping elements of the "interim" EDD in higher-level elements defined in the target EDD.
Why have list AND step paragraph tags
--- Eli Har-Even wrote: > Our FrameMaker templates have two sets of numbered > lists, one set for steps (step1, step2, step3) and another for lists (and list1, list2, list3). > Visually, steps and lists look different, but in > practice, authors use them interchangeably. I'm considering simplifying the template by eliminating one > of the sets of tags. Does anyone have a use-case > where having two sets of numbered lists has been useful? Is there any reason for having both sets? = Obviiously, if the writers use them interchangeably, there is no reason to have both. Generally, procedural steps are more vital than ordinary lists, and thus require closer editorial and technical attention. Using different para names for steps and ordinary lists might make it easier to locate, manage and more closely review procedures. I assume the reason you have 3 different para tags for both steps and lists is so you can have indented substeps and sub-items, otherwise I don't know why you would have 3 different paratags for steps and lists.
FrameMaker 8 Automatic Letter Spacing Broken?
--- Mike Wickham wrote: > >> Justification and Automatic Letter Spacing used > to work together. Now, > >> only one or the other works. Is anyone else > seeing this? > > > Yes, I can verify this behavior with FrameMaker 8 > on Windows XP. > > Dang. I hope Adobe fixes this soon. The feature is > important enough to me > that I'm going to have to hold off on buying the FM8 > upgrade until then. This bug would seem to indicate that there's still lots of spaghettic code remaining in FM8. Given the short time between Beta testing and the release date, it seems likely that, even if this bug had been discovered during Beta testing, it would not have been fixed in the released version. Let us hope this bug is not an omen that FM8 will repeat the FM5.5 fisaco (the first full release produced by Adobe). That version had more bugs than a termite-riddled house.
FrameMaker8 Automatic Letter Spacing Broken
--- Mike Wickham wrote: > >> Justification and Automatic Letter Spacing used > to work together. Now, > >> only one or the other works. Is anyone else > seeing this? > > > Yes, I can verify this behavior with FrameMaker 8 > on Windows XP. > > Dang. I hope Adobe fixes this soon. The feature is > important enough to me > that I'm going to have to hold off on buying the FM8 > upgrade until then. This bug would seem to indicate that there's still lots of spaghettic code remaining in FM8. Given the short time between Beta testing and the release date, it seems likely that, even if this bug had been discovered during Beta testing, it would not have been fixed in the released version. Let us hope this bug is not an omen that FM8 will repeat the FM5.5 fisaco (the first full release produced by Adobe). That version had more bugs than a termite-riddled house.
FrameMaker XML inDesign XML imports
UniMerge is the solution. You create a report template in FrameMaker describing how each type of database record is to be processed and formatted, save it as a MIF file, and execute it on the database output. The result is fully-formatted, ready-to print output. The rport templated can include FM markders in the report template to produce running header/footers indexes, and other goodies. I have a PDF which describes UniMerge's powerful features. --- David Creamer wrote: > > What we do here is take let's say 100 products > which include the > > image, descriptions, and all the corresponding > sizes or colors in a > > table, and export from a filemaker database and > then import into > > Frame. Frame streams all the information into the > template -- all 100 > > products -- where we then lay them out in the > template. I can then > > take each individual product and apply a straddle > here, resize a > > table there, etc. Each product is its own entity > within frame. > > If I do the exact same import into InDesign, all > 100 products become > > just one large text block and they lose their > individuality and thus > > I lose the ability to design each prouct. > > Can that individuality somehow be maintained with > ID??? Plugins > > perhaps??? > > > With InDesign, you might want to take a slightly > different approach and look > at EmSoftware.com plug-ins: InData and InCatalog. > (InCatalog can even > maintain a "live" link to your database.) > > David Creamer > I.D.E.A.S. - Results-Oriented Training > http://www.IDEAStraining.com > Adobe Certified Trainer & Expert (since 1995) > Authorized Quark Training Provider (since 1988) > Markzware, Enfocus, FileMaker Certified > > > ___ > > > You are currently subscribed to Framers as > danemory7224 at sbcglobal.net. > > Send list messages to framers at lists.frameusers.com. > > To unsubscribe send a blank email to > framers-unsubscribe at lists.frameusers.com > or visit > http://lists.frameusers.com/mailman/options/framers/danemory7224%40sbcglobal.net > > Send administrative questions to > listadmin at frameusers.com. Visit > http://www.frameusers.com/ for more resources and > info. >
Database Publishing book
--- Pat Bensky wrote: > Hello Framers, > I am thinking of writing a book about database > publishing. It would cover > publishing with InDesign and Quark (possibly > FrameMaker and Word as well) > using the following methods: > > InDesign tags > Quark tags > Xtags, Xdata > XML > RTF (perhaps) > FrameMaker tags (maybe) === I've been developing database publishing applications for clients for about 14 years. In some cases, I deliver turnkey applications to my customer. In other cases, I produce the finished output (typically annually). Your list of methods barely scratches the surface, and does seem to address only the most simple database publishing applications, which, in my experience, is rarely enough. Nor do you seem to be addressing he wide array of products/solutions which are available, as well as the extremely wide variety of applications in which database publishing can be employed effectively. Your definition of what you mean by database publishing will determine the scope of your book. The broadest definition would encompass all special solutions whose purpose is to process raw output from a database so as to deliver it in a form that is useable to both human and non-human users. In the case of delivery to human users, such solutions typically include customizeable middleware which can receive/processe/manipulate the raw database output, and makes the processed data compatible with the selected formatting/output engine (e.g., FrameMaker, Quark, Word (ugh) or InDesign). If, for example, FrameMaker is chosen as the formatting/output engine, several customizable middleware products are available, including PatternStream, Miramo and UniMerge. Such middlewar products require the development of a special application for each production operation, which may, among other things, involve evaluatiing each database record so as to select/delete/rearrange the sequence of the data fields in each record before it is delivered to FrameMaker. UniMerge (the product I use) can also specify the FrameMaker format tag to be applied to individual fields, add markers to specify fields whose content is used to produce running header/footers, specify fields which are to be included in a table of contents, insert static text above, below or within a sequence of record fields, specify that some or all fields in a record field be placed within a FrameMaker table, truncate the data in a field, add mathematical operations on rows or columns in a tabular array, and many other functions which radically alter the raw database input before delivering output to FrameMaker. Very large database publishing solutions are very complex, and can cost hundreds of thousands of dollars to develop,operate and maintain successfully. === Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Replacing Framemaker
The publication by the STC of this article demonstrates the declining relevance of that organization.
Using variables for single sourcing
--- Scott Prentice wrote: > The only way I can think of to do this without a > plugin (or > FrameScript), would be to source the files as XML or > MIF, and have some > process outside of Frame that manages these values. In my document entitled "A New Approach to Single Sourcing" (available on the microtype site under Articles by Dan Emory), I offer a solution to the problem you describe. The method is as follows: 1, On a reference page in document file (or in the document template), create a multi=row table having the following columns in left-to-right order, named as follows in a header row: * Column 1 = "Variable (Current Value)" * Columns 2 and up = the name of each deliverable requiring changes in the variable?s value. 2. In each row of column 1, you select and insert one of the variables which changes in one or more deliverables. So, double-clicking on the current value in this column opens the variable diialog.. 3. In columns 2 and up, you insert the required value (of the variable in column 1) for each deliverable. 4. If the current value of a variable in column 1 differs from the required value for a particular deliverable, you double-click on the variable in column 1 to open the variable dialog, click the Edit Definition button, type in the correct value, click the Change button, then click the Done button. Notice that the user who updates the variables doesn?t even have to know the name of each variable. All that person must determine is whether the current value of the variable (indicated in column 1) agrees with the required value for a particular deliverable (in columns 2 and up). It might be convenient to add another column to this table which specifies the correct value for the deliverable-neutral configuration of the master document. In that column, all variables would be specified to have their default values (which could be the names of the variables themselves). This approach is superior for the following reasons: A. The user does not have to know the names of the variables which are subject to change for each deliverable, which eliminates the likelihood that the tech writer will pick the wrong variable. B. This solution provides an assured, organized way to manage all variables whose values differ in different deliverables. In effect, the table itself completely defines the scope of the task, as well as the methodology used for successfully carrying out the task. C. If a single master template is used to update all files (including reference pages) in a book, the operation described in B above need be performed only in the master template, and then the updated values of the variables will be imported from the template into all files in the book. =
Reasons to Structure
No one has mentioned the potential for greatly improving writer productivity, as well as eliminating format overrides. Once authors are up to speed on using the structure view and the element catalog, they're freed from the entire formatting burden (if the EDD specifies context-based format rules). I see no reason why this productivity advantage would diminish for relatively small documents. And, unlike unstructured Frame, re-importing the EDD into a structured document with "Remove Format Overrides" turned on will eliminate every single instance in which authors overrode the EDD-specified formatting. When authors realize this step is part of the review process, they know the jig is up. -
Reasons to Structure
--- Charles Beck wrote: > Besides-with the caveat that I have not actually > experienced *enforced* structured authoring, per > s?-if you need to format a word or phrase for > emphasis or for special recognition (such as bolding > UI elements), don't you still have to tag that > content somewhere? So where is the great advantage? === Semantic tagging of a word or phrase can be implemented by wrapping it with an EDD-defined text-range element whose element name describes the semantic type. A format rule in the EDD automatically applies the correct format to it. > As I understand structured authoring (with my > admittedly limited understanding), its strengths > seem to lie more in the realm of freeing the author > from having to make specific adhoc formatting > decisions that may or (more likely) may not be > consistent. That, and enforcing certain rules about > what content is required, accepted, optional, etc. === In a properly designed EDD, there is no such thing as ad-hoc formatting. That is, Format rules define all formatting. These format rules can be based on one or more of the following: element name, element context, element attribute value(s), and format change lists referenced from within the format rules. Typically, full use of these capabilities can drastically reduce the number of paragraph and character formats required in a FrameMaker template. I could go on to describe numerous other advantages of this approach to formatting. Typically, full use of
PDF to framemaker
--- Peter Ring wrote: > Dov is of course correct in stating that PDF should > be considered a final form document format. But, > nevertheless, PDF can be used as an > input (to Frame) === Another effective way to use PDF as an input to FrameMaker is to use it to import graphs for display in FrameMaker documents. In this case, however, the graphs are first created in FrameMaker. The method is described below. Step 1. On a new FrameMaker master page, create a background frame in which you create (using FrameMaker's drawing tools) the graph's frame (i.e. the X and Y axes with labeled tickmarks (and perhaps corresponding horizontal and vertical lines), plus any additional static text. Step 2. On a body page in which the background master page from step 1 is used, employ FrameMaker's drawing tools to to overlay the background created in step 1 with the foreground graphical plots (lines, curves, wedges, etc), using different colors diferent dashed lines, etc as needed. Additional text labels might also be created in the overlay, as needed, using the drawing tools. Step 3. Save the body page created in step 2 as a 1-page PDF with an appropriate filename. Step 4. Open the PDF created in step 3 and crop it as needed to eliminate all the white space surrounding the graphic, and then re-save it as a single-page document. Step 5. At the location in a FrameMaker document where you want the graph to appear, import the PDF produced in step 4 into a graphic frame, scaling it as needed. This methodology is particularly useful when the basic graph background created in step 1 above is used multiple times to produce different graphical plots. In that case, each graph created in step 2 is saved to a separate PDF file in steps 3 and 4. And of course, the resulting PDF graphics are not restricted to use in FrameMaker. They can be used in any software product which can import PDFs. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
New to the list, and asking for help
--- Pedro Pastor wrote: > Maybe the troubles I've found come from my > inexperience developing structured applications in FM, but I cannot fully understand the aim > behind the (so called) "XML-roundtrip" editing. == Assuming that the documentation you are creating and updating/editing is accomplished by human beings, you can avoid XML-roundtripping only by having your writers create/modify tagged XML. If you expect to have any semblance of a productive authoring environment, you must "round-trip" the XML into some sort of authoring product which provides the numerous bells and whistles needed to hide XML internals from your authors. Most XML editing produces are not WYSIWYG, and thus in those editors authors see something that is not a facsimile of what human readers will see when they retrieve those documents. Structured FrameMaker is just as much an XML editor as any of the other ones. It provides an automated way to import XML instances into FrameMaker, preserving all the XML internals, and at the end of an editing session, it provides an automated way to export the work product back into fully conformant tagged XML output. The extra feature of FrameMaker is that it avoids the necessity of having to use the clunky and difficult-to-implement XML tools used to accomplish acceptable formatting and layout needed to make documents that are highly readable and effective for human users. That is, FrameMaker, in addition to being a powerul way to create documents, can also serve as a powerful print engine for delivering high-quality, eminently readable, technical documents in paper or PDF format. == > 1) I cannot understand how to clearly separate > structure from presentation in FM. If EDD contains > structure and presentation > information we are against the main principles of > SGML/XML document > design!! = Gee, the idea behind FrameMaker is to have the best of both worlds. Desktop publishing systems like FrameMaker have highly sophisticated formatting and layout capabilities. You can, however, completely ignore presentation in an EDD simply by declaring that all text will use a single paragraph style. If, on the other hand, you decide to exploit Frame"s exquisite presentation capabilities, you can export a structured Frame document to XML or SGML, and none of that formatting information gets exported, hence it in no way violates the canons of XML or SGML. The fact is that both SGML and XML provide a set of clunky, insufficient and unwieldy tools for delivering formatted output for printing or on-line display. The FrameMaker EDD offers a far more robust and elegant method for producing high-wuality presnetations. == > 2) It seems like there are two placeholders > for storing presentation information: Templates and EDD documents. This could be > redundant, I mean, the same presentation definition > data could be store > on both places. === Again you denigrate a powerful feature of Frame. The EDD specifies the names of paragraph, character and other types of formatting tags based on element context. Templates are used to specify the formatting details for each such tag. There are two advantages to this. First, you can change the formatting (e.g., fonts, sizes, etc.) without disturbing the EDD. Second, you can create multiple template versions for the same EDD, allowing you to deliver differently formatted documents which meet the requirements of different types of users or different types of documents created from the same EDD. Another feature of the EDD is format change lists, which allow certain parameters (e.g., indents, fonr size, autonumbering) of a given format tag to be modified in different structural contexts. === > 3) In addition to this, Template document > could have structure > associated with it (via importing EDD document). > Then we get just > another way of associating structure to documents, > apart from the DTD > specification!!). Wrong again. A DTD contains no formatting information. You create an EDD. Then you import that EDD into an empty FrameMaker document, and the EDD "seeds" the empty document with all the EDD's structure rules as well as all the formatting tags defined in the EDD. Then the designer defines the parameters of each EDD-defined format tag. If your production needs require different presentations for different customers or different types of documents (all created from the same EDD), You create more than one structured template for the same EDD, and design the formatting of each version of the template to meet specific formatting and layout requirements. To create a new structured document, you select the appropriate template file and apply it to a new (empty)FrameMaker file. ==
QA wants unique edition number in changed footers
--- "Andersen, Verner Engell VEA" wrote: > Have you any idea of how I can have the various > edition numbers in footer of each chapter page and > still have the possibility of importing all formats > from all files without messing things up? == This kind of dilemma can be eliminated in structured FM documents. The edition number, rev number, rev date, effectivy, and similar info can be produced by defining FrameMaker header/footer variables which pick up the current value(s) of the applicable element attributes. In mission-critical documents (aircraft maintenance manuals, for instance) the process begins with the technician picking a work card to perform a particular maintenance task on a particular aircraft (the same aircraft model can have many different configurations, even within the same airline). The work card provides all the information needed to assuredly select the correct procedural instructions from the maintenance manual (in the ATA methodology, the mechanic submits the work card number to a database, which retrieves the applicable procedure from the maintenance manual). The work card information may even allow the mechanic to examine the information in the footer of each page of the retrieved procedure to verify that the footer information (such as the page's effectivity, current revision date, page block number, etc.) agrees with what appears on the work card. All of this footer informatin in the retrieved procedure is produced from header/footer variables which pick up the current values of the corresponding element attributes when the procedure is delivered to the machanic. As you can see, this approach, employing element attributes which are converted by structured FrameMaker to header/footer variables appearing in the footer, can be used at any level of granularity, even down to individual pages.
Table formatting
> Eli, > You wrote: > >I'd like to create a table format for a note, with > one row and two columns. > >I want a line above and below the second column. > I've only managed to do > >this using custom ruling and shading, which I don't > want to use because > >custom ruling can't be stored as part of the table > format. > > > >Any ideas? === On a reference page, create a text frame and insert an empty anchor paragraph at the top. Then, create the customized table below the anchor paragraph. If the first column contains the word "Note" (or a note icon), put that in the first column. Once all that is done, you simply copy the table (including the anchor paragraph), and paste it anywhere it's needed within the document.
Structured Frame Saving XML
What, exactly, do you mean by Frame's "perversity" in line wrapping? What, exactly, are you comparing it with on the XML side? Frame's line wrapping actions are dependent upon settings in the paragraph designer, including: * Under Advanced (automatic hyphenation) * Under Basic (indents). --- Trevor Nicholls wrote: > Hi > > Our source documents are in XML and we edit in > structured Frame. I have XSL > processes running successfully on Open and Save and > I have no issues with > the validity of the XML which Frame is giving me. > However I do have an issue > with the layout. Because our XML files are managed > by a source control > system, I would like to minimize the differences > between revisions, and > Frame's apparent perversity regarding line-wrapping > in particular is making > this difficult. > > Is it following any rules at all? > Can we know what they are? > Can we change them? > > Cheers > Trevor Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
anticipating a move to Structrued Frame
--- Milan Davidovic wrote: > I'm looking for resources or advice on how to start > working in unstructured Frame in anticipation of a > move to Structured Frame. 1. In your unstructured template, create paragraph, character, table, marker and cross-reference tags whose names correspond to the releated element names in the DTD/EDD you intend to use when you switch to structured. 2. Adhere rigorously to the correct application of these tags during creation of unstructured docs. This methodology will assure that conversion of unstructured docs to structured ones will be a slam dunk. ===
anticipating a move to Structrued Frame
--- John Sgammato wrote: > But the point remains that the best way to prepare > depends greatly on what your goals and objectives > are. Just as one example, if you are not planning to > adopt topic-oriented authoring and topic-level > reuse, then spending time learning about DITA would > be a digression rather than progress toward whatever > your real objective is. > > There are many different things that can be > accomplished by the implementation and use of > structure, and it is not necessary to know a lot > about the techniques and workflows that don't relate > to your specific business need. == The trouble is "business needs tend to change. Information reuse, topic-level authoring, content management systems, the capability to deliver to a user exactly what the user needs to perform a particular task, and the addition of metadata (attributes) to further facilitate infomation management have enormous potential, and some or all of these reatures are likely to become future requirements in your companies busines model. Unstructured docs do not fit well in those future models for many reasons, and conversion of unstructured docs to structured ones is usually an onerous and unsatisfactory process. So, it makes sense to initially select (or develop)adopt a DTD/schema which is adaptable to likely (or even possible) future business requirements. Otherwise, down the line, you are likely to face an embarassing fiasco. Although there are many advantages to structure, the most compelling reason to move in that direction is that it anticipates the almost certain capability for assured information reuse, topic-level authoring, and content management. Therefore, it makes sense to to initially select a DTD/schema whose design facilitates future possibilities. == Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Version control of FM documents/books
--- Radha Padmanabhan wrote: > I wish to know whether we can use CVS for version > control of FM files/books and how the path > sensitivity of FM /size of books will effect this. > Or what is the best way to ensure version control of > FM docs/books? === It depends, for instance, on what you're trying to do, and the level of version control you're trying to achieve. If your documents are structured, you could use a version attribute to specify the applicable version(s) at the topic level, where each version of the topic is stored separately. For topics applicable to all versions, the version attribute would be set to "All". If a topic is applicable to two or more versions (but not all), each applicable version number would be listed in the version attribute. This approach would allow you to assemble any instance of a complete structured document by specifying the applicable topic version number(s) to be included in that instance of the document. If none of the versions of a given topic are applicable to a particular instance of the entire document, it would be dropped from that instance. Obviously, this approach would require one or more additional attributes for each topic for the purpose of specifying the sequencing of the topics within an assembled document instance. The other advantage of this approach is that it would permit users (as well as authors) to individually retrieve an applicable version of any topic by simply specifying the applicable version number of the topic of interest. == Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
[FrameSGML] Format Change Lists and Removing Structure
--- Rick Quatro wrote: > have a document where the EDD uses format change > lists for its formatting. > As a result there is a bare bones paragraph catalog, > with each paragraph > tagged as *Body. When I remove the structure from > the document, the > paragraph catalog now has a bunch of new formats, > and each paragraph in the > document is tagged with one of the new formats. I am > curious if this > behavior is documented and how FrameMaker derives > the paragraph format > names. Thanks. == Each format change list has an unique tagname in the EDD. That would be the most logical means of naming the paragraphs when structure is removed. Often, however multiple format change lists are applied to a single paragraph element, which would make for very long paragraph names in the unstructured version. == > > Rick Quatro > Carmen Publishing > 585-659-8267 > www.frameexpert.com > > Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Display of variable content in Structured FM
--- "Nantel, Elise" wrote: > I'm working with Structured FM 7.0 on Windows XP. > I use a lot of variables in my manuals, typically > for product lines and product names. Sometimes after > I generate a structured book, the variable content > > appears in Times New Roman instead of Verdana. It's > really weird because it doesn't occur all the times > or on all variables. It happens also in text insets. = Elise: The most likely cause is that the text which precedes the variable insertion point is not in the Verdana font. The assured way of fixing it is to do the following: 1. Add a character format named Verdana in which you specify the font as Verdana, and the size as "As Is." 2. Open the Variable dialog, select, select a user variable, and click Edit Definition to open the Edit User Variable dialog. 3. Observe that the the new Verdana character format now appears in the list of character formats. 4. Presumably, the definition slot now contains nothing but the value of the user variable. Let's assume that the current definition is "Blah." 5. Change the variable definition as follows: Blah If this fails to correct the problem, then you have identified another bug in Frame 7.0. == Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Productivity Gains from Structured Authoring
--- John Sgammato wrote: > I am thinking of something along the lines of output > pages per writer. I appreciate any help. === Using an ROI estimate to justify changing over to a structured approach is definitely the right way to go. But coming up with a number is complex. The fundamental purpose of structure is to greatly improve the management of your legacy documents, as well as improving the productivy of writers creating new content. Although output pages per writer (in the case where completely new content is being created) definitely shows gains in productivity (after writers have become familiarized with structured authoring) it's only part of the ROI number. Here are some other, equally important, factors needed to come up with a realistic ROI: * The structure view, the element catalog and metadata (attributes) provide powerful new tools for systematically managing information. For instance, you can quickly locate chunks of information needing updates, as well as facilitating information re-use, using more systematic Find or Find/Change operations. For instance, you can use Find to locate all instances of a particular attribute value within all instances of a particular element name. * By reimporting a document's EDD into itself with Remove Format Overrides turned on, all format overrides of the EDD-specified formats are removed. This capability eliminates any necessity for editors to tediiously find and fix such overrides. Also, both authors and edictors can quickly use the Validate command to find and correct all anomalies in the structure. * A validated structured document with all illegal format overrides removed assures that conversions of FrameMaker structured document to other output forms can be accomplished successfully. * The ultimate ROI value is the certainty that, at some future date, you can successfully store your legacy documents in a content management system (CMS), which, I believe, will become the gold standard even for small companies. If you continue to produce unstructured documents, you assuredly will incur huge conversion costs, and thus an estimate of what that cost will be should legitimately should be included in the ROI.
Double-spacing a PDF output doc from a structured Frame book
--- Bob Williams wrote: > Wondering HOW to simply double-space my PDF output > doc (from a structured > Frame book) - so that our writers can more easily > make mark ups on the > hardcopy. They write - we production wonks put their > stuff into the frame > books. (We like it this way - less chances for them > to screw up the frame > files.) 1. Save your structured template under a different name. Lts call it DblSpace. 2. In the DblSpace version of your template, modify all Para formats to specify double space, ;eaving everything else the same, and save it. 3. Open the file)s) you want to convert to doublespace, select File>Import Formats to open the Import Formats dialog 4. Spcify the DblSpace file in the Import from Document slot. 5. In the Import Formats dialog, uncheck everything but Paragraph formats, and execute the import action. 5. In the Import Formats dialog uncheck everything bu Paragraph formats
Nested ul and ol elements
--- Rick Quatro wrote: > I need help with text formatting rules in an EDD. > Basically, I am allowing > nesting of ol and ul elements. I need rules that > will allow a particular > format to be called, depending on the nesting level. > Here is an example of > "flat" structure. The text in the element indicates > the paragraph format > used. > > > bullet1 > > > > number1 > > > For nested ul elements, it is no problem. In theory, > I can do the same thing > with ol elements (although in practice I don't). > > > bullet1 > > bullet2 > > bullet3 > > bullet4 > > > > > > What I want to be able to do is this > > > bullet1 > > number2 > > bullet3 > > number4 > > > > > > or this > > > number1 > > bullet2 > > bullet3 > > number4 > > > > > > or any combination of nested ol and ul elements. I > am having trouble > devising the correct text formatting rules. Any help > or pointers would be > appreciated. Thanks. = Rick: Certainly, the easiest way to deal with this is to add attributes: A Level attribute which specifies the indent level, a Symbols attribute which specifies a symbol (e.g., a bullet), and a Number attribute that specifies a number, where the default value for the symbol and number attributes should be "None". So, if both the Symbol and Number attributes are set to None, there is no number or symbols prefix. But, if either of these attributes is set to a non-None value, that value whall become the prefix). Regardless of the level, specify an element paragraph format which does not specify either the indent level of the number or bullet type. Below, I describe the prefix and format rules Prefix Rules for the OL or UL element (same set of prefix rules for both elements) 1 If context is: [Number != "Off"] . Else if [Symbol != "Off"]
FW: Adobe CEO interview
--- mcarr at allette.com.au wrote: > As far as a device that you can comfortably and > safely use in the tub is > concerned, I don't think that paper will be the > delivery method of the > future. It?s estimated that 40% of the US adult population is non-literate, which means they don?t read books or newspapers. This has been accompanied by a rapid decline in the ability of college students to write a half-way decent paragraph in English. The California State College system, the largest in the nation, takes almost any applicant who got through high-school degree with half-way decent grades. But about 40% of its first year students are not capable of doing college-level work, and thus their first year is dominated by remedial classes in English, Math and other subjects they should have mastered in high school. These declines all coincide with the growth of the internet, and the shift from obtaining knowledge from paper books to learning from feeble snippets of on-line text. The blogosphere, dominated by those who are at least competent in the English language, consists mainly of opinions unsupported by any factual basis. When you read tomes from the 1990?s extolling the promise of hypertext to change the way people think and use information, (I recommend the ?Hypertext/Hypermedia Handbook by Berk and Devlin), you begin to realize that it?s promise was still-born. The hypertext pioneers envisioned a rich panoply of link types that would create hypertexts which were true ?searchable mazes? Frame Technology, beginning in FrameMaker 4, added a rich variety of hypertext link types which would have realized that original vision. When Adobe took over FrameMaker, it could have carried out that vision by implementing all of the FrameMaker link types in PDF. It failed to do so. And so, the HTML standard, with only the most primitive hypertext link type, became the standard. There was some hope that the XML standard would have rich linking capabilities. It added a few additional link types, but nowhere near enough to realize the original promise of hypertext. The result is that most online help documents are shovelware. I wrote an article about that, ?Thoughts About On-Line Help?, about 6 years ago. It?s still available at: http://www.microtype.com/resources/articles/Oldocs_DE.pdf Although I would probably add some additional concepts and ideas if I wrote that article today, I still stand by most of what?s stated there. In particular, I stand by my statements in that article about the many advantages of paper books (or PDFs which faithfully replicate the format and layout of well-designed paper books). Getting back to what I state in the first two paragraphs above, I maintain that the ability to acquire in-depth knowledge of a subject is a discipline which is difficult to master. And I have no doubt that well-written, well-organized paper books, particularly on difficult subjects, will continue to be the best way to acquire real, in-depth knowledge of a subject, and subsequently serve its owner as a valuable reference source. If the internet (and other vehicles of on-line content) continues to serve mainly to encourage an undiscipplined pseudo-approach to real learning, it will remain a major cause of rising non-literacy.
First Time FrameMaker User
--- Mark Lawrence wrote: > My job involves producing 40 page reports in > Microsoft Word. These > reports are nearly identical. I use the mailmerge > feature in Word to > import variables such as the date of the report, the > name of the product > on which the report is based, the final score that > the product achieved > and so on. These are inserted at the relevant > points in the text using > mailmerge. FrameMaker has no built-in capability comparable to mailmerge. You don't describe what the source is of the mailmege data. If the source is some kind of database, there are companion products (such as UniMerge) which do work with FrameMaker, and these combinations are far more powerful than mailmerge. == Tables and graphs from an Excel > spreadsheet are are then > copied and pasted into the report manually. Do you receive the data in Excel, or do you take raw data and convert it to a spreadsheet? Either way, there are probably much better ways to get it into a form that will work with FrameMaker/UniMerge. I have a PDF (about 6 pages) which describes the capabilities of the FrameMaker/Unimerge combination. An alternaitve approach (although in same ways less adaptable than UniMerge) would be to take the raw data you receive for each report and convert it into an XML instance, and use structured FrameMaker to process each XML instance. This would require that the raw data for each product be reducible to a single XML structure which is replicated in a FrameMaker EDD that specifies not only the structure, but also all the information needed to format the information in FrameMaker. == What I conclude is that your present methodology using Word is that most of your time using your present methodology is on the Word sids. A UniMerge or XML solution would shift most of your work to a one-time development or a UniMerge or XML solution which produces a ready-to-print FrameMaker output with virtually no tweaking. If you are interested, I have a 6-page PDF which describes the FrameMaker/Unimerge solution. I hope this helps your decision-making. I have no doubt that either a UniMerge or XML solution would be far superior to your present methodology, and would indulge your desire for perfection. =
Help decoding Running H/F variables with attibutes
> At 10:28 -0400 24/5/07, Rick Quatro wrote: > >I am trying to figure out how attribute-based > Running H/F variables work. Here is are examples of > a couple in a document I have: > > > ><$attribute[Booktitle:book]> > ><$attribute[Revision:book]> = I may be missing something here, but if the "book" element only appears in a book file, and the same attribute is not repeated in the top-most element of the individual book components (e.g., chapters), I don't see how it is possible for FrameMaker to properly produce a running header-footer (in the book file's individual structured component files) which reflects the value of an attribute which exists only in the separate book file. And, under no cicumstnaces could that book file attribute be used to produce a running header-footer in unstructured front and back matter (e.g., tables of contents, indexes, etc.) included as components of the book file. The same compopnent file could, for instance, be included in several different book files. How, then could that chapter file when it is opened separately, know which book file it should use to produce the correct attribute value to select for producing the running header/footer containing the correct book title? Even if the chapter file appears in only one book file, how, if you separately open an individual chapter file (without opening it from within the book file) could that chapter file obtain the applicable attribute value from the unopened book file? And, if the book file contains unstructured front and back matter, certainly those unstructured files cannot produce a running header/footer derived from an attribute in the book file. These realities lead me to conclude that individual component files within a book file cnnnot inherit attribute values which exist only within a book file. That is, book components (such as structured chapters) can only produce attribute-derived running hader/footers from attributes of elements which exist within the component file, not from attributes which exist onely within a book file. It seems to me therefore, that the solution is one of the following: 1. Repeat the book-title attribute in the top-most element of each structured component file within the book file, and, if such a component file appears in more than one book file, change the attribute value in each component file each time the book title changes. OR 2. Simply create an ordinary running header/footer in each book file component which specifies the current title of the book being generated. That solution will work for both structured and unstructured components within a book file.
Help decoding Running H/F variables with attibutes
As I understand what you are stating, each book component will store the value of the book file title attribute value which existed the last time the generate/update action was taken on the book file. Thus, if the value of the attribute in the book file is changed but the generate/update action is not executed, the component files within the book will retain the book title which existed the last time the book file was updated. Furthermore, using the solution you describe, each time you change the book title in the book file, you must convert each individual book component file to MIF and "fish out" the current attribute value in order to produce the desired running header or footer. To make this work, therefore, each time the book file attribute is changed, you must always execute the generate update action on the book file, convert each book component file to MIF, fish out the current value of the book title attribute in each book component file, and use it to produce the correct header or footer text, and then reopen it as an ordinary FrameMaker file. That, it seems to me, could be an onerous and error-prone task, even if you use FrameScript. This method also implies that access to all the individual book component files must be blocked each time the book file attribute value is changed, and each component file must remain blocked until the generate/update action on the book file is executed, and the fishing expedition to replace the old book title is repeated in all the component files. It seems to me to be far simmpler to repeat the book title attribute in the topmost element of each component file, and update the attribute value in each component file when the attribute value in the book file is changed, which is much easier (and perhaps quicker and more reliable) than the method you are proposing. My alternative solution to the problem becomes even more necessary when one or more component files are included in more than one book file, each having a different book title. In that situation, the last book file on which the generate/update action was taken will determine the book title in the running header/footers of those component files. Thus, if an individual component file is printed separately (as is often necessary), the book title which appears in the output will often be the wrong title for the intended usage, which will be particularly confusing when different versions of the document are produced using conditional text settings to differentiate between version. === --- Rick Quatro wrote: > Thanks for your reply. I got the message below rom > Mark O'Connor offlist. > The book information is stored in each file, which > is nice because the attribute values carry over, even if you don't have the book. You have to > save the document as MIF and fish out the > information, but at least it's > there. As far as I can tell, you can't get the > information directly from the > document with FrameScript or the FDK. > - Original Message - > From: "O'CONNOR Mark" > Hi Rick, > The format is [attribute name:element name]. If > you don't specify the > element name, the first occurrence of the attribute > on the page will be > used (blank if there are no occurrences). If you > specify an element > name, it will use the first occurrence on the page: > if there are no > occurrences it will use the value of the first > parent element that uses > the attribute (and blank if no parent elements use > the attribute). > The "book" element information is contained within > the file, but > you'll need to save the file as mif to find it (look > for > "DBookElementHierarchy"). I believe that this info > is updated by the > generate/update command. > Cheers, > Mark O'C > >
Re: FrameMaker 8 Automatic Letter Spacing Broken?
--- Mike Wickham <[EMAIL PROTECTED]> wrote: > >> Justification and Automatic Letter Spacing used > to work together. Now, > >> only one or the other works. Is anyone else > seeing this? > > > Yes, I can verify this behavior with FrameMaker 8 > on Windows XP. > > Dang. I hope Adobe fixes this soon. The feature is > important enough to me > that I'm going to have to hold off on buying the FM8 > upgrade until then. This bug would seem to indicate that there's still lots of spaghettic code remaining in FM8. Given the short time between Beta testing and the release date, it seems likely that, even if this bug had been discovered during Beta testing, it would not have been fixed in the released version. Let us hope this bug is not an omen that FM8 will repeat the FM5.5 fisaco (the first full release produced by Adobe). That version had more bugs than a termite-riddled house. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: FrameMaker8 Automatic Letter Spacing Broken
--- Mike Wickham <[EMAIL PROTECTED]> wrote: > >> Justification and Automatic Letter Spacing used > to work together. Now, > >> only one or the other works. Is anyone else > seeing this? > > > Yes, I can verify this behavior with FrameMaker 8 > on Windows XP. > > Dang. I hope Adobe fixes this soon. The feature is > important enough to me > that I'm going to have to hold off on buying the FM8 > upgrade until then. This bug would seem to indicate that there's still lots of spaghettic code remaining in FM8. Given the short time between Beta testing and the release date, it seems likely that, even if this bug had been discovered during Beta testing, it would not have been fixed in the released version. Let us hope this bug is not an omen that FM8 will repeat the FM5.5 fisaco (the first full release produced by Adobe). That version had more bugs than a termite-riddled house. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: structured Frame
The fundamental issue is Return on Investment (ROI), whether the staff is one writer or 100. Here are the major cost factors that must be evaluated: A Realizable positive values of a structured solution. 1. A breakdown of the identifiable costs of the current unstructured methodology which can be reduced or eliminated by a structured approach. Most of these are reducible labor costs. 2. What needed current and future improvements in information management and productivity, not realizable under the unstructured approach, could be implemented under a structured approach. Consider not only current needs, but also predictable future needs which are only feasible under a structured approach. Estimate the long-term positive value to the enterprise of these improvements. B. Estimated negative costs of conversion to the structured approach 1. Cost of new software. 2. Cost of development to initially implement a structured approach. 3. The cost of training activities needed to implement the structured approach. C. Any additional positive and negative cost factors associated with the transition to a strucured approach. One probable positive value is that many employees outside the writing group will discover that they now have much more cost-effective ways to precisely locate and retrieve technical document information they need to perform their tasks. If you can assign realistic positive and negative numbers to the listed factors, and the positive values substantially exceed the new negative costs, you may be able to make the case for a structured approach. = ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: FrameMaker XML inDesign XML imports
UniMerge is the solution. You create a report template in FrameMaker describing how each type of database record is to be processed and formatted, save it as a MIF file, and execute it on the database output. The result is fully-formatted, ready-to print output. The rport templated can include FM markders in the report template to produce running header/footers indexes, and other goodies. I have a PDF which describes UniMerge's powerful features. --- David Creamer <[EMAIL PROTECTED]> wrote: > > What we do here is take let's say 100 products > which include the > > image, descriptions, and all the corresponding > sizes or colors in a > > table, and export from a filemaker database and > then import into > > Frame. Frame streams all the information into the > template -- all 100 > > products -- where we then lay them out in the > template. I can then > > take each individual product and apply a straddle > here, resize a > > table there, etc. Each product is its own entity > within frame. > > If I do the exact same import into InDesign, all > 100 products become > > just one large text block and they lose their > individuality and thus > > I lose the ability to design each prouct. > > Can that individuality somehow be maintained with > ID??? Plugins > > perhaps??? > > > With InDesign, you might want to take a slightly > different approach and look > at EmSoftware.com plug-ins: InData and InCatalog. > (InCatalog can even > maintain a "live" link to your database.) > > David Creamer > I.D.E.A.S. - Results-Oriented Training > http://www.IDEAStraining.com > Adobe Certified Trainer & Expert (since 1995) > Authorized Quark Training Provider (since 1988) > Markzware, Enfocus, FileMaker Certified > > > ___ > > > You are currently subscribed to Framers as > [EMAIL PROTECTED] > > Send list messages to [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > or visit > http://lists.frameusers.com/mailman/options/framers/danemory7224%40sbcglobal.net > > Send administrative questions to > [EMAIL PROTECTED] Visit > http://www.frameusers.com/ for more resources and > info. > ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Registering a new FrameMaker license
I recall recent posts on this subject. Specifically about buying an old version of frame from Ebay, and then registering it with adobe so as to get the upgrade price for the latest version. Apparently, part of the problem is to be sure the copy is not already registered to someone else. How can I be assured that buying the product on Ebay is eligible for registration in my name. Also, I looked aroun on the Adobe website for the subject of how to register Framemaker as the crucial step in buying an upgrade. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Best Approach to Structure
> On 12/5/05, DeFlorio, Dominick > wrote: > > > > What is the best approach to learning how to > structure Frame documents? I > > need to learn quickly how to create and implement > EDDs into many and varied, > > unstructured Frame documents. > Suggestions...links? The individual who asked for help says he wants to: "learn quickly how to create and implement EDDs into many and varied unstructured Frame documents." His initial challenge is not to learn about EDDs, it's to: 1. Analyze the the "many and varied" structures in his unstructured docs and the extent to which para and character tags can be feasibly be mapped to some coherent structural hierachy. If the paratags in the unstructured docs are not consistently applied, and/or if those docs use many different templates, each having different paratags, or if there are numerous instances of one-to-many relationships (i.e., a single paratag in different contexts must be mapped to many different elements), then the chances of success are nil. 2. Assuming that the docs successfully meet the requirements in step 1, he must next learn how to effectively use conversion tables. But to exploit the capabilities of conversion tables, the user must now visualize the hierarchical structure of the converted documents. This visualization must be constrained by the limits imposed (primarily) by the unstructured docs' paratagging scheme(s). Structure rules should then be written for each defined element that will appear in the conversion tables. Although it's desirable to do this in a rudimentary EDD, it' not absolutely necessary to do so at this point. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory
Apply Default Attribute Values
We're mainly talking, I presume, about Choice-type attributes (Name Token Groups in DTD parlance). If such an attribute is declared to be "REQUIRED", either the EDD, the DTD, or both MAY specify a default value (i.e, one of the specified values in the name-token group), in which case the absence of an actual value is interpreted by both the EDD and the DTD to mean the EDD/DTD-specified default value. In this case, it would be WRONG fo export the default value from FrameMaker, because different versions of the same DTD could conceivably specify different default values for the same attribute. Note also that, in this case, if no default value is specified for a REQUIRED attribute, an error will be reported during validation or export. The other case is that the attribute is NOT specified in the DTD as REQUIRED, and the DTD may or may not specify a default value. In that case, any default value specified in the EDD for such an attribute should NEVER be exported, because the absence of a value in that situation should dictate what takes place during XML/SGML processing of a FrameMaker document instance. That is, the XML/SGML side of the processing equation should determine what happens when such an attribute has no value. --- Rick Quatro wrote: > I am not looking to change the attribute value from > one thing to another. > Here is the scenario: when you set a default value > for attribute in the EDD, > it will initially show in the structure view as > italic. But if you > double-click on the attribute, the attribute will > show as in the > Attribute window. And, from what I can tell, when > you save the file as XML, > these default attribute values don't export. You > have to explicitly set the > value in order for them to export. You can tell when > an attribute value has > been set, because they no longer display as italic > in the structure view. > > After experimenting, I can use FrameScript to > explicitly set these default > attribute values so that they export to XML. > > But it does make me wonder: why have a "default" > value for attributes when > it doesn't seem to "register" unless you explicitly > set it? > > Rick Quatro > Carmen Publishing > 585-659-8267 > www.frameexpert.com > > > You can define a default value for an attribute, > but as far as I know the > > process of importing an EDD won't change an > attribute value from one thing > > to another. The "default" value is just the value > of the attribute if it > > has no other value applied. > > > > I guess the question is, in the statement .. "set > all attributes to > > default values when the EDD is imported" .. does > "default" refer to the > > FrameMaker concept of default (empty), or do you > mean "some actual default > > value" ? > > > > Unless I'm misunderstanding the original question, > I think you'll have to > > go with the script, Rick. > > > > ...scott > > > > Scott Prentice > > Leximation, Inc. > > www.leximation.com > > +1.415.485.1892 > > > ** To unsubscribe, send a message to > majordomo at omsys.com ** > ** with "unsubscribe framers" (no quotes) in the > body. ** > Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory
Apply Default Attribute Values
--- "Lynne A. Price" wrote: > Shlomo, >Of course--having a default contradicts requiring > a value to be specified! = I stated: "If such an attribute is declared to be "REQUIRED", either the EDD, the DTD, or both MAY specify a default value (i.e, one of the specified values in the name-token group." What I was attempting to say (and not very well) was the case where the DTD specifies an atttribute to be REQUIRED, but the EDD specifies it as optional so that a default value can be specified, which I suspect may be what the originator of this thread was dealing with. Clearly, that default value would not be exported by FrameMaker, and thus an error would occur. If the attribute is specified as OPTIONAL in both the EDD and the DTD, and both the EDD and the DTD specify a default value, that value should not be exported, because the DTD should determine the default value.
Footnote Structured Frame Bug
--- "Lynne A. Price" wrote: Thank you Lynne for confirming that this bug has been propagated through all releases of structured FrameMaker. == > 1) You comment that it doesn't matter whether the > text range is defined as > an inclusion or contextual element. This is correct; > formatting is > completely independent of whether an element > structure is valid and, if > valid, how it is defined. -- Because an element of type Footnote is kind of an oddball, I thought it likely that the bug is expressed only for footnotes because the programmer overlooked something about its oddballness. So, I tested all possible variations in the way a text range could be specified to see if that made any difference. That's the customary way in which programmers try to isolate the cause of a bug. Your comment assumes that the bug couldn't possibly be caused by differences in the way valid structure is defined. My assumption was that it might, so I tested for it. so that others wouldn't have to. = > 2) You claim that you need to reapply element > definitions to restore the > desired formatting. This is not correct. You can > reformat an individual > element by changing it to itself. In your case, you > can reformat the > footnote by changing the Footnote element to a > Footnote. = Of course, the way you suggest is an option, but it assumes that the author spots each and every occurrence of the bug at the moment it is expressed, and proceeds immediately to correct it in the manner you describe. The way I suggested is the only CERTAIN way to be sure that ALL INSTANCES of the bug are corrected before saving the file. In other words, I offered the MOST PRUDENT way to assure that all instances of the bug have been corrected. === I should add that, since it is standard practice in footnotes to italicize the name of a referenced book or journal appearing in a footnote, this bug represents one more major irritant (the other being inability to produce End Notes) for those who use structured Frame to produce scholarly works. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
[FrameSGML] Getting FM auto numbers into the xml
At 09:50 AM 3/31/2006, Terry Badger wrote: >Is there a way to push the auto numbers ing >information generated in FM into the xml file? >I don't see any variables to grab and put into an > xml attribute. = What you describe is a serious incompatibility between the FrameMaker autonumbering approach and that used in SGML and XML. In the latter two, the numbering must somehow be restored by a FOSI or DSSL (in SGML) or XSLT in XML. In many types of documents ( e.g., regulatory, legal, aircraft maintenance), preservation of the original numbering is crucial. And when XML data is stored in, and retrieved from, a database or CMS, the numbering must be retained in the database so that, if you query the database to retrieve a particular numbered section by itself, the query can be successful simply by specifying its unique number, and that number must also appear in the retrieved section. In many cases the numbering scheme itself is non-sequential. That is, the number itself conveys information about the content. An example is Air Transport Association (ATA) publications, which provide a way for users to identify the information applicable to a particular task by means of the numbering system itself. All the user needs to do to retrieve the needed information or procedure from a database is to issue a query that specifies the applicable number, and the delivered content (containing only the desired information) is properly numbered Clearly, there is only one workable solution, and that is to create a set of attributes--a separate attribute for each level of the number, and, in structured FrameMaker, EDD prefix rules use those attribute values to construct the number. When a document using this method is round-tripped between FrameMaker and an XML database, all numbering is preserved. Admittedly, this means autonumbering of documents must be abandoned, which adds the burden of properly maintaing the corrrect numbering in the associated attributes. Usually, it's possible to continue to use autonumbering for numbered lists, because (usually) nothing less than the entire list can be retrieved, and thus it is easy, using XSLT, to reconstruct the sequential numbering. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
FrameMaker Evangelist
--- RJ Jacquez wrote: > Hi All, > Just wanted to introduce myself to the group and > share with you that as of Monday, I'm now the > FrameMaker Evangelist for Adobe Systems and > so I'm looking forward to contributing to this group > and being as involved and supportive as I can to > everyone who uses FrameMaker. = Hallejuah! In my recollection (which goes back well before Adobe bought FrameMaker), you are the first evangelist ever to be appointed by Adobe for FrameMaker. If Adobe's title of evangelist still means what it did in an earlier time, your job includes promoting the product both within and outside of Adobe. Both are urgently needed. Will you be based in San Jose or elsewhere? Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Technical Writing Suite From Adobe
The "Content Wrangler's" "vision" of FrameMaker?s future is fatally flawed. It would do little to improve the quality of on-line help, or increase the penetration of FrameMaker into the on-line help market. Some years back, I wrote an article entitled "Thoughts About On-Line Help", which is still available at: www.microtype.com/resources/articles/OLdocs-DE.pdf I still stand by most of the criteria and conclusions discussed in that article, and very few. if any, on-line help documents today come anywhere close to meeting those criteria. THE FUNDAMENTAL PROBLEM WITH ON-LINE HELP is that it delivers the content in HTML, XHTML or XML.This means it relies almost solely on the canonical simple cross-reference link: xlink:href="students.xml" to implement the hypertext capability. NOT GOOD ENOUGH. Although the XLink standard defines some additional link types, none of them are now implementable in FrameMaker, and few, if any, web browser or on-line help products have been updated to support those additional XLink capabilities. BY CONTRAST, FrameMaker (since the early 1990s) implements, in addition to the canonical cross-reference link, 23 robust types of hypertext links, including: GoToLink, Named Destination, Alert, Alert with Title, Go to URL (launches browser and displays the specified web page), Jump to Page Number, Jump to Previous Page, Jump to Next Page, Jump Back, Jump Back and Fit to Page, Open Document, Open Document and Fit to Page, Open Document as New, Open Document at Page Number, Pop-Up Menu, Button Matrix, Message Client (communicates with other applications and creates a link to a URL), Close Current Window, Close All Hypertext Windows, and Exit Application. Some of these link types (Alert, Alert with Title, Pop-Up Menu, Button Matrix) require part of their implementation to be accomplished on reference pages. In addition, it should be possible to use the reference page methodology to implement all of the link types defined in the XLink standard. By inserting graphic buttons with embedded hypertext commands on FrameMaker master pages, navigation bars can be easily implemented. I?ve implemented large FrameMaker hypertext documents in which such master-page navigation bars were used to provide buttons such as "Global" (clicking on this button produced a menu of links to major subject areas, plus hypertexted tables of contents, indexes and glossaries), Local (clicking on this button produces a menu of links to locations within the current subject area), Previous (jumps to the location of the previous link), and Next (goes to the next page). UNFORTUNATELY, nearly all of FrameMaker?s linking capabilities are not convertible to PDF, HTML, XHTML or XML. The only viewing software that implemented all of them was the now-defunct FrameViewer product. WHAT I PROPOSE INSTEAD is that Adobe provide a new version of FrameMaker that includes (in addition to all the existing link types) the new types specified in the XLink standard, and also provide an upgraded version of Acrobat that can, when a FrameMaker file is saved as PDF, preserve all those link types. PDF has already become a de-facto web standard because of its superior readability, bookmarks, thumbnails, and forms capabilities. Adding all of FrameMaker?s superior hyperlink capabilities to PDF would vastly expand penetration into web content and on-line help development. And FrameMaker would replace Robohelp, Winhelp and similar products as the publishing system of choice for delivering web and on-line help content as PDF. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Creating Popup menus in FrameMaker
--- "Carol J. Elkins" wrote: > Good post, Dan. However, I'm trying to visualize your > statement, "...clicking on this button produced a > menu of links to major subject areas..." The > button part I understand, the menu of links I'm > struggling with. A popup menu? If so, could you tell > me how you achieve the menu of links functionality? You asked how a popup menu is created in FrameMaker. Here?s the procedure: (steps 1 and 2 are used only if a button in a background text frame on a master page is used to open the menu. If, instead, you want to open the menu from highlighted anchor text within a body page, proceed directly to step 3). 1. On a reference page, draw a text frame. Inside that text frame draw a button, and use the drawing tool?s text button to insert, inside the button, a descriptive name for the button. 2. Inside the empty paragraph at the top of the text frame (not inside the button) insert a hypertext marker of the form: popup flowname where flowname is the name of a text flow of a text frame you are going to draw on a reference page. 3. Alternatively, you can skip steps 1 and 2, and instead insert the "popup flowname" hypertext marker into highlighted text (i.e., the hypertext anchor) within an ordinary body page. NOTE: If you are using structured FrameMaker, it might be advisable to specify the "popup flowname" marker in your structure rules, and define it as an element of type marker. 4. On a reference page (I usually create a special reference page named "Popups"), draw a text frame and assign that text frame the same flowname you specified in step 2 or 3. 5. In the first paragraph inside the text frame created in step 4, enter, on the top line, the title of the popup menu (it?ll only appear in the popup menu on Unix platforms). In the second and succeeding paragraphs within the menu, type the names of the items you want to appear on the menu. 6. Immediately following the last letter of each menu item (other than the title) added in step 5, insert the appropriate hypertext marker type (most commonly jump to named destination, but other types may also be used). The Jump to Named Destination marker has the form: gotolink destination_name where destination_name is the unique name of a newlink hypertext marker which you insert in the text of the applicable content. However, the hypertext link can also be to a popup sub-menu, in which case the menu item that refers to the submenu would be created in step 4 thru 6. However, a sub-menu cannot reference another popup menu. 7. If you used the button approach described in steps 1 and 2, copy the text frame containing the button you created, and paste it as a background text frame on a master page. 8. Once all that is accomplished, clicking on the button (or the highlighted text) will open the popup menu, and the user can then select the desired subject node from the menu.
Schema Tools
--- Jon Harvey wrote: > We would like to begin developing in structured > framemaker. My understanding is that to do so, we > need to bring in schema that FM can use to help us > structure our docs. Can anyone recommend some solid > tools for creating schema? It's either that or > write the markup by hand, > something I'd rather not do. === "Schema" is a database term. A schema describes the detailed structure of a particular database design. If your intent is to export data from structured FrameMaker into such an existing database, your EDD must replicate the schema of your database. If that's not your goal, and instead you are simply trying to create structured documents, then you may be able to ignore some of the rigors of a pre-defined schema in developing your structured application. Other external constraints/requirements, however, may impose schema-like requirements that affect the design of your EDD. It's even conceivable that the EDD you develop, when it is converted to a DTD/schema, could be used to define the schema for a new database in which you intend to store Framemaker documents broken up into their constituent structured components. Be aware that implementing a true database schema imposes certain constraints on EDD developement. For instance, the use of inclusions in the structure rules of an EDD makes documents created in accordance with an EDD incompatible with export to XML or storage in a database. Also, true schemas can impose more rigorous requirements on the permissable values of attributes.
Importing Pricing ino Frame Document
You've gotten plenty of suggestions. I assume that, presently, production of your catalog is being done in a manner that is incompatible with a full database publishing solution, otherwise the solution would be obvious. The FrameScript solution offered by Rick Quatro would seem to be the simplest and best one offered so far. But I propose two more alternate solutions: A. Strip out the "embedded" pricing, and instead create a separate pricing section in the catalog in which the products are listed in order by their part number. This new section could be easily and quickly generated from a database just before printing. B. There is a solution using UniMerge which would preserve the existing catalog structure with embedded pricing. To update the pricing, you'd perform the following steps: 1. Produce a database extract containing the following two character-delimited fields: PartNum,Price. 2. In the existing FrameMaker catalog document, replace the existing in-text price for each catalog item with the following UniMerge command: ^[IF (PartNum = 123) ^Price ^[END] where XYZ is the part number, and Price is the unit price for that part number. 3. After completing step 2, you save the modified FrameMaker catalog document in MIF format, creating a UniMerge template. 4. Finally, you execute UniMerge on that template, specifying as the data source the 2-field database extract described in step 1. This action causes UniMerge to merge the data from the database extract into a MIF file output which preserves all the formatting and content of the original MIF file, and updates the price UniMerge executes from the MS-DOS or UNIX command line. It costs about $750 on Windoze platforms. It doesn't run under the MAC OS. Ultimately, it may be possible for you to use UniMerge to generate the entire catalog, in which case you could radically reduce both your production time and production costs. I've been using UniMerge to produce catalogs, directories and other database-derived documents in FrameMaker since 1994. The user manual and other aids which come with the product are excellent. --- Scott White wrote: > Is there a way to import new prices for a 1,000-page > catalog into a > Framemaker document? > We do many large catalogs here, some with and some > without pricing, and a > potential customer wanted to know if they could > update embedded pricing just > before the files go to press. I thought I would ask > the question. > Thanks. > Frame 7 Mac OS10, Frame 7.2 Windows XP Professional. > -- > Scott White > Media Production Manager > Implentation Coordinator > AlaMark Technologies > 210-704-8239 > swhite at alamark.com > > > ___ > > > You are currently subscribed to Framers as > danemory7224 at sbcglobal.net. > > Send list messages to framers at lists.frameusers.com. > > To unsubscribe send a blank email to > framers-unsubscribe at lists.frameusers.com > or visit > http://lists.frameusers.com/mailman/options/framers/danemory7224%40sbcglobal.net > > Send administrative questions to > lisa at frameusers.com. Visit > http://www.frameusers.com/ for more resources and > info. >
Public Domain Templates for FrameMaker Docs
If your company is a member of the ATA, you can obtain the DTD for spec 100 from the ATA. Using that DTD, you can generate a FrameMaker EDD. You then add to the EDD the formatting information you require to produce structured ATA 100-compliant documents. --- Steve Cavanaugh wrote: > > Hi everyone. I'm a brand new FrameMaker user here, > and I've been hired to > produce a Component Maintenance Manual to ATA > Spec-100, to which I am also > new. EGAD! It raises the question in my mind - are > there any repositories > of public domain templates for industry standard > type documents such as Spec > 100? I'm certain that with a bit of study, I'll be > able to produce one, but > if I had one to model from, and learn from, it would > decrease the learning > curve considerably. Anyone know of such a > repository, or even where I might > find a set of stand alone templates for ATA Spec > 100? > > By the way, this looks like a very useful list - > I've already learned > several things in just the last two weeks. > > Steve Cavanaugh > > ___ > > > You are currently subscribed to Framers as > danemory7224 at sbcglobal.net. > > Send list messages to framers at lists.frameusers.com. > > To unsubscribe send a blank email to > framers-unsubscribe at lists.frameusers.com > or visit > http://lists.frameusers.com/mailman/options/framers/danemory7224%40sbcglobal.net > > Send administrative questions to > lisa at frameusers.com. Visit > http://www.frameusers.com/ for more resources and > info. > Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Searching in text insets
--- Fred Ridder wrote: > "Supposed to be" could be argued, but it certainly > is the way > things *are*. Text insets are treated as black boxes > by the > Find/Change operation. == Putting text insets in text frames (each with a different text flow name) within reference pages in the same document is one way to preserve the find/change and spell checking capability for text insets. Of course, this solution only works when the entire text inset content will fit within a single reference page. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Can an Element be a Container and a System Variable
--- Catudal & Rousseau wrote: > Can an element be a container and a system variable > at the same time? I > would like to generate the Chapter-Section-Subject > in the footer of the page from the > attributes of the subject element. === Yes, this is doable if you appropriately define a running header/footer variable to contain the applicable attribute value(s). For instance, if you define three attributes in the subject element to have three attributes identifying the chapter (chapnbr), section (sectnbr) and subject number (subjnbr), you would define an available running header-footer variable as follows: <$attribute[chapnbr:Subject] - <$attribute[sectnbr:Subject]> - <$attribute[subjnbr:Subject]> Alternatively, if you were to use a single attribute to define all three numbers (e.g, 2-3-5) in the Subject element, the definition of the running footer variable would be simplified as follows: <$attribute Note that you must follow the attribute name with a colon (:) followed by the name of the applicable element in which the attribute is contained. If there are two or more Subject elements on a page, the attribute(s) in the first element is used. If there are no Subject elements on the current page, Framemaker will use the attribute values in the last Subject element on a preceding page. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Displaying a Portion of an Attribute Value
--- Catudal & Rousseau wrote: > I would like to display a portion of an element's > REFLOC value, for example, > this element with attribute values to be displayed Wiring Manual Chapter 20 so I would like to display the numerical value of the REFLOC attribute with a prefix. = I take it that the REFEXT attribute is intended to produce a hypertexted link to Chapter 20 of the wiring diagram manual, or something like that, and the sole piece of the REFEXT attribute you wish to extract is the number 20, and then prefix that number with the words "Wiring Diagram Chapter". This would require that each REFLOC attribute be processed to find and delete the string: , and replace that string with "Wiring Manual Chapter" followed by the remaining part of the attribute, which is the chapter number. Certainly, this cannot be done using FrameMaker read/write rules. So, you'd have to develop an application using the FDK or FrameScript (or something similar). Presumably, you'd have to signify, in some unique manner, the location within the text where you want the derived reference text to appear. The FDK or FrameScrip application would recognize that text location, process the REFMAN attribute in the current element, and replace the text position locator with the derived reference text. If all of the chapter references you want to produce are in the Wiring Manual, then only one such application would have to be developed. But if you also want to process the REFMAN atttribute to produce a similar result for references to other manuals, you'd have to develop a separate application for each type.
Interchange vs. Analysis
--- mcarr at allette.com.au wrote: > I consider DITA to be an interchange format. If two > organisations can figure out how to convert their own structure > to and from DITA, they can freely exchange data. Add five more > organisations and impose the same requirement on them and everyone can exchange data, whereas in the past, > each organisation would have to code the conversion > for all of their data partners. This is very powerful and very useful, but it doesn't replace the structure > that the organisations use on their own side. === I agree completely. The schema should be defined by the database/CMS requirements that a particular enterprise has developed to reflect its business model, not by the content creators, whose job it is to produce documents which can be parsed on the XML side into their constituent components for storage in accordance with the database schema. That requirement pertains also to the metadata (attributes) needed to manage the content, including those attributes which enable content to be selectively retrieved from the database in response to a user query. In many documentation systems (ATA, statutory, regulatory, et al), the principal method which users employ to retrieve the information thay desire is an unique number (or numbers) associated with the content of interest. That means there must be attributes which which carry this informaton, and those attributes must not only be used for retrieval, but also to apply the full and correct numbers to the extracted content. In other words autonumbering such as that used in FrameMaker cannot be used to produce the correct number when a piece of of a document is retrieved. But the problem with using something like DITA for information interchange is that it is unlikely the metadata defined by DITA will match the metadata in the enterprise's database schema. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory
Structure/Schema - Custom or off the shelf?
--- Alan Houser wrote: > Organizations are "successful" when they meet their > business requirements as efficiently (time and $$$) as > possible. I talk lots of people _out_ of migrating to XML for > this reason. I even occasionally say "you're doing just fine > with MS Word." Certainly, there's no rational reason to migrate to XML unless you intend (now or in the future) to manage your documentation by storing it (parsed into its constituent components) in a database/CMS, or your customer(s) demand that your documentation be delivered to them in that form for the same purpose. The other case where XML may be important is database publishing of catalogs, directories, etc., where the content is originated in the database, and must be output to a publishing engine such as FrameMaker. However, there are several other forms (e.g., character-delimited, fixed field, and others) in which any database can output the data, and, in my experience these alternatives are better than XML for database publishing. = > Printing XML using XSL-FO is one of the most difficult tasks > you will face, and leveraging the XSLT transforms for an > off-the-shelf DTD is likely to save a very substantial amount > of development time. == And there's the rub, isn't it. The whole idea of SGML and XML is based on the premise that structure and metadata are the important things, and thus all formatting information must be striped out of the stored content. But then the extreme difficulties and high cost associated with developing customized, adaptable XSL-FO, FOSI or DSSL appications forces companies to select a non-optimal "standard" DTD so they don't have to do any formatting development. Thus, the desira to create a customized DTD that provides the optimal structure for an enterprise must be abandoned snd replaced with a dreary "standard" DTD like Docbook or DITA. And they must also accept the dreary formatting produced by the "standard" formatting application. So the original concept that structure is more important than formatting, is, in reality reversed, and the typical enterprise is forced to accept an easy solution to the formatting problem by choosing a mediocre "standard" monstrosity such as Docbook or DITA. Does that make any sense? Not to me it doesn't. === > By the way, I never recommend starting out with > out-of-the-box DocBook = That's like putting lipstick on the pig. It's still a pig. And each modification of Docbook or DITA may imply major costs in adapting the "standard" XSL-FO application which caused you to select the pig in the first place. Thus, significant modification of the pig is likely to be discouraged. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory
Esc m p for anchored frames?
If you initially set the anchored frame postion to be Below Current Line, using ESC mp to shrink the size of the anchored frame to the size of the contained graphic object changes the anchored frame position to "At Insertion Point". To restore the original position after shrinking it, you must click on the anchored frame, open the Anchored Frame dialog, and and re-select "Below Current Line", and perhaps also restore the original "Alignment" position. Don't ask me why the ESC mp action forces these arbitrary changes in position and alignment. That's just the way it is. I suspect that this shortcut was added at the request of one of the large license holders, who explicitly asked for this behavior, and Frame Technology complied with the request. --- Tammy.VanBoening at jeppesen.com wrote: > Ok, > > I have tried searching the archives for this, but > the searchable messages > don't go back far enough in time. I distinctly > remember a discussion about > what the m and p represented in the Esc m p command > for anchored frames. > Fred Ridder also supplied a succinct description of > why this functions the > way that it does - basically, when I place my > anchored frame at a certain > location, then use Esc m p, the frame is shrunk to > the size of the > graphic, but the whole frame with the graphic is > shifted upwards - it does > not remain in its original location - if this > description makes sense. > > Any information on this subject is appreciated. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory
POLL: Which method do you use to apply bold and italics?
> Bill Swallow wrote: > > Being a manager and until recently a template > owner, I completely disagree. UI tweaks passively hinder > misuse. Proper training and education for writers actively > prevents misuse, and even initiates their own investigation > into other ways to prevent needless headaches in a > documentation effort. All well and good, but the certainty of retribution is better. In structured Frame, retribution is certain. Tell your writers that each document they turn in for edit/review will first be subjected to the following steps: 1. Open the writer's submission. 2. Open the applicable structured template. 3. Import formats from the template with Format/Overrides turned on. 4. Import the element definitions from the template with Format Rules Overrides turned on. 5. Validate the writer's submission to detect any structure violations, including detection of failure to enter values for required attributes. To impress new writers with all the implications of this process, have a sample demonstration document with instances of each type of violation, and demonstrate what happens when the above steps are taken. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory
Help vertically centering text in FM..
--- Andy Kelsall wrote: > I can't for the life of me figure out how to > vertically align text > in FM. I have a page where I would > like to align the text vertically, but after poking > around FM and doing a > Google search, I'm still stumped. > Is it possible to do this in FM? Does it require > creating a table that fills > up the page and then aligning the > the text in the cell? Any help would be appreciated. Obviously, in order to calculate the location of the top line of text to be vertically centered, you must know in advance the total height of all the text lines in order to properly center the first line. but there is no way to use the paragraph designer to properly do this. So, the only way to accomplish this is to insert (at the top of the page) a one-row, one-column, unlined table (no space above or below) whose width and height matches the width and height of the text frame. Then to properly center all the text within this table you must use the Table > Row Format dialog to set the minimum height of the table row to be (nearly) the height of the text frame. Then in the Paragraph designer, you must set the Cell Vertical Alignment under "Table Cell" to Middle. All of the text will then be centered within the table column. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
question re object properties in Frame 7.2
--- Shlomo Perets wrote: > The "extremely useful" phrase is indeed used in the > review, but frankly I > wasn't sure how it should be interpreted. = You are very kind Shlomo.
Page Numbering Properties
--- "Wollenberger, David" wrote: > I have a situation which I don't think is so > unusual, and yet I can't seem to figure out how to > get FM to handle it. Our TOC page numbering begins > on iii and goes as long as it has to, ending on an > even page. > Our Chapter 1 begins on the next page after the TOC > page. So if the TOC is eight pages (iii-x), then the > first page of Chapter 1 is 11. = To me, what you describe as not "unusual" is extra-unusual. The whole reason for using roman numerals in front matter is to allow the non-front matter to begin at arabic numeral 1. Your company's numbering scheme is counter-intuitive and dumb. I defy you to find any instance where professionally-published books of any type use the numbering scheme you describe. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
OT: Unbelievable On-Line Help Stupidity
I was helping a friend who?d just acquired her first computer, an E-Machine with Windows XP. I was demonstrating how to get help, and showed how she could type in a search phrase and get a list of all the help topics containing that phrase. So, to demonstrate how to properly shut down the computer, I entered the search phrase ?Turn Off.? Sure enough, all the help topics containing that phrase appeared, and I selected the?Turn Off The Computer? topic. Here are the instructions which appeared under that topic: ?Click Start, click Shut Down, and then in the drop-down list click Shut Down? The only part of that instruction which is correct is ?Click Start.? o There is no Shut Down option under Start. It?s called ?Turn Off Computer.? o There is no drop-down list under the ?Turn Off Computer? dialog. Instead, there are 3 buttons. o There is no button option under ?Turn Off Computer? called ?Shut Down? Instead there are three button options: ?Stand By?, ?Turn Off?, and ?Restart.? Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Unbelievable On-Line Help Stupidity
--- Phil Heron wrote:
> I am on Windows XP Professional.
> The instructions you list ("Click Start, click Shut
> Down, and then in
> the drop-down list click Shut Down") are perfectly
> correct for my
> computer. That is exactly what I see.
===
The e-Machine had Windoze XP Home Edition installed.
Apparently, Microsoft soesn't versionize its on-line
help. (which makes you wonder what else they
incorrectly fail to versionize).
RE: Numbering Systems for Technical Service Manuals
--- "Linda G. Gallagher" <[EMAIL PROTECTED]> wrote: > I only use that type of numbering when a client > insists on it. Typically, > those clients are engineers with content targeting > other engineers. == The complaint that prompted Ms. Gallagher's response was that multi-level numbering schemes "looked clunky," the implication being that such numbering offended the writer's esthetic sensibilities. Ms. Gallagher's response is a laughable explanation for when (or why) multi-level numbering of topics (as well as tables and graphics) might be necessary. No doubt most engineers use such numbering schemes because it is the only assured way to avoid ambiguity when you reference something. The legal profession uses such numbering schemes for the same reason. Then there are the military and the Air Trasport Association (ATA) (among many others) which also require such numbering schemes because a number provides a way to double-check that that the user is following the correct procedure. Someone else pointed out (correctly) that the concept of a content management system (CMS) also imposes a requirement for such numbering schemes in order to facilitate the retrieval from a CMS of the particular information needed by a user. To implement this, the value of each level of a multi-level number appears in a separate attribute (ala ATA DTDs, where the attributes are named Chapter, Section, Subject, Page Block, Task, and Subtask). Inspection Work Cards in the ATA system identify the applicable number(s) associated with each task or subtask identified on an individual work card. If the inspection results in the need for some corrective action, the multi-level task number specified on the work card is used to retrieve that task from the CMS. The user can then verify that the number on the delivered content matches the number specified on the work card for that task. This process of number re-verification is an essential ingredient of a zero-tolerance maintenance environment. Producing technical manuals of any substantial size and scope demands an appropriate multi-level numbering scheme, not just for titled text, but also for titled tables and graphics. Even relatively simple on-line help docs should have some sort of numbering scheme. Typically, users who can't figure out something from the on-line help will resort to a customer help line or in-house expert. If the user can give the help specialist the number of the particular on-line help content where the user is stuck, ambiguity is eliminated, a successful resolution of the problem is more likely, and the time to arrive at the correct solution is likely to be minimized. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Numbering Systems for Technical Service Manuals
--- "Linda G. Gallagher" <[EMAIL PROTECTED]> wrote: > I don't think it was necessary to single out my > response and call what I > said laughable. Your unqualified statement that the only people left who use such numbering schemes are engineers communicating with other engineers is what made it laughable, because your statement itself was insulting to the many technical disciplines where such numbering schemes are considered essential. Clearly, many types of technical documentation other than engineer-to-engineer documents are enhanced by using a rational numbering scheme, and I cited many examples in my initial reply. One could infer that your conclusion derives from the fact that your millieu is restricted to on-line help--the realm where shovelware reigns supreme. In general, that regime only works when the product being supported is some relatively simple piece of software, and on-line help is only useful to beginners, who would probably be better off if they could print a complete manual that actually looks like a technical manual when it is printed. The general assumption of on-line help developers seems to be that links are a substitute for a rational numbering scheme. You may be surprised to learn that there are vast realms in which selected technical manual content must be printed out in order to successfully carry out tasks, and thus links no longer work. in those cases, a rational numbering scheme in the printed portion replaces links as the method for finding (and printing) referenced content. That's an unnecessary insult. == Your statement itself insulted those who produce technical content that is far superior to the typical on-line help shovelware. == > As for this particular issue, I know of few writers > and companies who advocate using numbered sections as you suggest. == How many companies or writers do you know who work outside the realm of on-line help shovelware? Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Numbering Systems for Technical Service Manuals
--- Anne Robotti <[EMAIL PROTECTED]> wrote: > Is this a private email from Linda that you posted > to the list? How > completely rude. = My mistake, and I apologize to Linda. The Framer's list, unlike some others, identifies the sender's name, not the list's name as the sender. My default email setup only identifies the sender in the From line, thus, when I hit reply, only the sender's name appears in the To line. Since the thread originated on the Framers list, I presumptively added the list name on the cc line in my reply. I usually check first to see if that is proper, but this time I failed to do so. I'll be more careful in the future. My bad. Nevertheless, this issue about numbering of titled headings, tables and graphics seems to come up frequently. It's a valid issue, and it deserves more discussion on the list. And by the way, I do not apologize for describing most on-line help as shovelware. If that is offensive to some, so be it. The FrameMaker on-line help in versions 4 and earlier was far superior to the shovelware that replaced it in later versions. That, coupled with the much less complete printed manual, makes life more difficult for newbies. Many of the FrameMaker issues which come up over and over again on this list should be answered by declaring RTFM. Unfortuantely, that recommendation no longer applies in many cases. The same goes for the Acrobat manual. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Numbering Systems for Technical Service Manuals
--- Steve Rickaby <[EMAIL PROTECTED]> wrote: > Surely the answer here is 'horses for courses'? > There are many areas where numbering is either > appropriate or essential (engineering manuals,legal > documents, political documents, medical documents, > repair manuals, ya-de-yah), and others where it is > not. Legal is one special case: due to its density, > every *paragraph* is often numbered. == The essence of the reason for numbering in the document types I (and you) cited is multi-fold: 1. It eliminates ambiguity 2. It facilitates rapid access 3. It minimizes mistakes, and speeds up access, particularly when you are working off-line with a paper copy, in which case hyperlinks are unavailable. When you reference something by its title instead of by an unique number, it creates two problems: (a) How do you find it in a large document, whereas referencing by a number tells you exactly where it's located, and (b) technical manualsoften have many instances of very similar titles, and users are more likely to go to the wrong one. For these reasons, I contend that that nearly all technical manuals fall into the same category as engineering documents, legal documents, medical documents, etc., because all of those types share the urgent necessity of avoiding mistakes caused by looking up the wrong reference. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Hypertext Link Strangeness
<[EMAIL PROTECTED]> wrote: > I've got one for you I am making hypertext links > active in the PDF > output by using a "message URL" hypertext marker. I > use a character tag > to identify the text to include in the link. This > has worked fine for me > in the past in unstructured docs. > > I have recently noticed that in my structured doc > the link is not > working the way I expect. In some cases I get only a > part of the address > in the link or no active link at all. = My experience with converting structured docs with hyperlinks to PDF is that the links don't work if you insert the gotolink (or message URL marker) at the before the first text character in a text line. Instead, insert the marker at the end of the highlighted text (i.e., just before the end bracket ]) delineating the end of the character tag. The same goes for newlink markers. Namely, never insert a newlink marker before the first text character in text line. I use EDD-defined structure rules to define the link components, as follows: = GoToExt (a link to another FM document or URL) The structure rule for this element consists of the names of one or more marker-type elements: (FmGotlink | MailLink | whatever else is needed) Each element specified in the structure rule is defined as being a marker of a particular type. Element GotoExt is defined as a text-range element and the format rule specifies colored text. == GoToint (a link to a newlink marker within the same document). The structure rule for this element is: (FmGotolink | whatever else is needed) Each element specified in the structure rule is defined as being a marker of a particular type. = Element NewLink (an element of type newlink marker, which specifies the unique name of a hypertext node within a FrameMaker document. Obviously, no colored text is required in this case. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Help vertically centering text in FM..
--- Andy Kelsall <[EMAIL PROTECTED]> wrote: > I can't for the life of me figure out how to > vertically align text > in FM. I have a page where I would > like to align the text vertically, but after poking > around FM and doing a > Google search, I'm still stumped. > Is it possible to do this in FM? Does it require > creating a table that fills > up the page and then aligning the > the text in the cell? Any help would be appreciated. Obviously, in order to calculate the location of the top line of text to be vertically centered, you must know in advance the total height of all the text lines in order to properly center the first line. but there is no way to use the paragraph designer to properly do this. So, the only way to accomplish this is to insert (at the top of the page) a one-row, one-column, unlined table (no space above or below) whose width and height matches the width and height of the text frame. Then to properly center all the text within this table you must use the Table > Row Format dialog to set the minimum height of the table row to be (nearly) the height of the text frame. Then in the Paragraph designer, you must set the Cell Vertical Alignment under "Table Cell" to Middle. All of the text will then be centered within the table column. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
re: question re object properties in Frame 7.2
--- Shlomo Perets <[EMAIL PROTECTED]> wrote: > The "extremely useful" phrase is indeed used in the > review, but frankly I > wasn't sure how it should be interpreted. = You are very kind Shlomo. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Schema Tools
--- Jon Harvey <[EMAIL PROTECTED]> wrote: > We would like to begin developing in structured > framemaker. My understanding is that to do so, we > need to bring in schema that FM can use to help us > structure our docs. Can anyone recommend some solid > tools for creating schema? It's either that or > write the markup by hand, > something I'd rather not do. === "Schema" is a database term. A schema describes the detailed structure of a particular database design. If your intent is to export data from structured FrameMaker into such an existing database, your EDD must replicate the schema of your database. If that's not your goal, and instead you are simply trying to create structured documents, then you may be able to ignore some of the rigors of a pre-defined schema in developing your structured application. Other external constraints/requirements, however, may impose schema-like requirements that affect the design of your EDD. It's even conceivable that the EDD you develop, when it is converted to a DTD/schema, could be used to define the schema for a new database in which you intend to store Framemaker documents broken up into their constituent structured components. Be aware that implementing a true database schema imposes certain constraints on EDD developement. For instance, the use of inclusions in the structure rules of an EDD makes documents created in accordance with an EDD incompatible with export to XML or storage in a database. Also, true schemas can impose more rigorous requirements on the permissable values of attributes. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Importing Pricing ino Frame Document
You've gotten plenty of suggestions. I assume that, presently, production of your catalog is being done in a manner that is incompatible with a full database publishing solution, otherwise the solution would be obvious. The FrameScript solution offered by Rick Quatro would seem to be the simplest and best one offered so far. But I propose two more alternate solutions: A. Strip out the "embedded" pricing, and instead create a separate pricing section in the catalog in which the products are listed in order by their part number. This new section could be easily and quickly generated from a database just before printing. B. There is a solution using UniMerge which would preserve the existing catalog structure with embedded pricing. To update the pricing, you'd perform the following steps: 1. Produce a database extract containing the following two character-delimited fields: PartNum,Price. 2. In the existing FrameMaker catalog document, replace the existing in-text price for each catalog item with the following UniMerge command: ^[IF (PartNum = 123) ^Price ^[END] where XYZ is the part number, and Price is the unit price for that part number. 3. After completing step 2, you save the modified FrameMaker catalog document in MIF format, creating a UniMerge template. 4. Finally, you execute UniMerge on that template, specifying as the data source the 2-field database extract described in step 1. This action causes UniMerge to merge the data from the database extract into a MIF file output which preserves all the formatting and content of the original MIF file, and updates the price UniMerge executes from the MS-DOS or UNIX command line. It costs about $750 on Windoze platforms. It doesn't run under the MAC OS. Ultimately, it may be possible for you to use UniMerge to generate the entire catalog, in which case you could radically reduce both your production time and production costs. I've been using UniMerge to produce catalogs, directories and other database-derived documents in FrameMaker since 1994. The user manual and other aids which come with the product are excellent. --- Scott White <[EMAIL PROTECTED]> wrote: > Is there a way to import new prices for a 1,000-page > catalog into a > Framemaker document? > We do many large catalogs here, some with and some > without pricing, and a > potential customer wanted to know if they could > update embedded pricing just > before the files go to press. I thought I would ask > the question. > Thanks. > Frame 7 Mac OS10, Frame 7.2 Windows XP Professional. > -- > Scott White > Media Production Manager > Implentation Coordinator > AlaMark Technologies > 210-704-8239 > [EMAIL PROTECTED] > > > ___ > > > You are currently subscribed to Framers as > [EMAIL PROTECTED] > > Send list messages to [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > or visit > http://lists.frameusers.com/mailman/options/framers/danemory7224%40sbcglobal.net > > Send administrative questions to > [EMAIL PROTECTED] Visit > http://www.frameusers.com/ for more resources and > info. > ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Public Domain Templates for FrameMaker Docs
If your company is a member of the ATA, you can obtain the DTD for spec 100 from the ATA. Using that DTD, you can generate a FrameMaker EDD. You then add to the EDD the formatting information you require to produce structured ATA 100-compliant documents. --- Steve Cavanaugh <[EMAIL PROTECTED]> wrote: > > Hi everyone. I'm a brand new FrameMaker user here, > and I've been hired to > produce a Component Maintenance Manual to ATA > Spec-100, to which I am also > new. EGAD! It raises the question in my mind - are > there any repositories > of public domain templates for industry standard > type documents such as Spec > 100? I'm certain that with a bit of study, I'll be > able to produce one, but > if I had one to model from, and learn from, it would > decrease the learning > curve considerably. Anyone know of such a > repository, or even where I might > find a set of stand alone templates for ATA Spec > 100? > > By the way, this looks like a very useful list - > I've already learned > several things in just the last two weeks. > > Steve Cavanaugh > > ___ > > > You are currently subscribed to Framers as > [EMAIL PROTECTED] > > Send list messages to [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > or visit > http://lists.frameusers.com/mailman/options/framers/danemory7224%40sbcglobal.net > > Send administrative questions to > [EMAIL PROTECTED] Visit > http://www.frameusers.com/ for more resources and > info. > Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Columns in middle of chapter
--- "Lisa M. Balbes, Ph.D." <[EMAIL PROTECTED]> wrote: > My client wants one section of a particular chapter > to be in columns, instead of the full page width text of the rest of the chapter. This > section will extend over several pages, and will > probably have things added and deleted as we continue editing the document. They want the > columns to flow like a newspaper - filling both > columns on one page before moving on to the next. There is a viable way to do this in FrameMaker. First, your Left and Right master pages must both be converted from a single-column page layout to a 2-column layout. Second, to make it work, you must have two sets of paragraph formats which at differ in a single setting within the Pagination pane of the Paragraph Designer, namely: 1. the paragraph formats for the ordinary single-column content are all set to "Across All Columns":, 2. The paragraph formats for the 2-column content are set to " In Column". Take note also that you'll need to define 1- and 2-column paragraph formats for graphic and table anchors if the 2-column text contains graphics or tables. With this setup: Each time you switch from a 1-column paragraph style to a 2- column paragraph style, lines of 2-column text are produced. Then, switching back to a 1-column paragraph style will cause the lines of 2-column text above it to be balanced out within the two columns, and the text below will resume the 1-column layout You can switch back and forth between 1- and 2-column text multiple times within a single page, thus you can begin and end the 2-column text anywhere within the same page, or you can start the 2-column text anywhere on a beginning page, and end the 2-column text anywhere on a succeeding page. This solution works best when: A. Single-column text appears at the top of a page, and either fills the page or is followed by 2-column text which fills the rest of the page, or B. The 2-column text appears at the top of a page, and either fills the page, or is followed by 1-column text which fills the rest of the page. If, as you state, there are likely to be subsequent edits which cause both the 1-column text and the 2-column text to shrink or grow in size, you may find it necessary to manually force page breaks more often that usual in order to keep the 2-column text coherent. This, however, should not be much of a problem if all the 2-column text is in one solid, multi-page block that is preceded and/or followed by solid blocks of single-column text. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: general publication quiestion
--- Charles Beck <[EMAIL PROTECTED]> wrote: > Maybe I'm missing something, and then again, maybe > I'm not. I too have > always considered it a strange paradox when I see > the words "This page > intentionally left blank." But there is no need to > use it. == Mis-printed technical documentation has real-world consequences. A printer device can misfeed two or more sheets at once, inserting completely blank double-sided sheets, or, even worse, it may print one side properly, but mis-feed two or more sheets at once on the second pass to produce the backside pages, which results in an incorrect blank backside for one or more pages. The fact that, more and more, technical manuals are being delivered as computer files, not professionally printed and bound paper documents, increases the likelihood of printing errors when users print out all or part of a manual, and thus unambiguous identification of blank pages becomes even more important. In designing technical documentation, technical writers have an obligation to consider the impact of such things as printing and binding errors, particularly when such errors could have life-and-death consequences. How, then, do you prevent such consequences. There's only one way, and that is for users to be trained that any completely blank page or page side constitutes an error that must be corrected. Consequently, every single page must have text. The logical solution for an intentionally blank page is to place the statement "THIS PAGE INTENTIONALLY LEFT BLANK" in the center (not the edges, which may be incorrectly trimmed or mis-printed) of the page. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: general publication quiestion
Your "snip" below deleted from my original post the main reason I gave for why intentionally blank pages should be unambiguously labeled. The snipped part was: "The fact that, more and more, technical manuals are being delivered as computer files, not professionally printed and bound paper documents, increases the likelihood of printing errors when users print out all or part of a manual, and thus unambiguous identification of blank pages becomes even more important." "In designing technical documentation, technical writers have an obligation to consider the impact of such things as printing and binding errors, particularly when such errors could have life-and-death consequences." = As the military has learned, some readers of technical documentation are not at the bright end of the mental continuum. Unless blank pages are unambiguously labeled so that even a low-wattage brain will get the message, the military has learned that some very troubling outcomes occur. The US military conducts, as a matter of course, thorough reviews of snafus to identify the causes of the foulups. Instances where poorly designed or written tech manuals contributed to a snafu are extremely common, and corrective actions are often recommended, which result in changes in MIL specs, and/or changes in the validation and verification process for military tech manuals. The standardization on the "THIS PAGE INTENTIONALLY LEFT BLANK" solution was found to be the least ambiguous way to identify blank pages, because it allows a simple training mantra, namely: "If you find a blank page in a manual which does not contain the above statement, something is probably wrong. Stop what you are doing, and seek advice from your superior." The fact is that the US military is the only true laboratory where technical documentation is subjected to extensive post-publication review to determine its effectiveness in the real world. Findings resulting from analyses of actual foul-ups lead to continuing improvements in tech manual instructions. Those who write manuals for non-military applications ought to also take advantage of that laboratory. --- "Combs, Richard" <[EMAIL PROTECTED]> wrote: > Daniel Emory wrote: > > > --- Charles Beck <[EMAIL PROTECTED]> wrote: > > > Maybe I'm missing something, and then again, > maybe I'm not. > > I too have > > > always considered it a strange paradox when I > see the words > > "This page > > > intentionally left blank." But there is no need > to use it. > > == > > Mis-printed technical documentation has real-world > > > consequences. A printer device can misfeed two or > more sheets > > at once, inserting completely blank double-sided > sheets, or, > > even worse, it may print one side properly, but > mis-feed two > > or more sheets at once on the second pass to > produce the > > backside pages, which results in an incorrect > blank backside > > for one or more pages. > > > How, then, do you prevent such consequences. > There's only one > > way, and that is for users to be trained that any > completely > > blank page or page side constitutes an error that > must be > > corrected. Consequently, every single page must > have text. > > The logical solution for an intentionally blank > page is to > > place the statement "THIS PAGE INTENTIONALLY LEFT > BLANK" in > > the center (not the edges, which may be > incorrectly trimmed or > > mis-printed) of the page. > > All this concern over "completely blank" pages > strikes me as odd. But > then, I read Charles Beck's explanation of *why* > there's no need -- the > part about *headers* and *footers* that's > conveniently snipped above. > > And "only one way"? This is beginning to sound more > like a religion than > techwriting advice. > > In the past, I've used a level-1 heading that reads > "Notes" at the top > of the extra page (below the header's ruling line) > -- does that lack the > rigorous user training component that the statement > "THIS PAGE > INTENTIONALLY LEFT BLANK" seems to possess? > > What about this "in the center" bit? Does it have to > be horizontally > centered too, or can it align left in the text > column? For that matter, > if you have wider inside than outside margins, > should it be centered on > the page or in the column? > > For those of us who like the golden ratio, would it > be beyond the pale > to place the statement 1.62 times as far from the > bottom of the page as >
Re: The Page Left Intentionally Blank
--- Shmuel Wolfson <[EMAIL PROTECTED]> wrote: > I always felt that "This Page Intentionally Left > Blank" sounds a bit > weird. Why would you intentionally leave a page > blank? I vote to change > it to "This Page Left Blank for Double-sided > Printing." What about the case where the manual is only delivered as a computer file, and the user prints out all or part of the double-sided manual as a single-sided document on local printer? Now a typical dimwit reader will become confused about what it means. The addition of "For Double-Sided Printing" adds an unnecessary confusion factor which adds nothing to the intended meaning, regardless of whether the manual is printed single- or double-sided. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: OT: MIL specs (was RE: general publication quiestion)
Certainly I don't advocate the use of MIL specs for preparing commercial manuals. I do know, however, that most tech writers who produce manuals for commercial products remain blissfully unaware of the problems caused by their outputs. Unlike typical users of commercial products, most users of MIL=SPEC manuals have received thorough training on the systems they will maintain/operate, including classroom exposure to the manuals they will use after they graduate. Nevertheless, they frequently foul up, and sometimes it's because the manual is poorly written or deficient in other ways. Unlike the commercial world, the military reacts by investigating manual-caused snafus, and taking corrective action, which may include modification of both the training and the manuals. All I was trying to say is that tech writers in the non-military world should take advantage of remedial measures taken by the military to minimize foul-ups. One such remedial measure was to require blank pages to have the infamous "THIS PAGE LEFT INTENTIONALLY BLANK" appear in the middle of each empty page. The absence of this statement on a blank page assures that the reader knows something is missing. The military learned the necessity of this measure the hard way, yet the general ridicule this subject receives each time it arises is equivalent to ridiculint the fact that car manufacturers discovered it was wise to prevent idiots from starting their automobile while the shift lever is set to reverse. --- "Combs, Richard" <[EMAIL PROTECTED]> wrote: > Daniel Emory wrote: > > > The fact is that the US military is the only true > laboratory > > where technical documentation is subjected to > extensive > > post-publication review to determine its > effectiveness in the > > real world. Findings resulting from analyses of > actual > > foul-ups lead to continuing improvements in tech > manual > > instructions. Those who write manuals for > non-military > > applications ought to also take advantage of that > laboratory. > > First there was "only one way." Now there's the > "only true laboratory." > I'm seeing a pattern here... > > Ever hear the (chiefly British) expression "horses > for courses"? :-) > > Don't get me wrong -- I'm a huge fan of the US > military (especially when > they're killing Islamofascists). I donate to > Soldier's Angels, the USO, > VFW, PVA, ... > > But if some edict were to declare that henceforth > all technical > documentation everywhere must be done to MIL specs, > I suspect I'd change > professions or retire. At the least, I'd have to go > on anti-depressants. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: Searching in text insets
--- Fred Ridder <[EMAIL PROTECTED]> wrote: > "Supposed to be" could be argued, but it certainly > is the way > things *are*. Text insets are treated as black boxes > by the > Find/Change operation. == Putting text insets in text frames (each with a different text flow name) within reference pages in the same document is one way to preserve the find/change and spell checking capability for text insets. Of course, this solution only works when the entire text inset content will fit within a single reference page. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Can an Element be a Container and a System Variable
--- Catudal & Rousseau <[EMAIL PROTECTED]> wrote: > Can an element be a container and a system variable > at the same time? I > would like to generate the Chapter-Section-Subject > in the footer of the page from the > attributes of the subject element. === Yes, this is doable if you appropriately define a running header/footer variable to contain the applicable attribute value(s). For instance, if you define three attributes in the subject element to have three attributes identifying the chapter (chapnbr), section (sectnbr) and subject number (subjnbr), you would define an available running header-footer variable as follows: <$attribute[chapnbr:Subject] - <$attribute[sectnbr:Subject]> - <$attribute[subjnbr:Subject]> Alternatively, if you were to use a single attribute to define all three numbers (e.g, 2-3-5) in the Subject element, the definition of the running footer variable would be simplified as follows: <$attribute Note that you must follow the attribute name with a colon (:) followed by the name of the applicable element in which the attribute is contained. If there are two or more Subject elements on a page, the attribute(s) in the first element is used. If there are no Subject elements on the current page, Framemaker will use the attribute values in the last Subject element on a preceding page. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Displaying a Portion of an Attribute Value
--- Catudal & Rousseau <[EMAIL PROTECTED]> wrote: > I would like to display a portion of an element's > REFLOC value, for example, > this element with attribute values to be displayed Wiring Manual Chapter 20 so I would like to display the numerical value of the REFLOC attribute with a prefix. = I take it that the REFEXT attribute is intended to produce a hypertexted link to Chapter 20 of the wiring diagram manual, or something like that, and the sole piece of the REFEXT attribute you wish to extract is the number 20, and then prefix that number with the words "Wiring Diagram Chapter". This would require that each REFLOC attribute be processed to find and delete the string: , and replace that string with "Wiring Manual Chapter" followed by the remaining part of the attribute, which is the chapter number. Certainly, this cannot be done using FrameMaker read/write rules. So, you'd have to develop an application using the FDK or FrameScript (or something similar). Presumably, you'd have to signify, in some unique manner, the location within the text where you want the derived reference text to appear. The FDK or FrameScrip application would recognize that text location, process the REFMAN attribute in the current element, and replace the text position locator with the derived reference text. If all of the chapter references you want to produce are in the Wiring Manual, then only one such application would have to be developed. But if you also want to process the REFMAN atttribute to produce a similar result for references to other manuals, you'd have to develop a separate application for each type. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: PDF to framemaker
--- Peter Ring <[EMAIL PROTECTED]> wrote: > Dov is of course correct in stating that PDF should > be considered a final form document format. But, > nevertheless, PDF can be used as an > input (to Frame) === Another effective way to use PDF as an input to FrameMaker is to use it to import graphs for display in FrameMaker documents. In this case, however, the graphs are first created in FrameMaker. The method is described below. Step 1. On a new FrameMaker master page, create a background frame in which you create (using FrameMaker's drawing tools) the graph's frame (i.e. the X and Y axes with labeled tickmarks (and perhaps corresponding horizontal and vertical lines), plus any additional static text. Step 2. On a body page in which the background master page from step 1 is used, employ FrameMaker's drawing tools to to overlay the background created in step 1 with the foreground graphical plots (lines, curves, wedges, etc), using different colors diferent dashed lines, etc as needed. Additional text labels might also be created in the overlay, as needed, using the drawing tools. Step 3. Save the body page created in step 2 as a 1-page PDF with an appropriate filename. Step 4. Open the PDF created in step 3 and crop it as needed to eliminate all the white space surrounding the graphic, and then re-save it as a single-page document. Step 5. At the location in a FrameMaker document where you want the graph to appear, import the PDF produced in step 4 into a graphic frame, scaling it as needed. This methodology is particularly useful when the basic graph background created in step 1 above is used multiple times to produce different graphical plots. In that case, each graph created in step 2 is saved to a separate PDF file in steps 3 and 4. And of course, the resulting PDF graphics are not restricted to use in FrameMaker. They can be used in any software product which can import PDFs. Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: New to the list, and asking for help
--- Pedro Pastor <[EMAIL PROTECTED]> wrote: > Maybe the troubles I've found come from my > inexperience developing structured applications in FM, but I cannot fully understand the aim > behind the (so called) "XML-roundtrip" editing. == Assuming that the documentation you are creating and updating/editing is accomplished by human beings, you can avoid XML-roundtripping only by having your writers create/modify tagged XML. If you expect to have any semblance of a productive authoring environment, you must "round-trip" the XML into some sort of authoring product which provides the numerous bells and whistles needed to hide XML internals from your authors. Most XML editing produces are not WYSIWYG, and thus in those editors authors see something that is not a facsimile of what human readers will see when they retrieve those documents. Structured FrameMaker is just as much an XML editor as any of the other ones. It provides an automated way to import XML instances into FrameMaker, preserving all the XML internals, and at the end of an editing session, it provides an automated way to export the work product back into fully conformant tagged XML output. The extra feature of FrameMaker is that it avoids the necessity of having to use the clunky and difficult-to-implement XML tools used to accomplish acceptable formatting and layout needed to make documents that are highly readable and effective for human users. That is, FrameMaker, in addition to being a powerul way to create documents, can also serve as a powerful print engine for delivering high-quality, eminently readable, technical documents in paper or PDF format. == > 1) I cannot understand how to clearly separate > structure from presentation in FM. If EDD contains > structure and presentation > information we are against the main principles of > SGML/XML document > design!! = Gee, the idea behind FrameMaker is to have the best of both worlds. Desktop publishing systems like FrameMaker have highly sophisticated formatting and layout capabilities. You can, however, completely ignore presentation in an EDD simply by declaring that all text will use a single paragraph style. If, on the other hand, you decide to exploit Frame"s exquisite presentation capabilities, you can export a structured Frame document to XML or SGML, and none of that formatting information gets exported, hence it in no way violates the canons of XML or SGML. The fact is that both SGML and XML provide a set of clunky, insufficient and unwieldy tools for delivering formatted output for printing or on-line display. The FrameMaker EDD offers a far more robust and elegant method for producing high-wuality presnetations. == > 2) It seems like there are two placeholders > for storing presentation information: Templates and EDD documents. This could be > redundant, I mean, the same presentation definition > data could be store > on both places. === Again you denigrate a powerful feature of Frame. The EDD specifies the names of paragraph, character and other types of formatting tags based on element context. Templates are used to specify the formatting details for each such tag. There are two advantages to this. First, you can change the formatting (e.g., fonts, sizes, etc.) without disturbing the EDD. Second, you can create multiple template versions for the same EDD, allowing you to deliver differently formatted documents which meet the requirements of different types of users or different types of documents created from the same EDD. Another feature of the EDD is format change lists, which allow certain parameters (e.g., indents, fonr size, autonumbering) of a given format tag to be modified in different structural contexts. === > 3) In addition to this, Template document > could have structure > associated with it (via importing EDD document). > Then we get just > another way of associating structure to documents, > apart from the DTD > specification!!). Wrong again. A DTD contains no formatting information. You create an EDD. Then you import that EDD into an empty FrameMaker document, and the EDD "seeds" the empty document with all the EDD's structure rules as well as all the formatting tags defined in the EDD. Then the designer defines the parameters of each EDD-defined format tag. If your production needs require different presentations for different customers or different types of documents (all created from the same EDD), You create more than one structured template for the same EDD, and design the formatting of each version of the template to meet specific formatting and layout requirements. To create a new structured document, you select the appropriate template file and apply it to a new (empty)Fram
Re: QA wants unique edition number in changed footers
--- "Andersen, Verner Engell VEA" <[EMAIL PROTECTED]> wrote: > Have you any idea of how I can have the various > edition numbers in footer of each chapter page and > still have the possibility of importing all formats > from all files without messing things up? == This kind of dilemma can be eliminated in structured FM documents. The edition number, rev number, rev date, effectivy, and similar info can be produced by defining FrameMaker header/footer variables which pick up the current value(s) of the applicable element attributes. In mission-critical documents (aircraft maintenance manuals, for instance) the process begins with the technician picking a work card to perform a particular maintenance task on a particular aircraft (the same aircraft model can have many different configurations, even within the same airline). The work card provides all the information needed to assuredly select the correct procedural instructions from the maintenance manual (in the ATA methodology, the mechanic submits the work card number to a database, which retrieves the applicable procedure from the maintenance manual). The work card information may even allow the mechanic to examine the information in the footer of each page of the retrieved procedure to verify that the footer information (such as the page's effectivity, current revision date, page block number, etc.) agrees with what appears on the work card. All of this footer informatin in the retrieved procedure is produced from header/footer variables which pick up the current values of the corresponding element attributes when the procedure is delivered to the machanic. As you can see, this approach, employing element attributes which are converted by structured FrameMaker to header/footer variables appearing in the footer, can be used at any level of granularity, even down to individual pages. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Database Publishing book
--- Pat Bensky <[EMAIL PROTECTED]> wrote: > Hello Framers, > I am thinking of writing a book about database > publishing. It would cover > publishing with InDesign and Quark (possibly > FrameMaker and Word as well) > using the following methods: > > InDesign tags > Quark tags > Xtags, Xdata > XML > RTF (perhaps) > FrameMaker tags (maybe) === I've been developing database publishing applications for clients for about 14 years. In some cases, I deliver turnkey applications to my customer. In other cases, I produce the finished output (typically annually). Your list of methods barely scratches the surface, and does seem to address only the most simple database publishing applications, which, in my experience, is rarely enough. Nor do you seem to be addressing he wide array of products/solutions which are available, as well as the extremely wide variety of applications in which database publishing can be employed effectively. Your definition of what you mean by database publishing will determine the scope of your book. The broadest definition would encompass all special solutions whose purpose is to process raw output from a database so as to deliver it in a form that is useable to both human and non-human users. In the case of delivery to human users, such solutions typically include customizeable middleware which can receive/processe/manipulate the raw database output, and makes the processed data compatible with the selected formatting/output engine (e.g., FrameMaker, Quark, Word (ugh) or InDesign). If, for example, FrameMaker is chosen as the formatting/output engine, several customizable middleware products are available, including PatternStream, Miramo and UniMerge. Such middlewar products require the development of a special application for each production operation, which may, among other things, involve evaluatiing each database record so as to select/delete/rearrange the sequence of the data fields in each record before it is delivered to FrameMaker. UniMerge (the product I use) can also specify the FrameMaker format tag to be applied to individual fields, add markers to specify fields whose content is used to produce running header/footers, specify fields which are to be included in a table of contents, insert static text above, below or within a sequence of record fields, specify that some or all fields in a record field be placed within a FrameMaker table, truncate the data in a field, add mathematical operations on rows or columns in a tabular array, and many other functions which radically alter the raw database input before delivering output to FrameMaker. Very large database publishing solutions are very complex, and can cost hundreds of thousands of dollars to develop,operate and maintain successfully. === Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing <[EMAIL PROTECTED]> ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: Replacing Framemaker
The publication by the STC of this article demonstrates the declining relevance of that organization. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
