3 Replies Latest reply on Dec 7, 2007 8:09 AM by HKabaker

    Evil <spaces> of doom

      Every time I load a page with code on it, Robohelp removes another space from the indenting.
      Simply going between [design] and [html] editors removes a leading space each time.
      I've discovered that the problem is something to do with the <space> tags that Robohelp inserts.
      Attached are two versions of the same code section; the top is how Robohelp formatted it using space tags, and the bottom version is how I'm having to re-write things in [html] mode to stop the space tags from wrecking my layout.
      To avoid having to deal with the dreadful text selection in html mode, I simply replace all occurrances of <space> or </space> with   in html mode, and then delete any extra spaces in design mode.

      To see what I'm talking about, paste the code below into a page in html mode, look at it in design mode (the top and bottom code sections should look the same). Then click back and forth between design and html modes and the indenting on the top code section is gradually removed a space at a time.

        • 1. Re: Evil &lt;spaces&gt; of doom
          Peter Grainge Adobe Community Professional
          Welcome to the forum

          Not on my PC. The fact that you are referring to Design and HTML modes suggests you are talking about RH7?

          I don't have access to my RH7 machine at the moment. I can test that later.

          Using spaces in the way you are is not something that works well in HTML. Preview your topic and then resize the window so that it is narrower than the text and see what happens.

          You might want to try a multi line form field. In design mode, highlight the text of one of the examples and insert that into the form field. Double click the form field and insert in the obvious location.

          Now preview again and you will find the problem of the text wrapping goes away.

          It would also fix the original problem although until I can get to RH7, I don't know why you are seeing that problem.

          • 2. Re: Evil &lt;spaces&gt; of doom
            Peter Grainge Adobe Community Professional
            I see the problem in RH7 and will be reporting it.

            • 3. Re: Evil &lt;spaces&gt; of doom
              HKabaker Level 2
              Peter and other colleagues,

              It's related to a bug in the WYSIWYG editor, which I rediscovered just yesterday. The space is missing in the browser, but it's in the html output code after the </span> tag. This is a new symptom of a legacy bug, I think.

              When you select text with the cursor, you can highlight the space before the first word and/or after the last word. However, when you apply the attribute, RH re-highlights text starting with the first space and un-highlights the last space. The <span> tag is after the preceding word but has no space after, while the </span> tag is after the last word, and precedes the space before the next word (look at the output; that space is there).

              However, it seems the browser suppresses leading spaces.

              If this doesn't always happen with one attribute, I think if you have text that's bold and conditional, for example, the html can get confused.

              Also, what happens if you un-apply an attribute, perhaps reapply another, edit text at the beginning or end, and so on? What if you selected spanned text but beginning or ending in the middle of a word, perhaps beyond the end of the existing span? RH5x and RH 6 sometimes got confused.

              The <spaces> code appears to be Adobe's RH 7 version of kadov (shudder); special characers have <robohelp>mmmm</robohelp> delimiters in RH source html. These, too, can confuse things when RH outputs html code around span tags.

              As I said, this is a legacy bug, but in the past you found it when you had trouble applying and unapplying styles and attributes.
              In RH 7, we're seeing the space getting lost in the browser display, so it's more noticeable.

              Last night I thought I'd raise the issue here before calling it a bug.

              Maybe, if Adobe confirms my diagnosis, this can contibute to the solution.


              P.S. Another factor may be whether you are using the Windows character set or UTF-8. I've seen this with UTF-8 and haven't tested the other.