Exit
  • Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
  • 한국 커뮤니티
0

How to prevent FrameMaker eating up significant whitespace

Advocate ,
Jun 10, 2014 Jun 10, 2014

I have a paragraph that contains a number of inline elements, such as a <link> and a <uicontrol>. When these are only separated by a whitespace (which is significant in this case, as it separates the characters in the <link> from the characters in the <uicontrol>, the XML file produced by FM has replaced the whitespace with a carriage return, which of course disappears as it is supposed to be meaningless in XML.

I have tried to set the "preserve line breaks" rule on the enclosing <p> element but, apart from the fact that this is not what I intend to do, it does not make any difference on the whitespace between the two inline elements.

Is there any way to make FM not perform this obvious mistake? Or do I really have to use ExtendScript to first change the whitespace to a special <whitespace> character, so that this is kept in the XML output and can then be changed back into a regular whitespace by my XSLT (which I need in any case). Kind of ugly but it would work. If there is an easier way to do this, please tell me about it.

Ciao

Jang

TOPICS
Structured
728
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Jun 10, 2014 Jun 10, 2014

Hi Jang...

What FM version are you using? If FM11 or 12, are you using XML view (in FM11, that caused whitespace problems)?

You might try changing the setting of RemoveExtraWhiteSpacesOnXMLImport in maker.ini (if it's On turn it Off, if Off, turn it On).

Rather than use the "preserve line breaks" rule, if you set the "writer line break" rule on the enclosing <p> that should "fix" the problem ..

     writer line break is 99999 characters;

FM should not be stripping CRs, but "normalizing" them with the other surrounding whitespace characters. A CR should be treated like any other whitespace (space or tab), which would collapse it into a single space. FM12 should be doing this correctly. FM11 had some lingering issues in this regard. In all cases, make sure you've got the latest FM patch installed.

Just out of curiosity .. have you tried this with DITA-FMx? It *should* work properly there. If it doesn't please send me a sample file.

Cheers,

…scott

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advocate ,
Jun 10, 2014 Jun 10, 2014

Hi Scott,

I am using FM12 and no DITA-FMx, as the materials are not DITA at all. I have found a solution, as the CR in the produced XML is treated as a whitespace when I tell the XSLT to preserve whitespace on the <p> elements. It just seems a little odd that a whitespace is changed into a CR, which normally has no meaning in XML.

Ciao

Jang

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Jun 10, 2014 Jun 10, 2014

Hi Jang...

Frame wraps the XML after some number of characters (not sure what the default is). You can use the writer line break rule to specify a different number of characters to wrap after. Using a very large number means that it won't wrap (under normal conditions). This is not a DITA-FMx feature .. default FM.

Changing a space into a CR shouldn't be a problem in XML since it should be treated just like any other whitespace (CR is whitespace just like tab and space). What's bad is that FM isn't apparently interpreting this CR properly. It should be adding a space not deleting it.

Cheers,

…scott

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advocate ,
Jun 10, 2014 Jun 10, 2014

Hi Scott,

Thanks for the info. I might use it in one of my other projects, e.g. when there is no XSLT or there is roundtripping involved. For the moment the problem has been solved in XSLT.

Ciao

Jang

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Jun 10, 2014 Jun 10, 2014
LATEST

Jang,

    I started to suggest you do some testing without XSLT to see if that makes a difference. Or try setting <xsl:output indent="no"/>. However, I've just done some testing of my own and suspect you've encountered a bug.

   Is your <link> element a cross-reference?

    According to the FM 11 INI Reference, RemoveExtraWhiteSpacesOnXMLImport is used to control whether multiple adjacent spaces are treated as a single space. Nevertheless, I just created a variation of the xdocbook application from which I removed the custom API client. This application has paragraph elements with numerous possible inline subelements. It does not use XSLT.

   I created a document with the content:

<chapter>

<title id = "BGBHIGBC">title</title>

<para>one <citation>two</citation> <emphasis>three</emphasis> <xref

    endterm = "BGBHIGBC" linkend = "BGBHIGBC" role = "Page"/> five

six seven eight</para></chapter>

    Note that there are no line breaks between inline elements. With both FM11 and FM12, when I set RemoveExtraWhiteSpacesOnXMLImport to Off, the content imported correctly. When I left the setting at its default of On, however, the space following the <xref> was omitted. Thus, the bug seems to involve white-space (space or line break) after the cross-reference. I did not try other non-containers (particularly system variables or markers).

    Furthermore, the length of the line is also irrelevant. (IIRC, the default for writer line break is 80 characters, so that FM breaks lines when they get close to 80 characters to avoid exceeding that limit).

     --Lynne

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines