Need a space after </keyword>

[lief_erickson1]

FrameMaker 11

DITA 1.2

I am having problems with keyword references. It was the same problem I was having with my FrameMaker variables, which I have abondoned in favor of a "cleaner," pure DITA solution. When I insert a conkeyref like in the the shortdesc everything appears fine.

<shortdesc>You can grow the size of your <keyword  conkeyref = "keywords/prodcut_name"></keyword> by adding additional drive units if you are running low on disk space. </shortdesc>

After I save the file, close it and reopen it, the space after </keyword> is removed so that it reads </keyword>by. What is causing this? I can't simply add a space to my product_name definition because there are times when I need punctuation after the it.  I suspect has to do with how FrameMaker processes the conkeyrefs because when I manually put spaces after all of the conkeyrefs and then choose DITA > Update References FrameMaker will go through my document and update all conkeyrefs and remove the trailing space. Where is this behavior set or defined?

-Lief

[Russ Ward · Accepted solution]

Hi Lief,

Thanks so much for this post. It reminded me about something that was introduced in FM10 that IMHO is a terrible bug and caused me hours of trouble to restore the damage it did. And, I was never able to fully track down all the damage, so to this day I still find problems that it caused.

Anyway, while your post helped me a lot because it inspired me to check my FM11 installation, I don't know if my answer will help you   But it is worth a try.

In your maker.ini file, by default there is the following setting:

RemoveExtraWhiteSpacesOnXMLImport=On

This is an abhorrent setting that aggressively removes whitespace in various situations, some of which sound like the case you describe. Try turning it off and see what happens. To be sure, turn it off in both copies of maker.ini... the copy in your installation directory and your user profile area (Documents and Settings > etc.)

Checking my FM11 installation, I see the setting is still turned on by default. I'm ranting here, but for the life of me, I can't fathom how a desktop publisher is being released with a setting that involuntarily alters your source files. I also don't understand why anyone producing literary content would desire this sort of whitespace normalization. I was told to submit a bug report back with FM10, but I never got around to it thinking surely that this mistake would be caught and fixed. I'm heading to the bug report area now.

Russ

[lief_erickson1]

Hi Russ--

Thank you so much. That was exactly the issue. You deserve eleventy billion bonus points.

-Lief

[lief_erickson1]

Well, it solves one issue and introduces another...<WHITESPACE>. In many ways, this is a more annoying problem to look at while authoring, but is more easily solved come production time.

[Russ Ward]

Lief,

Can you be more specific about the new issue? I'm really trying to understand what this setting is for.

Russ

[lief_erickson1]

FrameMaker is trying to be helpful and intelligent about something that is required by the XML spec. The spec requires that XML renderers respect all spaces and tabs as valid characters that must be passed along untouched, but it is these spaces and tabs that make a pretty printed document "pretty printed" and more readable by humans. The only time one would care about a document being pretty printed is if they are looking at the XML view. By pretty printing a document one creates whitespace by definition. Therein lies the struggle.

With RemoveExtraWhiteSpacesOnXMLImport=On FrameMaker removes/ignores all of the whitespace creating by pretty printing your document. Typically, this is a great and wonderful thing and for the most part does what it is designed to do (i.e., ignore whitespace introduced by pretty printed files), but the side effect is that it also removes the space after my conkeyref. Here's where you and I would probably agree that there is a FrameMaker bug. It should leave that space while ignoring other whitespace.

With RemoveExtraWhiteSpacesOnXMLImport=Off: FrameMaker honors all of the spaces and tabs of a pretty printed document, but those appear in Author/WYSIWYG view, which then also appear in your output. But because whitespace is not removed, the space that I require after my conkeyref is present.

Our solution is going to be to live with the whitespace created by pretty printing our files right up until we need to produce a document. At that point, we'll remove the whitespace (which can be done by "linarizing" the file using a tool such as Notepad++), produce our document in FrameMaker, and re-pretty print it. Of course, this is going to be a huge hassle with a couple thousand files. If we had to produce more frequently than we do or were a bigger shop, this would be an unacceptable solution.

[Russ Ward]

Lief,

Thanks for the explanation. I can understand that on the surface, but I can't understand why you would pretty-print the file in the first place. The concept of pretty-print seems incompatible with a documentation source file, which should be about pretty-publish instead. Whitespace can be significant in documentation, especially when you get into the area of presenting things like code samples and XML snippets. You could get into the situation where pretty-printing prevents you from being able to publish a pretty-printed XML sample, if you get where I'm going.

I don't mean to be dense here. I'm really just trying to figure it out. And, I'm still a bit steamed about what that setting did to my source files. Were I not also an FDK developer who could automate much of the restoration, it could have taken days to sort out.

Russ

[Russ Ward]

...and, I just read again that you said "required by the XML spec."  Pretty-print is required?

[lief_erickson1]

Yes, you're right, it should be for pretty-publish, but we also want to be able to easily diff/compare files, too.

We're looking at this from another angle based on info here: http://www.scriptorium.com/2010/01/removing-whitespace-structured-framemaker/

It may take some time, but I'll post back what we determine.