Mystery   in topic files

[HelenF]

Hi, our translators have just spotted that   is appearing in some of our topic files. There's no reason for our writers to have introduced them so I'm wondering if Flare has a habit of introducing them of its own accord. Does anyone known if this is a known issue?

We are using Flare 8 to build WebHelp output.

Thanks
Helen

[kwag_myers]

I've only been using Flare a short time and the only thing I've seen introduced is <![CDATA] ]]> when there's something the system doesn't recognize. However, I have seen other text editors introduce the non-breaking space character entity when there is a double space. Is it possible that your code came from, or someone is using another XML editor?

[HelenF]

No, the non-breaking space is appearing in topics that have only been edited in Flare.

[sfoley]

No, the non-breaking space is appearing in topics that have only been edited in Flare.

Chances are that your writers held down the Shift key just a little too long while typing capital letters or punctuation. Every organization where I've used Flare, we see these scattered throughout the output.

The reason is because Flare rather stupidly defines the non-breaking space shortcut as Shift+Space, rather than Ctrl+Space (Framemaker and other apps) or something similar that isn't so easy to type accidentally. I submitted a bug report awhile back on it and was told "working as intended," but it won't hurt to let them know it's causing you annoyance.

You can do a project-wide Find and Replace to get rid of them.

[HelenF]

Interesting. In every case so far (except one) there's an uppercase character next to the   so that's probably it. Thanks very much.

Cheers

[LTinker68]

The reason is because Flare rather stupidly defines the non-breaking space shortcut as Shift+Space, rather than Ctrl+Space (Framemaker and other apps) or something similar that isn't so easy to type accidentally.

Interesting. I'm pretty sure Dreamweaver uses Shift+Space, too, which is why I just naturally tried that when I started using Flare. SharePoint Designer is the same way, I think. I wonder if it's a web app convention versus a print app convention.

[RamonS]

As far as I know MS Word and OOo Writer use Shift+Space as well.

[sfoley]

Interesting. I'm pretty sure Dreamweaver uses Shift+Space, too, which is why I just naturally tried that when I started using Flare. SharePoint Designer is the same way, I think. I wonder if it's a web app convention versus a print app convention.

As far as I know MS Word and OOo Writer use Shift+Space as well.

Actually, Word and Dreamweaver both use Ctrl+Shift+Space:
http://en.wikipedia.org/wiki/Non-breaking_space

My bias is toward Ctrl+Space (or Opt+Space on the Mac) because of the applications I've used most often. But I'd really just prefer it was something other than Shift+Space, which I seem to hit non-purposefully every other sentence. :P

[i-tietz]

No, the non-breaking space is appearing in topics that have only been edited in Flare.

Really? How did you do that, then?
Whenever I use SHIFT+Blank in Flare it doesn't produce a   but a   ...

[Msquared]

Under some circumstances Flare puts in a non-breaking space rather than leave something empty. I've noticed this on several occasions, for example, when you create a new paragraph by pressing Enter, or when you first create a table and the cells are empty. In each case, once you start typing there, the non-breaking space disappears. Presumably, Flare doesn't like "empty" content so it makes up something innocuous to fill the space.

I've also noticed non-breaking spaces immediately before capital letters that start new sentences. I think this one is down to pressing Shift slightly before the capital of the first word in the sentence and catching the space instead. I've come from a Word background and would really prefer Ctrl+Shift+Space for non-breaking spaces.

The other consequence of Flare's rather odd design decision is that I often end up missing out spaces when typing something with spaces followed by capital letters where a non-breaking space isn't valid, for example, when specifying a file name for a Target. In this case, Shift+Space does nothing, whereas any normal person would expect it to enter a space (what do you mean, I'm not normal? )

[Nita Beck]

Under some circumstances Flare puts in a non-breaking space rather than leave something empty.

I've never seen Flare insert " " rather than leave something empty. I've only ever seen it insert " " in those circumstances.

Usually when I see " ", it's an artifact in material copy and pasted in from other applications, particularly older versions of Word, or in material that was imported from RoboHelp.

Occasionally I assist a translation company with QA of translated Flare projects, and at the top of my list of tasks (as instructed by the translation company), I search and replace all instances of " " with " ".

[cbdebris]

I believe that   throws an error in Flare code, which is why you'll se  

[Msquared]

Aha! The issue specifically relates to &nsbp; not just a "non-breaking space". Read the first post properly, girl!

  is a non-breaking space, and that's how Flare codes it if you insert one deliberately, or do something that causes Flare to insert one for you. This is always recognised by both XML (what Flare uses to encode your source content) and HTML (what Web browsers use to display web pages).

  is a non-breaking space in HTML but won't be normally be recognised in XML and definitely isn't supported in Flare's XML schema.

So, either the   appeared when your content was first imported and no-one has tried to open the topic since, so the problem hasn't been flagged yet (Flare will complain bitterly if it finds it later on), or someone/something has done some post-processing on your content after Flare and before the translators, and this post-processing has made the mistake of replacing perfectly valid instances of &160; with  , which is the same thing in HTML, but invalid in XML.

Occasionally I assist a translation company with QA of translated Flare projects, and at the top of my list of tasks (as instructed by the translation company), I search and replace all instances of " " with " ".

Nita's comment makes me wonder whether there is some translation software that is known to cause this problem?

As I say, Flare will grumble when you open a topic that contains   rather than &160; in it. If you have a topic like this, Flare 8 will also report an error when you build a PDF target. However, if your only target is Webhelp, you will be able to build your target, where the   will remain quite happily and be decoded properly in the Web browser, which understands HTML, and recognises   as valid.

So if your only target is an HTML-based output (like WebHelp), and the problem topics have never been opened in Flare, it is possible the   have always been there and never spotted. If you know those topics have been opened/edited in Flare, or if you have successfully generated PDF targets, then something added them after the topics left your Flare project, because you would have known all about them otherwise.

[NorthEast]

Yep,   is not a valid entity in XML/XHTML.
The same goes for other entities like £ and ¢ .

I've not seen Flare insert   - only   (which is unicode for a non-breaking space), or CDATA tags (for multiple spaces).

If you use   , Flare will display an error and won't display the topic in the XML editor; so I'm wondering how this wasn't noticed by authors, only the translators.

[PhilHeron]

Hello there,

I work for the same company as the original poster (HelenF). Our translation department is continuing to have problems with the   entity in Flare source files.

The good news is, the   entity does not occur in our English source files. When needed, we have either   or a CDATA element. However, it appears that the translation process introduces   into the translated files in certain circumstances. Now that the translation department has identified the problem, they can amend their processes to stop the   being introduced, or to strip it out before building the help using Flare.

I have to disagree about   not being a valid entity in XML or XHTML, though. It's certainly not a built in entity (like >, < or &), but if you are using validated XML, and your XML schema or DTD defines it as being a valid entity, you can use it. The XHTML 1.0 DTD, for example, defines the three entity sets xhtml-lat1, xhtml-symbol and xhtml-special. The   entity, and many others are included in this.

Flare source files are not XHTML files validated against the XHTML schema, they are well-formed xml files using a grammar very similar to XHTML.