Pages: 1
Print
Author Topic: Typeing 2 spaces  (Read 4805 times)
gcrews
Member

Posts: 265


« on: February 11, 2013, 05:12:40 PM »

How would I go about typing in 2 spaces between 2 words in Xmetal?
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #1 on: February 13, 2013, 02:03:24 PM »

Default behaviour (no special CSS settings configured) for Tags On and Normal view is to collapse multiple white-spaces and treat them as insignificant (W3C XML recommendation definition of "insignificant").

To make them all visible in Tags On or Normal view you will need to change the white-space property in the CSS for the element that will contain the text. You would want to probably set this to either "pre" or "pre-wrap".

If you have pretty printing enabled then you may want to disable it entirely or just for that element. Whether you want to do this will depend on whether you care if just your extra spaces are to be inserted. I'm guessing that if you care about inserting extra spaces then you'll also care about XMetaL adding them for pretting printing as well. If you want to disable it just for the one element you do that in the element's pretty printing section in the CTM file. The setting is listed as "Preserve Space" in the "Text Layout" dialog accessed via the Properties window in XMetaL Developer (when you have a CTM file open). In the CTM file itself it is inserted as <PreserveSpace>. See the Journalist example's CSS and CTM settings for the "ProgramListing" element. See attached screenshots.

You may also wish to increase the <MaxLineLength> general pretty printing property in the CTM file or set the <IgnoreMaxLineLength/> on the individual element (this one is new to 7.0 and not included in the XMetaL Developer GUI). The CTM files for DITA use this <IgnoreMaxLineLength/> property on the DITA element "imagemap".

Having said all of this it would be good to know why you need to enter multiple spaces between words. Clients have asked XMetaL Support about this type of thing in the past and it has turned out in several cases that they actually don't really want extra spaces in their XML. They were trying to compensate for flaws in some kinds of output. Those are best dealt with by fixing whatever is generating your output instead. In some cases when you really do want the text to look different (but there isn't really anything wrong with the output) adding extra markup might also be needed so that you end up identifying a special exception:
Code:
<para specialcase="extraspace">This is a test.</para>

Then you might change your output engine to lay that para out by adding additional spaces between words programmatically, or by taking advantage of specific formatting properties supported in the output engine (such as font kerning or word spacing) or the viewing application (such as with CSS in an HTML page).


* programlisting_css_ctm_settings.gif (37.36 KB, 725x873 - viewed 684 times.)
« Last Edit: February 13, 2013, 02:14:32 PM by Derek Read » Logged
gcrews
Member

Posts: 265


« Reply #2 on: February 13, 2013, 06:03:01 PM »

I was wounding since I came across two non-breaking spaces (&nbsp;) in our DITA content and some of our processing was getting a parsing error because of it. It’s a specific string within text of a paragraph being quoted that specifically needed two spaces.  The documentation itself says with two spaces between the two words.  I ended up just just changing them in that instance to &#xa0; and it seems to work ok now. I was just kind of wounding if there was a trick in XMetaL such as a special character in the symbol or special characters toolbars for non-breaking spaces or something. I don’t think I’m going to go through the trouble of making a special tag if it’s only once or twice that it’s needed.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #3 on: February 14, 2013, 02:42:42 PM »

Sorry, my assumption was that you meant 0020, 000a/000d and 0007 (space, carriage return/linefeed and tab). They will all collapse (unless you do what I said previously).

All other characters, including the "no-break space" character, are considered "significant" so XMetaL should render them (using the current font so there may still be a few characters that will not render if designed as such in the font).

-- but I think we're getting off track here, I think your real issue is this:

DITA defines the character entity &nbsp; in the DTD (it is the only named character entity defined) so it is legal to have it in your DITA files and XMetaL will tell you they are valid, because they are. Newer versions of the DITA OT such as the one included with XMetaL Author Enterprise 7.0 don't like them to be there (or more specifically the XSLT engine is told by the DITA OT to run in a mode that causes an error when this entity is encountered). There's a detailed thread about that here: http://forums.xmetal.com/index.php/topic,2724.0.html

There is a shortcut (which is a legacy feature from HoTMetaL actually) for inserting a "no-break space": Ctrl+Shift+spacebar. However,  that is exactly what you don't want. It's behaviour is to insert the named character entity &nbsp; if it is defined in the DTD. For DTDs where it is not defined that shortcut does nothing.

Your change (inserting the actual no-break space character in place of the &nbsp;) is the right thing to do for DITA given that it causes errors with the DITA OT today and that this entity has been deprecated in the DITA DTDs and may be removed in the future (so that your files may become invalid when using future versions of the DTDs). However, I think a script would be needed if you want to automate that change or make it easier for a user to do.
« Last Edit: February 14, 2013, 02:47:50 PM by Derek Read » Logged
tmakita
Member

Posts: 26



WWW
« Reply #4 on: June 24, 2014, 08:58:01 AM »

Hi Derek,

I have a basic question about your explanation:

Quote
Default behaviour (no special CSS settings configured) for Tags On and Normal view is to collapse multiple white-spaces and treat them as insignificant (W3C XML recommendation definition of "insignificant").

The XML recommendation is written as following:

Quote
In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code.

http://www.w3.org/TR/REC-xml/#sec-white-space

Why does XMetaL treat white-spaces as "insignificant" in default setting? The XML recommendation refers significant when they are written in as poetry and source code.

If I wrote a program source code using "pre" element, the white-spaces will not be collapsed. So there is no problem.

If I write a poetry using "p" element, the white-spaces will be collapsed into one space even if they are inserted multiple times in Plain Text View. However how do you guess that the white-spaces inside the "p" element is "insignificant"?

Regards,
Logged

Toshihiko Makita
Development Section
Antenna House, Inc.
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #5 on: June 24, 2014, 04:08:04 PM »

It is the default setting because that makes the most sense for the vast majority of content. The only CSS property that applies to all elements by default (when no CSS properties are in your CSS file for an element) is display:inline. Everything else is optional and must be added.

So, for elements where content is significant and you wish to display white-space in Tags On or Normal view simply set the appropriate CSS property for that element when you create your customization files.
« Last Edit: June 24, 2014, 04:10:00 PM by Derek Read » Logged
Pages: 1
Print
Jump to: