Adobe Community : All Content - All Communities

Using FM Publish to generate Responsive HTML, how do I produce

?

forums_noreply@adobe.com — Thu, 06 Nov 2014 15:47:24 GMT

Good morning,

I am using FM's Publish command for the first time, producing HTML output. I have a paragraph format that I want to map to an HTML heading with a class attribute (for example, something like <h1 class="x">. For FM paragraphs that map to HTML <p> elements, I can specify a class attribute by selecting an output style in the Style Mappings section of the Publish settings. I can map a paragraph format to a heading element by typing the element name in the User Defined HTML Tag text box. But I'm not able to put the two together. Am I missing a way to do so? Thanks.

--Lynne

FM9 Save CMYK As PDF again: different results for instances of one character

forums_noreply@adobe.com — Thu, 12 Sep 2013 20:55:27 GMT

Hi,

A customer sent me an FM9 document that uses the Symbol font. When he saves the document as PDF, without converting CMYK to RGB, one instance of a character in this font appears in the PDF as a different character in the same font. Other instances of the same character in the same document are fine. Saving as PDF changing CMYK to RGB produces correct results.

Does this sound like the usual don't-use-CMYK-and-Save-as-PDF-with-FM9 type of problem? Or should we look for something else?

Minor variations of the document cause the problem to go away:

1. Deleting some earlier instances of characters in this font cause the problematic one to appear as expected.

2. Some characters in this font occur in tables. Converting those tables to paragraphs "fixes" the problem.

3. Saving as PDF under Win 7 from FM10 and FM 11 produces expected results.

We have only seen the problem on a Win 7 system. On Vista and XP, we get correct results. Editing the document on Vista and saving it as PDF on Win 7, however, fails. A MIF wash does not fix it. Deleting and reinserting the problematic character or the table row in which it occurs does not fix it. While the original document was structured, removing structure did not fix it. Nor did changing master pages.

We started with a longer document and repeatedly deleted content until we had a much shorter document that fails. Somewhere along the line, the erroneous character changed

We can change the documents for this project to convert CMYK. I just don't know if doing so simply masks one particular instance of a general problem, or if CMYK is the real problem.

Thoughts?

--Lynne

Size of PDF output created in FrameMaker

forums_noreply@adobe.com — Mon, 29 Apr 2013 22:39:05 GMT

Hi, I am getting different page sizes when I print a FrameMaker document directly to a printer and when I create a PDF file from FrameMaker and print the PDF. The page printed by PDF seems to be reduced to 95% of the page printed by FrameMaker. I have tried both Save as PDF and printing with Adobe PDF as the printer. I've used a fully-updated version of Acrobat 9 Pro and the version of distiller installed with FM 11. I've tried FM 10 and FM 11. I've used two different computers (one with Windows 7 and one with Vista) and two different printers. I've changed PDF job options. Six months ago, I printed an earlier version of the same document from PDF without this problem. Can someone suggest what might have changed? Thanks.

eSeminar 10/2: Debugging XSLT with FM 11

forums_noreply@adobe.com — Tue, 18 Sep 2012 21:50:08 GMT

Just a reminder that I will be speaking on using FM 11 to debug XSLT at 10:00 AM Pacific time on October 2. To register, go to http://www.adobe.com/cfusion/event/index.cfm?event=detail&id=2076630&loc=en_us.

This presentation follows on both Tom Aldous's recent 5-part introduction to XSLT (http://tmaldous.com/2012/06/15/5-part-eseminars-series-find-out-how-to-write-xslt-statemen ts-for-xml-to-xml-transformations) and the talk I gave on September 5 on using a structured FrameMaker application to edit XSLT itself (http://www.adobe.com/cfusion/event/index.cfm?event=set_registered&id=2085111&loc=en_us).

This packed and fun-filled hour will use an example in which conversion of an unstructured document to XML uses XSLT to augment results produced by a conversion table. I will demonstrate modifying the XSLT transformation, testing it in FM 11's XML view, and opening the result back in the WYSIWYG view to confirm that the desired formatting is produced. I will use an XSLT advanced run to apply the transformation only to relevant files in a directory and then use XPath to find and inspect documents that happen to contain the newly supported construct. In conclusion, I will compare the convenience of staying within FM and switching between the XML and WYSIWYG views as opposed to using another XSLT engine to process files that will be opened in FM.

Structure design issue

forums_noreply@adobe.com — Fri, 29 Jun 2012 16:21:17 GMT

I am designing an EDD. I have an element which can contain a large hierarchy of subelements.There is text I want to display at the start and end of the element (same text in both locations), but I don't want the user to have to enter it twice. If it were simply a string, I'd make it an attribute and include its value in a prefix and a suffix. However, it's a cross-reference.

I am currently considering making the cross-reference the first child of the original element and then using a plug-in or script to copy the cross-reference text into an attribute that I insert into a suffix. This solution is not elegant and it complicates my application since I do not otherwise need a plug-in or script.

Can anyone suggest another approach?

Thanks.

Two eSeminars on editing XSLT in FrameMaker

forums_noreply@adobe.com — Thu, 30 Aug 2012 17:44:09 GMT

Hi,

I'm giving a couple of eSeminars on a structured FrameMaker application for editing XSLT that readers of this forum may find interesting. Info is below:

http://www.adobe.com/cfusion/event/index.cfm?event=detail&id=2076620&loc=en_us

Date: 5 Sep, 10-11AM PST

Topic: Maintaining XSLT code as a structured FrameMaker document

Description:
This webinar describes a structured FrameMaker application for editing XSLT. While the document window appears to show actual XSLT code, the structure of the edited document is an easily-understood variation of that used in the final XML output. Features of this editing structure include:

1) Names of various constructs (variables, templates, modes, and so forth) can be entered once and referenced multiple times as cross-references. To change a name therefore, a user need only change the typed occurrence and update cross-references; there is no need to search for all the individual occurrence.

2) The user can navigate through multiple files with generated lists of elements such as named templates and calls to those templates. Index markers can be used to generate an index into the code.

3) Elements in the structured document spare the user the need to remember details of XSLT syntax such as the names of the different axes and the order of the arguments to various functions. Color is used to visually identify matching parentheses and help prevent some syntax errors.

Once a document is complete, the user saves it as XML using an application that uses XSLT itself to change from the editing structure into actual XSLT code. Furthermore, existing XSLT code can be brought into this environment by opening it using an application that converts XSLT to the editing structure.

In addition to demonstrating a productive environment for maintaining XSLT transforms (or stylesheets), this application illustrates:

1) A practical application of the XSLT features Tom Aldous described in his recent 5-part series of presentations on XSLT in FrameMaker

2) How useful FrameMaker 11 can be for producing XML

3) A situation in which there is more information in a FrameMaker structured document than the corresponding XML

http://www.adobe.com/cfusion/event/index.cfm?event=detail&id=2076630&loc=en_us
Date: Oct 2, 10-11AM PST

Title: Debugging XSLT with FrameMaker 11

Description:
In this presentation, Lynne Price of Text Structure Consulting illustrates how a developer can use new FrameMaker 11 features to test and maintain XSLT code. Lynne will use an XSLT advanced run to transform all files in a test suite and examine the results using XPath to find particular structures, make changes, and repeat the process until correct results are produced.

Enhanced application definition file (structapps.fm) template available

forums_noreply@adobe.com — Wed, 05 Oct 2011 22:05:22 GMT

Text Structure Consulting, Inc. is pleased to make available an alternative FrameMaker 10.0 template for application definition files such as structapps.fm. Differences between this template and the one used in the structapps.fm file that ships with FrameMaker include:

An application definition file can define both XML and SGML applications. The permitted content of the two types of applications differs. However, the formatting of the application definition file included with FrameMaker does not distinguish them. Instead of prefixing the name of every application with “Application Name:”, the revised template uses “XML Application Name:” or “SGML Application Name:”.
The revised templates add a Comment element, permitted within and between application definitions, that allows you to insert comments in the main flow of an application definition file. Since the trick of placing comments in background flows on master pages is no longer necessary, the revised templates remove the First master page, and moves the comment it contained to a Comment element.
The revised templates add attributes CommentsDisplayColor, CommentsDisplayWeight, CommentsPrefix, and CommentsSuffix to the StructuredSetup highest-level element. These attributes control formatting of comments in the same way that attributes of the same name on the highest-level element of an EDD control formatting of EDD comments.
The revised templates change the prefix for the XmlCharacterEncoding and XmlWriteRules elements to indicate that these elements were supported only in FrameMaker+SGML 6.0.
The revised templates insert a page break before an application definition if the application does not fit in entirety on the current page. Thus, if possible, an entire application definition fits on one page.
The revised template puts the name of the current application definition in the running header of the page.

The template and its EDD can be downloaded from http://www.txstruct.com/app.htm.

Enhanced EDD template available

forums_noreply@adobe.com — Mon, 03 Oct 2011 21:43:31 GMT

Text Structure Consulting, Inc. is pleased to make available

a beta version of its alternative FrameMaker 10.0 metatemplate

(template for EDDs). This metatemplate differs from the one that

ships with FrameMaker 10.0 in several ways, including:

1) Comments are permitted throughout an element definition

instead of only at the beginning or the end

2) Numbering of subrules allows for 6 levels of nesting (instead

of only 3).

3) "If" and "else if" clauses as well as complete format rules

are numbered

4) Documentation elements List, Note, and CommentTable are available.

5) Element type SGMLFragment is defined to facilitate use of text

insets within an EDD

6) Section heads are formatted differently for outer sections and

nested sections (10 levels supported)

7) Color is used to distinguish element definitions for containers

from those of graphics, tables, cross-references, etc. Instead of

assigning colors in the meta-EDD, colors called Table, Marker,

Equation etc. are defined in the metatemplate. Users can therefore change

the color scheme just by editing definitions of these colors.

8) Page breaks within an element definition are minimized

9) Running headers show the tag of the current element definition and head

of the current section

10) Attributes Filter1 through Filter10 are defined on most elements. These

attributes can be used to define filter expressions so that filter

by attribute can be used as well as conditional text to define variations

of an EDD.

11) A brightly colored arrow marks elements defined to be valid at the highest

level (the character and character format used are configurable).

12) Several elements have descriptive tags.

13) Element (and format change list) definitions can be commented out by

changing their element types to CommentElement (and CommentFormatChangeList)

14) Numerous context labels on the Tag element allow the user to generate lists

of all element definitions of a particular type (e.g., all table elements),

or of tags in format change lists, etc.

The template and its EDD can be downloaded from http://www.txstruct.com/metatemp.htm.

Directions for using this tool are included in comments at the beginning of

the EDD. Metatemplates for earlier versions of FrameMaker are also

available.

Please send comments on the provided descriptive tags to lprice@txstruct.com.

Can the wording be clarified? Is it accurate? Which additional element types should

have descriptive tags? Which provided descriptions are unnecessary? The zip file

with the EDD and template includes a list of the descriptive tags in PDF.

--Lynne

Survey: Considerations for Using DITA

forums_noreply@adobe.com — Fri, 07 May 2010 02:03:17 GMT

Survey: Considerations for Using DITA

To help potential users decide whether to use DITA and how much effort doing so would involve, Text Structure Consulting, Inc. is conducting a survey to better understand the documentation projects for which DITA is appropriate. If you are using or considering DITA (or have done so), please take the time to share your experience by completing the survey. Partial and anonymous responses are welcome. You can send your response (embedded in an email message, in Microsoft Word, RTF, Adobe FrameMaker, or PDF) to dita.survey@txstruct.com. If you prefer to answer by phone, you can write to the same address to schedule an interview.

Please forward the survey to other documentation professionals you know who might like to participate. If you are involved in multiple relevant projects or would like to add to an earlier response, feel free to complete the survey multiple times. Answers from different people working on the same project will gladly be received.

Since the survey is being distributed largely by forwarded email, statistically significant results are not expected. Nevertheless, survey responses should help existing users re-evaluate their projects and possibly learn about new tools, potential users evaluate the relevance of DITA, and consultants decide when to recommend it. If an interesting number of responses are received, the results will be summarized on www.txstruct.com and submitted for possible presentation at Balisage: The Markup Conference in early August, 2010 (see www.balisage.org). If at all possible, please respond by June 15 so that information can be prepared for the conference.

The survey questions are available at http://www.txstruct.com/dita.survey/questions.htm and are repeated here:

Personal Identification

What is your name, affiliation, and name of your project?
What is your personal role in your project (e.g., author, editor, manager)?
Are you an end user, consultant, or tool vendor?
Is this a new survey response or a replacement for an earlier response?
Do you give permission for your responses to be quoted in a summary of the results of this survey? Do you want such quotations to be anonymous or attributed to you?

Project Identification

What industry does your documentation represent?
What type of processing does your project involve (authoring, publishing, translating, indexing, analyzing, etc.)?
How many documents or pages do you process annually? How much of this material is new and how much revised?
How do you publish documents (paper, PDF, Web, CD, etc.)?
How many document tool users do you have?
How many people use your finished documents?
Are your documents translated to multiple languages or localized in any other form? Are all documents localized or only some? How many languages do you support?
Are your documents revised and republished?

General software considerations

What documentation software does your project use:? Consider DITA-specific tools, XML tools, content management, word processing, desktop publishing, text editors, database management, project management, spreadsheets, and any other relevant tools.
Do you have software that enforces that writers follow your organization's conventions?
Do all groups within your organization use the same tools? All people in your group?
Is authoring geographically distributed?
How are editing tasks assigned to individual writers or editors? For example, is a writer responsible for a document or document component through multiple revisions, or is an available writer assigned whenever a change is needed? Do writers need specific expertise, such as knowledge of a documented product, to maintain particular pieces of content?
Do you reuse all or parts or your documents? What size units do you reuse? In how many documents does a typical reusable component occur? What percentage of a typical document is comprised of reusable segments?

DITA Considerations

For what types of documents (user manuals, online help, test plans, requirement specifications, journal articles, technical books, technical reports, interdepartmental memos, etc.)
1. Does your project use DITA?
2. Have you considered using DITA but decided not to?
3. Have you never considered using DITA?
Do you use DITA-inspired naming of element and attribute types when you do not use DITA itself?
Do you use DITA maps?
Do you specialize (modify) the DITA tagging scheme? How extensive are your changes? Which of the following do they involve:
1. Rename existing element and attribute types
2. Change the definitions of existing element and attribute types
3. Add new element and attribute types.
How many of the DITA element and attribute types do you use?
What were the primary factors in deciding whether to use DITA (for example, eliminates need to define a tagging scheme, availability of DITA open toolkit, a DITA deliverable is part of the project, wanted to use DITA- based software, recommended by consultant, addresses usability, effort required)?
Who are the primary decision makers on DITA issues (for example, customer, consultant, manager, tools group, writers)?
Do you transform your documents to or from DITA for different types of processing? Explain.
In what circumstances would you recommend that an organization consider DITA?
What have you found surprising about DITA?
How well have the effort, elapsed time, and cost of your solution corresponded to your expectations at the beginning of the project?
How well have the results corresponded to your expectations?
Given the experience you have gained, would you make the same DITA-related decisions now?
What version(s) of DITA do you use? Are you planning to use any others? When?
What changes to DITA or the Open Toolkit would you like to see?
What changes to your processes do you plan?

Other comments

Please make any other relevant comments.

Interaction of XSLT pre-process and default attribute names

forums_noreply@adobe.com — Wed, 10 Mar 2010 17:49:57 GMT

This message is not a question, but a report of some unexpected behavior that some of you might find interesting.

When FrameMaker interprets an XML document, it assumes that some XML attributes represent FrameMaker properties, whether or not the XML attributes also map to FrameMaker attributes. In my experience, the XML attributes that most often correspond to both FrameMaker properties and FrameMaker attributes are the entity attribute of a graphic and the cross-reference id attribute of a cross-reference.

I have an application with a DTD that includes a cross-reference element named cross_reference. The EDD (and hence the import template) defines an IDReference attribute called idref. There are no read/write rules pertaining to the cross_reference element or its attributes and no XSLT pre-process. When I open an XML document using this application, the expected behavior occurs. In particular, input such as:

<cross_reference format="fmt" idref="xyz"/>

imports correctly, creating a cross-reference element named cross_reference that uses cross-reference format fmt. The idref attribute of the FrameMaker element is set to xyz and the cross-reference source is the element with a UniqueID attribute set to xyz.

However, when I add an XSLT pre-process, import of this element fails. The log file contains an error message for each cross_reference to the effect that no ID reference has been specified. The resulting FrameMaker document has values for the idref attributes, but they don't seem to have been used to set the cross-reference source. Adding a read/write rule:

