ITauthor

Scrolling up and down a document using the mouse wheel can be a problem in FrameMaker. Sometimes it works, sometimes it doesn't. I have identical FrameMaker setups at work and at home, and scrolling works at home but not here at work. I finally got fed up with this and decided to sort it out. Unfortunately, updating the driver for the Intellimouse did not fix the problem. However, a good solution is to install KatMouse by Eduard Hiti: http://eduard.hiti.bei.t-online.de/ This changes the scrolling functionality, making the scroll wheel apply to whichever application happens to be under the mouse pointer - including FrameMaker windows. This sounds odd, but once you start using it it's really useful - especially in structured FrameMaker, where you can scroll the Structure View window without losing the focus in the document window. When I'm using FrameMaker I have the Structure View window permanently displayed on a second monitor, so I find this behaviour particularly useful.

XML produces functional, but very ugly, XML. I've had a look today for ways to remedy this. The reason for doing this is that the XML may need to be edited in its raw state occasionally, and this would be much easier if it was indented to display the element hierarchy. I tried:

• Tidy and TidyUI - but these didn't recognize entities such as / and just deleted them. TidyUI also removed spacing from within a literallayout element, which is just plain dumb
• xmllint and xsltlint - but in researching possible tools I read warnings about xmllint and so I wasn't confident about using them
• xmlformat - I had most success with this. I tried the Perl version, which worked fine from a DOS command console in Windows. It produced nicely formatted XML, without the problems TidyUI had, but on import into FrameMaker, some of the formatting spaces showed up in the FrameMaker text (e.g. as spacing to the left of subheadings)

I suppose the solution, if you really wanted to do this, would be to format the XML with xmlformat, work on the formatted XML, then remove the formatting before opening the file in FrameMaker. xmlformat allows you to create a configuration file specifying how you want to format the XML, which would allow you to have a "prettyprinted" config file and a "noformatting" config file to remove the spacing. One of the things I like about xmlformat is that it appears to be very well documented. Get xmlformat from: http://www.kitebird.com/software/xmlformat/

FrameMaker 5.5 used to intermittantly crash, with a large but unhelpful error message that would make your heart sink every time it appeared. I never encountered this error in FrameMaker 7.0, but now, in 7.1, it has returned. For the third time this week, the dreaded error has appeared: Read the rest of this entry »

It was good to discover that "preserve line breaks" now works in FrameMaker 7.1. In version 7.0, adding this to the read/write rules:    element "literallayout"    {       is fm element "LiteralLayout";       preserve line breaks;    } didn't work. Here's the rant I discovered in my read/write rules file from FrameMaker 7.0: /*** Don't use "preserve line breaks;". It doesn't work, because it inserts 'xml:space = "preserve"' in the XML, which is invalid DocBook. Also, it adds this attribute to any child elements, but, despite this, doesn't actually preserve the line breaks into the XML unless you add "preserve line breaks" to every element that might come within LiteralLayout (most elements). This would result in almost every tag in your XML having 'xml:space = "preserve"', which is nonsense!!! It also doesn't preserve FM carriage returns (which you'll have if you've copied text into an element within LiteralLayout. It only preserves forced line breaks (i.e. those you've added manually using Shift+Return). All in all, it's totally useless!!! ***/ It all now seems to work fine in 7.1. The comment about adding "preserve line breaks" to every element that might come within LiteralLayout was a red herring because LiteralLayout can only contain inline elements, and will rarely contain any of those anyway. The only thing you need to remember is to use a line break (Shift+Return) not a new paragraph (Return) to start a new line, and if you want multiple spaces you should switch off smart spaces (Format > Document > Text Options) or use en spaces (Alt+Ctrl+space).

After a long stretch writing online help, I'm now back to using FrameMaker. I wrote a large structured document in FrameMaker 7.0 last year, and subsequently persuaded my company to buy version 7.1, early this year, but since then I haven't had a chance to use 7.1 for structured documents because the only manual I've worked on since then is a legacy unstructured document that started life in FrameMaker 5.5. I did a great deal of work last year trying to get FrameMaker 7.0 to do three things: a) Roundtrip without losing anything along the way. b) Store documents as XML that validates against the xDocBook DTD. c) Store documents as XML, that uses standard DocBook elements for things like index references and cross-references. Frame 7.0 failed on all accounts, but now (from a brief tryout this afternoon) version 7.1 seems to do part a) successfully, and will, I'm pretty sure, do b) too. I don't think it will ever do part c) successfully, because it uses processing instructions like for cross-references etc. However, I'm sure I could use XSLT to transform FrameMaker XML output into standard DocBook XML, should the need arise. More useful, probably, would be an XSL transformation to turn DocBook into FrameMaker XML for importing into FrameMaker, as this would allow programmers to write documentation in DocBook markup, including cross-refs and index refs, using standard DocBook elements, and I could (after transforming it) pull their work straight into Frame for editing, polishing and output to PDF. Two bug-bears of mine with FrameMaker 7.0 were that I had to invent a very contrived way of doing conditional text, and I couldn't get literal text to output properly to XML at all. Fixing conditional text was Adobe's main selling point of 7.1, and formed the bedrock of my case for spending company money on buying the upgrade. However, I still need to see whether literal text survives the roundtrip. But I was very pleasantly surprised this afternoon when I took a chapter from the structured manual I wrote last year - created in FrameMaker 7.0 - saved it to XML, using the Save As option, then opened the resulting XML document and it came back looking just like it had when I opened the original .fm file. Another good step closer to my goal of storing documenation as XML source, so that we can maintain it in a CVS repository, and so that non-FrameMaker users can make use of it and can contribute documentation that we can use within FrameMaker.