Skip to main content
Known Participant
October 30, 2008
Question

FM8 and DITA -- Correct way to insert non-breaking spaces, etc.?

  • October 30, 2008
  • 12 replies
  • 3087 views
I've gone round in circle trying to figure this out.

FrameMaker's "good old" method of inserting a non-breaking space -- CTRL+SPACE -- doesn't work if the content is output as a DITA XML file: XML requires a string consisting of Ampersand-"nbsp"-semicolon (I can't enter the actual token because browsers evidently see it as a "real" non-breaking space...)

What's the trick for entering non-breaking spaces in content that will be saved as both:

  • DITA / XML

  • FrameMaker binary (.fm)



Is this one of those ALT+keypad things? Or...?

Cheers & thanks,
Riley
This topic has been closed for replies.

12 replies

Known Participant
December 2, 2008
Thanks to all who responded.

This is one of many FM8-DITA issues that I've deferred while I rush to meet a deadline.

Long story short, the apparent need to descend into FM's read/write rules and EDD's simply to enter a non-breaking space is just one more in a growing number of annoyances I've encountered trying to use FM as a DITA authoring environment...

Cheers and thanks 'gain to all,
Riley
Known Participant
December 2, 2008
Riley,

This may not help, but I use structured FrameMaker and our EDD defines a NoBrSpace ELEMENT, for which the EDD inserts a nonbreaking space. I do not export to XML, but my guess is that this element would be exported as an element but with no content. When read back into Frame, the Frame EDD inserts a nonbreaking space. No read-write rules are needed because the element remains an element in both the Frame space and the XML.

Now, I agree that this approach does NOT create a nonbreaking space in the XML; there it is just an element with no content. On the other hand, one can argue that a nonbreaking space is formatting, not content; it is used to prevent a line break at a certain spot in the content, which is formatting not content. IF the XML content is used elsewhere as XML data, such as content for a Web site, then maybe the Web site's CSS would be able to insert the correct code for a nonbreaking space.

Maybe the read-write rules can be defined to replace this element with the Ampersand-"nbsp"-semicolon code when exporting to XML and back to the element when importing to Frame. I have no idea how this would be done, just a concept.

If this helps, good; if not, sorry.

Van
Participating Frequently
December 2, 2008
Hello Mr. VanDyke,

you might try the following (although this is some kind of hack)

1. Define a variable in your structapps template (e.g. "hardspace") and give it the value "\ "(=the fm expression for a hard space)
2. in your R/W-Rules write:
entity "hardspace " is fm char XXX; (where XXX is the fm-number of the character; you should get this via the SYSTEC TOOLBOX-function "get encoding", which is a freeware function)
3. Whenever you want to insert a hard space insert the variable "hardspace".

I myself tried this with hard returns rather than hard spaces, but the method should be the same. After all, a "hard space" might be something that some application might not know, so it is an application specific character.

Hope this helps,
Franz.

[SYSTEC - the document processing company.]
[excessive signature deleted by host]
Known Participant
November 11, 2008
Scott: Good tip re: the variables. Thanks! RBV
Participating Frequently
November 11, 2008
Hi Riley...

I think you'll have the best luck with "\ " .. but if you're using FM8 DITA you're probably not going to have very good success using variables at all since they won't survive the map to book process. (DITA-FMx provides a command that wraps variables in a ph element which allows you to use them in a book.) However, for DITA, you should consider using conrefs instead of variables.

Cheers,

...scott
Known Participant
November 11, 2008
At the risk of contaminating my own thread, albeit in a way that's somewhat related to Phillip's point about keeping two-word tokens such as Adobe, Inc on the same line: For DITA / XML, what's the preferred form for non-breaking spaces in variables?

Is it still good ol' "\ ", or...?

RBV
Known Participant
November 11, 2008
Hi Philip;

>My use case is wanting to ensure that a company name, such as "Adobe, Inc", never wraps to start a new line with " Inc."

Good point.

You could also set an XML internal entity to designate "Adobe, Inc".
OTOH, one of the hardest XML things to do (at least for me) is to determine exactly what objects and entities I want in the first place. Sigh.

David Blyth (The UNIX and VI dinosaur)
Staff Technical Writer
QUALCOMM - Standard Disclaimers Apply

Only 149,999,949 more years of Ruling The Earth to go
------------------------------------------------------------------
New Participant
November 10, 2008
The difficulty with plain ol' spaces inserted when you've turned off Smart Spaces is there is no indication in the XML file of how the author wants the spaces treated. My use case is wanting to ensure that a company name, such as "Adobe, Inc", never wraps to start a new line with " Inc." By the time the author's "phrase" gets to HTML, something needs to have inserted the appropriate markup --"Adobe,&-n-b-s-p-;Inc."
Known Participant
November 3, 2008
Hi all;

Seems like you could also simply try inserting multiple soft spaces whereever you want them (with "smart spaces" turned off). See the thread on "Space! The Final Frontier", tho I should warn that my sense of humor is warped. ;)~

But between these two threads (writing spaces into DITA, and reading spaces in XML files) I can't help but wonder what Frame's default I/O behavior on spaces really is.

XML parsers usually let you set flags so you can define how you want the parser to handle multiple spaces and/or line breaks. But Frame just does whatever it does, so (unless I'm missing something) allowing users to set parser flags to change Frame's default XML parsing might be a useful thing for Adobe to do.

Just a thought.

David Blyth (The UNIX and VI dinosaur)
Staff Technical Writer
QUALCOMM - Standard Disclaimers Apply

Only 149,999,949 more years of Ruling The Earth to go
---------------------------------------------------------------

PS. Martti, I already wrote a UNIX csh script to clean up the spaces post XSLT, but I'll try modifying the XSLT per your suggestion and let you know what happens. That'd be a better solution. Thanks!
Participating Frequently
October 30, 2008
Excellent. You gotta love that rejiggering!

...scott