Skip to main content
E
Engineer_technical_writer
Known Participant
October 14, 2014
Answered

How to create a frame or box to surround a element

  • October 14, 2014
  • 1 reply
  • 518 views

Hi,

Would appreciate some help on this one, as I can't seem to figure it out.

How do you create a frame or box to surround an element, for example when using Hazardstatements.

The only way I can think of is to use tables, but is there any other way?

Example:

Danger
Some warning text
Some warning text

Thanks

Best regards

Ronny

This topic has been closed for replies.
Correct answer ScottPrentice

Hi Russ...

You're completely correct .. I should have explained where my response was coming from. There's nothing fundamentally wrong with wrapping a hazardstatement in a table to achieve some desired formatting.

My reply was based on the DITA (XML in general) premise that your source files should only contain "content" with minimal or no "formatting." Wrapping a table around a hazardstatement definitely falls into the "formatting" camp. Adherence to this guideline is completely dependent on your needs and in-house style and processing requirements.

Personally, I'd avoid needing to perform this extra step each time I added a certain element, when it can be done through automated means. This is a common problem for "notes" in general. People are inclined to want to add icons and other decoration into the source files because that's what they did in unstructured FM. I think it just adds more work to the authoring process and makes your content less modular and flexible, and potentially less consistent. Unless you're really only producing content for one deliverable (PDF), you likely shouldn't care about formatting while authoring. Get the content into the source file, then let the publishing process apply the formatting (including icons and other common formatting) for each deliverable.

Cheers,

…scott

1 reply

ScottPrentice
ScottPrentice
Inspiring
October 14, 2014

Hi Ronny...

It's of my opinion that there while you may want this content formatted as a table when published, you should not be authoring the content with a table to achieve that formatting. This type of formatting should be applied as a "publishing process" after the DITA topics are assembled into a FM book and FM chapter files. If you're publishing to other formats (like HTML), the formatting can often be achieved through CSS or by other publishing processes. You don't want your source files to enforce some type of formatting that may differ depending on the deliverable.

You may want to set up some ExtendScript wrapper that performs various pagination and formatting tasks to your generated FM files. While you can use ExtendScript to actually wrap the hazardstatement in a table, you can also look into using other tools such as FrameSLT (from West Street Consulting), or Structure Snippets (from Leximation, my company).

     http://www.weststreetconsulting.com/WSC_FrameSLT.htm

     http://leximation.com/tools/info/structuresnippets.php

Cheers,

Scott Prentice

Leximation, Inc.

www.leximation.com

R
Russ Ward
Legend
October 15, 2014

Hi Scott,

While I understand your response, it seems like a very complicated solution. If I wanted a warning to look like this, likely I'd want it that way in every format that I publish. So, I would think that a table would be the preferable solution. In any case, to answer Ronny's original question... a table is really your only option for this type of layout, especially in a structured FrameMaker document. And personally, I see no downsides to using a table, if you can set up a format that consistently provides the appearance you want.

Russ

ScottPrentice
ScottPrenticeCorrect answer
Inspiring
October 15, 2014

Hi Russ...

You're completely correct .. I should have explained where my response was coming from. There's nothing fundamentally wrong with wrapping a hazardstatement in a table to achieve some desired formatting.

My reply was based on the DITA (XML in general) premise that your source files should only contain "content" with minimal or no "formatting." Wrapping a table around a hazardstatement definitely falls into the "formatting" camp. Adherence to this guideline is completely dependent on your needs and in-house style and processing requirements.

Personally, I'd avoid needing to perform this extra step each time I added a certain element, when it can be done through automated means. This is a common problem for "notes" in general. People are inclined to want to add icons and other decoration into the source files because that's what they did in unstructured FM. I think it just adds more work to the authoring process and makes your content less modular and flexible, and potentially less consistent. Unless you're really only producing content for one deliverable (PDF), you likely shouldn't care about formatting while authoring. Get the content into the source file, then let the publishing process apply the formatting (including icons and other common formatting) for each deliverable.

Cheers,

…scott

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices