Skip to main content
QuintinSeegers
Legend
March 9, 2022
Answered

Globally change font (Structured FM2019)

  • March 9, 2022
  • 2 replies
  • 993 views

Here's our scenario:

We typically produce our training documentation in PDF. Occasionally, we agree to provide a client with an MS Word version of the documentation so they can add client-/process-specific details for their internal use. In the later case, we produce the document to PDF as normal, then use Adobe Pro to convert it to MS Word. (There is a bit of tidy-up in the MS Word version to do, but let's ignore that for now).

When we produce the documentation to PDF, we use a corporate (commercially bought) font (let's call it Font A). When we will be converting the PDF to MS Word, we currently have to go through and update all the paragraph styles in MS Word to use a common (free) font (let's call it Font B).

We don't use DITA or XML. We don't want to go down the route of using Paragraph Styles in FM - we moved away from that because our writers would constantly change the properties on the Paragraph Styles to how 'they like things to look', instead of keeping with our corporate style guides. We have a Base Paragraph Style (FormatChangeList) specified in our EDD. The formatting of every other Element is based off this Style (with modifications where needed) thought the use of FormatChangeLists.

Is there a way to specify which font to use based on the 'output' via the EDD (without having a separate EDD for the eventual MS Word version)? I envisage something like an Attribute at Book level that states if the output is PDF, use Font A, if the output is MS Word, use Font B.

    This topic has been closed for replies.
    Correct answer Lynne A. Price

    Quintin,

        There are several ways you can defined your EDD and templates to work together to support using different font families for different books:

    1. If you always specify fonts in paragraph, character, or table formats, you can maintain two parallel templates, one using Font A and the other Font B. To switch between the fonts, import formats from the appropriate template into a structured document. No need to change the EDD.

    2. As you suggest, you can add an attribute that indicates which font set you want to use to the root element for each type of book. In this case, your EDD can assign fonts based on the attribute value. Remember that the format rules can specify paragraph or character formats or individual properties (a combination of the two approaches is also possible). If your format rules only specify properties, it is sufficient to specify the font family in a rule for the root element so that all elements inherit the correct font family. If you apply paragraph and character formats throughout the EDD, you may need to reassign the font family after applying formats from the catalogs.

    3. You can maintain parallel EDDs for the two outputs. If the only difference between the two is in the fonts, you can use one or more variables in the EDD to refer to needed fonts or font families. Instead of maintaining two complete EDDs, for each variation, you can create a short file that defines the variables that variation. Then import variable definitions from one of these separate files into the EDD to creatte another version of the EDD. This approah is a little more complicated but gives you more flexibility. A script or FDK client can help maintain such sets of EDDs.

     

    Let me know if you'd like more detail on  any of the above.

     

    --Lynne

     

    2 replies

    Lynne A. PriceCorrect answer
    Inspiring
    March 10, 2022

    Quintin,

        There are several ways you can defined your EDD and templates to work together to support using different font families for different books:

    1. If you always specify fonts in paragraph, character, or table formats, you can maintain two parallel templates, one using Font A and the other Font B. To switch between the fonts, import formats from the appropriate template into a structured document. No need to change the EDD.

    2. As you suggest, you can add an attribute that indicates which font set you want to use to the root element for each type of book. In this case, your EDD can assign fonts based on the attribute value. Remember that the format rules can specify paragraph or character formats or individual properties (a combination of the two approaches is also possible). If your format rules only specify properties, it is sufficient to specify the font family in a rule for the root element so that all elements inherit the correct font family. If you apply paragraph and character formats throughout the EDD, you may need to reassign the font family after applying formats from the catalogs.

    3. You can maintain parallel EDDs for the two outputs. If the only difference between the two is in the fonts, you can use one or more variables in the EDD to refer to needed fonts or font families. Instead of maintaining two complete EDDs, for each variation, you can create a short file that defines the variables that variation. Then import variable definitions from one of these separate files into the EDD to creatte another version of the EDD. This approah is a little more complicated but gives you more flexibility. A script or FDK client can help maintain such sets of EDDs.

     

    Let me know if you'd like more detail on  any of the above.

     

    --Lynne

     

    Known Participant
    October 14, 2024

    Hi Lynne,

     

    I also have the similar problem with fonts, although it's simpler than the OP's.

     

    I only wish to set my family fonts to Open Sans, and let each styles manage its own sizes, colors, etc. I suppose I just have to replace the base element's family font, and let all the other elements derive from that one. The problem is I don't know which element is the base.

     

    Working with DITA, and I am using FM's supplied EDD.

     

    Regards,

    Andy

    Matt-Tech Comm Tools
    Community Expert
    Community Expert
    October 14, 2024

    As Lynne alluded to in the previous post, the EDD and paragraph catalogs blend together to apply formatting.

    You can have some properties "hard coded" in the EDD, while allowing the paragraph catalog to apply paragraph formats for other properties.

    This allows for context (based, for example, on output intent or on position within structure)

    It's not overly complex editing, if you are modestly experienced with EDDs and templates, but you'll be editing a number of EDDs and templates, so keeping track of original copies of your edited resource files (templates, etc.) is highly encouraged!

    If you're not yet comfortable editing EDDs, here's a link to the TOC for my EDD Development workbook 

    Folks often my workbook as a reference for editing EDD

     

    -Matt Sullivan, FrameMaker Course Creator, Author, Trainer, Consultant
    Dave Creamer of IDEAS
    Community Expert
    Community Expert
    March 9, 2022

    How can you be using an EDD and elements, but not XML or DITA? Are you using SGML?

    [Edited--I was passing a brain stone...]

     

    I think there are a few ways to do it.

    One way would be to use different root elements (with all the descendent elements being the same). Swap them out as needed; it can apply the base Body format settings. 

    Or you can use attributes and contextual format options. 

     

    A completely different route is to remind the writers that they are professionals and to leave the settings alone if they value their jobs!

     

    David Creamer: Community Expert (ACI and ACE 1995-2023)
    QuintinSeegers
    Legend
    March 9, 2022
    quote

    How can you be using an EDD and elements, but not XML or DITA?

    I have to ask. Why is there the assumption that, if you're using Structured FM, you have to use  XML, DITA or SGML? We using neither with Structured FM and is working very well for us and our needs.

     

    We've converted from unstructured to structured FM in the last 3 months. Our document formatting is very customised and doesn't correspond to any of the default DITA formats. DITA also won't work well for how our documents are structured. Moving to XML is the long-term goal, but I'd have to write the translations from scratch.

    quote

    One way would be to use different root elements (with all the descendent elements being the same). Swap them out as needed; it can apply the base Body format settings.

    Our Root elements identify the type of document, e.g. Book, Chapter, Checklist, etc, with only the appropriate Elements available for those types of documents. I'd have to investigate how this would practially work for us.

    quote

    A completely different route is to remind the writers that they are professionals and to leave the settings alone if they value their jobs!

    Our document creators are not technical writers by profession, (they're consultants doing ad-hoc documentation as/when needed) so I use the term 'writers' very loosely.

    Dave Creamer of IDEAS
    Community Expert
    Community Expert
    March 10, 2022

    OK--so you are using structured mode just to control the formatting. Is that correct?

    If so, manual overrides could still be applied, however, I believe if you use XML files in a book instead of FM files, overrides are removed. (I'll let greater minds than mine confirm that...)

     

    Either the Chapter element could have attributes with contextual formatting--or have a set of elements that must follow Chapter that set the font. 

     

    My last line was a joke--should have added a smiley...

     

     

    David Creamer: Community Expert (ACI and ACE 1995-2023)