I'm currently checking if there is an easier way to automatically add <b> tags when changing font style to Bold in your xml. I'm not sure how to override the format of a structured application automatically in FM. Do I need to create a script for this? Or is there any configuration that can be made to make this work automatically?
This question does not make much sense to me. Changing font style in XML does not have a meaning. Applying <b> tags does have a meaning but what do you mean with "automatically" adding those <b> tags. You need to be much more elaborate in asking your question. Tell us exactly what you are doing, and in which environments. What is the goal you are trying to achieve?
I have created a DITA structured application with defined template and EDD. My document is rendered using the format and styles defined in the EDD. There are cases when I need to override the format of my document. In DITA, bold is written inside b tags, i.e. <b> this is bold </b>. When I try to edit my document change font style to bold using menu bar, Framemaker does not automatically add these b tags. Hence when I save the document and open it again using my structured application, the bolded part is not saved. In order it to be saved, the b tags should be written in the XML. I dont know if there is an automatic way? Or need to write an extendscript on Save?
OK, now I understand what is happening. You need to make the toolbars with formatting options go away in your FrameMaker and NEVER touch them again. Formatting should NOT be done with those functions. In fact, formatting should not be done at all except by wrapping a piece of text in a <b> element, which is available from the Element Catalog.
If you are working in FrameMaker 11, the safest way to edit your documents in a more or less WYSIWIG fashion is to use the Author View. If you are working in an earlier version of FrameMaker, simply hide the formatting toolbar so that you cannot make this mistake anymore.
I don't think you are quite getting it yet. The user, meaning an author, who is working on a structured document, should simply insert a new <b> element and type whatever text is supposed to go into that <b> element. If a piece of text is already there, the author selects the text, selects the <b> element in the element catalog and wraps the text into the <b> element, instead of inserting an empty <b> element and then start typing. There is absolutely no need for the functionality you are asking for, as all of this is already available.
Ah yes I understand the operation you suggested. However our user might want to have an explicit way to let them know they are making it bold, hence, I'm thinking if I can create a toolbar "Bold" to simulate such operation?
No, I don't think that is a good idea. Either your user has no idea what they are doing in a structured editing environment, which means they should keep their hands off the content. Or the user can be shown that inserting a <b> element is just the same as inserting a <p> or any other element in a structured editing environment.
If your users have no idea about structured authoring, they should get educated before allowing them to do anything to your DITA materials. Unstructured thinking in a structured environment WILL lead to a total mess. There is no way your users can get the benefits of a structured editing environment without learning the basic rules. Inserting a <b> element to make something appear bold is as basic as it gets.
I have some disagreement with Jang here, despite our normally close relationship . As an author, I have been thinking for a while how nice it would be to have shortcuts for inserting/wrapping elements, based on simple formatting like bold. I would like to select text, then click a "Bold" button (or even just do Ctrl-B) and have the <b> element wrap automatically. I disagree that this points to a lack of education or a violation of the structured authoring paradigm. I think it is just a way to make things quicker for people who have to author a lot.
ExtendScript (or the FDK) would be very capable of this task. Since there would be lots of settings (ie, what tags to wrap for what actions), ExtendScript might be better since it is so much easier to make quick configuration changes. Plus the GUI capabilities are so much richer, especially if you want something like a toolbar.
I am almost sure to build a version of this myself in the near future. I'm not saying that I plan to build it for public release, although I might let it out. The point I'm trying to make is that I think it is a good idea and scripting would be the path to achieving it.
Most of the discussion on this thread has dealt with the relevance of the Bold button on FrameMaker's Text Formatting toolbar to structured documents.
While someone made the suggestion to create a <b> element and then insert text within the new element, I don't think anyone has yet commented on how easy it is to wrap an element (<b> or another element) around existing content. You can do so with the Element Catalog. Simply select the content to be wrapped and double-click the tag of the new element (e.g., b) in the Element Catalog. Or click the tag in the Element Catalog and then the Wrap button at the bottom of the Catalog.
If you prefer to use the keyboard, you can use what is called Smart Insert in FM 11 and quick keys in earlier versions. The first three buttons at the bottom of the Element Catalog window are Insert, Wrap, and Change. You don't need to have the Catalog open to use Smart Insert. I mentioned the buttons only because that order is pretty easy to remember--1. Insert, 2. Wrap, 3. Change. The keyboard shortcuts Ctrl-1, Ctrl-2, and Ctrl-3 bring up the Smart Insert or Quick Keys to Insert, Wrap, or Change an element. With Smart Insert, a pop-up menu appears that shows the available elements. You can use the up and down arrow keys to navigate to the one you want, or type a unique prefix. Then press Enter to perform the operation (or Esc to cancel). With Quick Keys, the left side of the status bar at the bottom of the document window or Structure View (whichever is current) will prompt for the element tag with I: for Insert, W: for Wrap or C: for Change. Again, use the arrow keys or a prefix to display the desired element tag and then press Enter.
So, to create a new <b> element to hold an existing string, select the string, type Ctrl-2 b, and press Enter.
That said, I will close with an observation on the use of format overrides in structured documents. While automatic formatting based on element structure is the heart of structured FM, the software was deliberately designed in recognition that as a practical matter it is sometimes necessary for an author to create formatting that the document's element definitions simply do not provide. It therefore allows the user to tweak the formatting (for example, by deliberating making some content bold without using the element structure to do so). Users should understand the difference between element-based formatting and format overrides and use the latter with care if at all.
I would immediately fire someone who was using direct formatting (without applying structured elements) to any content that is supposed to be a structured document. Or maybe I would not fire the person but first show how the format disappears whenever I output my materials to a number of different formats and possibly roundtrip it to XML. And I would make sure that processes were put in place to automatically clean up any direct formatting in documents before they are accepted into a CCMS.
Anything that cannot be expressed using the available semantic tags should either lead to a proposal to add a semantic tag for that and similar cases (which should be vigorously scrutinized before being accepted into the DTD / EDD ) or to another way of expressing whatever the author was trying to express. Grabbing the formatting toolbar to apply quick and dirty formatting is <emphasis>not</emphasis> what a structured content author should ever do.
What I like most about the Author View in FM11 is that there are no formatting toolbars. Let's rid the world of formatting that is not applied by style sheets, i.e. strict formatting rules. Content will become clearer and more reusable that way.
Great tips. I still think, though, that a simpler way to apply common formatting would be tops. I really want to press Ctrl+B (or the toolbar button) and automatically get a <b> element, which is what I think the OP really wants too. I don't think there was ever any intent to use format overrides; rather the desire is a way to use those tools to apply the legitimate structure.
I think I will release this thing once I write it. I'll make it work for unstructured docs too, such that a character format can be applied, instead of an element. But I'm kind of busy, so don't anyone hold their breath.
Don't get me started on the risks of users formatting their own structured documents. Directly applying formatting properties is only one way to do so. Others include manipulating white space (particular spaces, non-breaking spaces, and forced returns) and tag abuse (choosing an element that is not logically appropriate but produces a desired appearance).
I agree completely that these are techniques that should be avoided if at all possible and with your approach of demonstrating how they fail when the material is re-used, when a template is updated, when material is saved as XML. Neverthless, some organizations prohibit such techniques; others rely on them. FM was designed to support both groups.
Consider for example, final production editing that tweaks page breaks, possibly adjusting line or paragraph spacing or font size to do so. Should elements and attributes be defined for this much control? Maybe, maybe not, especially if the relevant settings are to be restored to the defaults for the next version of the document.
Or consider a writer who was requested an EDD enhancement that has been approved. What should the writer do if his deadline is before the EDD developer's?