CTRL-Enter for new snippet - issue
 

This issue is happening any time I use CTRL-Enter to create a new snippet below the one my cursor is in, and only when I am using the Read Aloud snippet style.

When I hit CTRL-Enter and the new snippet appears, I start typing and the font is always Calibri, despite the fact that the snippet style is defined as Comic Sans MS. I actually don't have any of my snippet styles defined as Calibri, which makes this even weirder.

It actually seems that there is a hidden or invisible character inserted at the beginning of the snippet, because I can right arrow past this one or two characters. It takes two right arrow key presses, the first doesn't move the cursor at all and the second press moves it once, and then I can start typing and the font will be correct, but this leaves a blank space at the beginning. I can then backspace to get rid of the phantom character(s), after which everything is fine.

I tried defining Read Aloud style as a different font. In this case, Century Schoolbook. The same thing happened, but this time the phantom font character was inserted as Times New Roman. WEIRD!

After copying the phantom character out of RW and into Word, it appears to be some kind of space or formatting character that shows as a little hollow circle when I tell Word to display "space characters". I found a chart on the web that seems to define it as a "nonbreaking space". I have no idea what that is.

This does NOT happen if I use the tool button on the right and "Add Snippet Below". The phantom character is not created this way, only with the CTRL-Enter.

I have tried this with every other defined snippet style, and not of them produce the same results. Only the Read Aloud style.

Before I submit a ticket, I just wanted to see what the community experience with this is, if any.

Thanks for any insight.

I have seen it yes, and you know I never did any investigating as to when and why, I just lived with it. Good find, I recommend you do indeed file and bug report.

What those characters are, and why they "act funny".
 

Depending at which point you are using Split Snippet, depends on the characters you get, but are always at least one each of the following, and not always in this order. This has been true for as long as I have been using Realm Works.

U+0020 : SPACE [SP]
U+200B : ZERO WIDTH SPACE [ZWSP]

Lets analyse what happens when using Split Snippet (Ctrl + Return).
With a space directly after the cursor, Realm Works turns that space into a ZWSP. Then moves the text into the snippet. At the end of that new snippet, another ZWSP is placed.

From what I can tell, this has always been true.

Like you have learned, adding a new snippet, or Ctrl + T, doesn't have this issue, but does still have characters present in that space. An educated guess would likely see me saying it could be a "Paragraph Delimiter" (¶), but I currently have no evidence of this.

Word is incorrect when it calls it a Nonbreaking Space, and that can be proved by using a UNICODE character analysing tool (such as What is it!).

"Your word processor assumes that a word space marks a safe place to flow text onto a new line or page. A nonbreaking space is the same width as a word space, but it prevents the text from flowing to a new line or page."

https://i.imgur.com/iW5VIBZ.png

Practical Typography, has a great write up on why you would use a NBSP in your document.

And a great review of a ZWSP can be found at Smashing Magazine

Your issue of why is the font changing is simple, Comic Sans MS doesn't have the ZWSP support and cannot display that font. Realm Works can try and find a font for you and that is what it does. My assumption is that Century Schoolbook also doesn't support this character. Part of Realm Works tries to find a font similar too the one in use and has this character, which is why the fonts are different. It should - in theory - happen to all snippet styles when using the same fonts.

Side note, this is also why I spent literally days trying to find a font that I can use in Realm Works, and posted this thread - Stopping Elements may not work

How to fix this? Find a font that supports the Zero Width Space. The standard font suggested to ensure font rendering in English is Arial Unicode MS from what I have seen.

I'm no typographic expert but I do know Unicode, U+200B (ZWSP) should appear in any font claiming to be Unicode.

I believe that to be true yes. However Comic Sans MS is not a Unicode supported font. As referenced in the link I presented above Comic Sans MS which lists all the character in its font packet vs say Arial Unicode MS which is present within the font packet. You can do a simple Find on the webpage to find Zero Width Space (or not).

Further, the documentation for the font provided by Microsoft themselves denotes as having the unicode ranges of " ". As seen on their Typographic site. Thou interesting if you look at the document for Arial Unicode MS, it too is not supportive of Unicode.

Wow. I learned a lot today. Thanks, Kiwi. Still not sure if I understand all this zero width space, non-breaking space stuff, but I will go learn more.

Soooo, bottom line, does this represent an "issue" with the program, or just an issue with my choice of fonts? I had noticed for a very long time that there had been a space in front of a lot of my inserted text, but I just kind of ignored it until it became a problem, which apparently corresponded to when I chose to use Comic Sans MS.

I'll try and break this down as simply as I can from the point of view of a guy who has designed web pages. Non breaking spaces are an actual space except they prevent what the separate from going on different lines. A zero width space is the opposite, it isn't a visible space at all but will allow the things it separates to be on different lines.

There are several other spaces mostly having to do with their physical width that you rarely see, or see automatically applied by word processors.

It is unclear to me if the issue is with RW or not. This whole inserting zwsp or nbsp when using the shortcuts to create new snippets may be unavoidable or it may be a bug.