element "cross_reference" {

is fm cross-reference element;

attribute "idref" {

is fm property cross-reference id;

is fm attribute;

}

solves the problem. The format attribute was processed correctly without a r/w rule. I do not understand why the use of XSLT affects FrameMaker's default processing, but it does.

I have confirmed this behavior in FM8 and FM9 but have not tested in earlier versions.

Formatting catalogs vs. explicit formatting properties in an EDD

forums_noreply@adobe.com — Fri, 03 Jul 2009 23:52:43 GMT

The bulk of the discussion on "Exporting Paragraph Catalog to EDD" (http://forums.adobe.com/message/2083552#2083552) deals with whether EDDs should apply specific formatting properties or apply named formats defined in the document's paragraph or character catalogs. Since that is a worthy topic in its own right, I am giving my response in this new thread.

Frankly, most of the responses to this part of the discussion are simply expressions of personal opinion. I'm a proponent of personal opinion and one of FrameMaker's strengths is its flexibility in supporting different users' preferences. However, I would like to point out in this case there are various technical reasons to use one or the other of these particular techniques.

1. The ability to specify individual formatting properties allows an EDD's context and level rules to specify context-sensitive variations of a base format. For this reason, the term "hierarchical styles" can be used to refer to this approach. Hierarchical styles allow an EDD to apply relevant formatting in the definition of the element that triggers that formatting.

Suppose, for example, that list items contain a sequence of paragraphs and notes and that notes contain a sequence of paragraphs and lists. Further suppose that both lists and notes are variations of the document's base format in which lists are indented and notes are italicized. One approach in the EDD is to assume the paragraph catalog includes formats called Body, Indent, Italics, and IndentItalics. The definition of the paragraph element can then apply one of these formats depending on whether the paragraph is within a list, within a note, within both, or within neither. Alternatively, the definition of the list element can change the indentation without considering whether or not the content is italicized and the definition of the note element can change the angle without considering the indentation.

Using hierarchical styles mean any changes to the base format (by default, Body) do not have to be replicated in numerous variations. The paragraph catalog thus is smaller and hence easier to maintain. Furthermore, no explicit testing for lists within notes or notes within lists is needed. Finally, the formatting is specified where it logically belongs. The developer specifies the list-motivated indention when defining the list element and the note-motivated font change when defining the note element instead of worrying about both of them when defining the paragraph element.

2. If an EDD is based on existing unstructured documents that already have rich paragraph and character catalogs it is often practical to use the existing formats rather than to copy their properties into the EDD.

3. There are numerous FrameMaker plug-ins that operate on paragraph and/or character formats. If the organization's workflow involves such plug-ins, hierarchical styles cannot be used.

4. Using formatting catalogs allows one EDD to be used with multiple templates that define the named formats in different ways. For example, variant templates may use language-specific autonumbers or set indentations and tab stops for different page styles.

Furthermore, note that an EDD developer can choose to refer to formatting catalogs or use hierarchical styles for some cases and use the other technique for others. For example, the developer may refer to the paragraph catalog for various levels of section headings but use hierarchical styles for variations of body paragraphs (such as the lists and notes discussed above).

--Lynne

Overriding the format rules in a structured document

forums_noreply@adobe.com — Sat, 04 Jul 2009 02:42:45 GMT

Some of the later messages in the "Exporting Paragraph Catalog to EDD" thread (http://forums.adobe.com/message/2083552#2083552) dealt with the use of overrides to the formatting specified in an EDD rather than with exporting paragraph catalogs. I've therefore started this new thread for my reply.

Structured FrameMaker was deliberately designed to support the needs of organizations who want all element formatting to be controlled by the element catalog as well as organizations who want to allow overrides. Reasons for the latter include tweaking of page breaks and spacing by a production group after all editing is complete as well as addressing publication schedules that may require publishing a document with a planned structure that has not yet been incorporated into the EDD.

Arnis's observation that organizations in the first category can use FrameMaker's configurable user interface to remove access to formatting commands is a good one. It is not enough to remove the paragraph and character designers; much of the Format menu as well as shortcuts for applying some format changes should also be disabled.

The workflow used in other organizations removes any overrides a writer may have applied. Before a document is published, element definitions (either from the organization's latest approved template or the current document) are imported, with the box to remove overrides checked. Publication may also require that a document be validated without error.

--Lynne