Trying to keep the dot in front of .357 in my fiction WIP but sometimes it splits and wraps between the . and the 357. Is there a code or method to keep alphanumeric strings from splitting?
Hi jimmypete,
If you’re using LaTeX with Scrivener, you can use the command \mbox(.357) to keep the period and 357 together on the same line.
HTH,
scrive
1 Like
Is LaTeX part of the Scrivener install?
If it’s not already something that you know you’re using, this is probably NOT the solution that is going to work for you.
1 Like
Unicode has a “zero width joiner” which is what you need. It is U+200D (in UTF8, E2 80 8D). As for how you access Unicode code points on Windows, someone else will have to tell you as I’m a Mac user and have no idea how to do it on Windows.
But I hope that helps. 
Mark
2 Likes
Thanks xiamenese! I found it in character map and tried it out in Scrivener, but it didn’t make any difference in how it displayed on screen. However, it might have an effect after compiling. I’ll experiment when I get to that stage. While playing around with it, I also found out that Scrivener cannot handle this character in a search/replace. It converts it to a line break. To find it in character map, select advanced and then enter 200D in the unicode box, and it will be highlighted. It looks like an empty box in character map. It also may be in some fonts and not others, so make sure the font is set correctly in the character map.
I have just tried it on Scrivener for Mac and it works fine, so maybe there is something about Qt that’s having an effect. Also, on the Mac it’s not something that is assigned to fonts … it is available whatever your text formatting is set to.
That said, even on the Mac, it does seem to make life somewhat difficult for search and replace where it is used, at least that is reported in the Nisus Writer Pro forum.
So I hope you manage to get it sorted out.
Mark
Is this a text that is going to be taken into a more professional environment for final layout? If so you can probably just ignore it—I would think that any typesetting engine worth its salt is not going to split “.357” across the line, and inserting invisible characters right now is unnecessary busy work.
Of course if all you have is Scrivener, I suppose you may need to figure something out. But even a relatively simple (and free) layout engine like the one found in LibreOffice is going to handle this correctly without any hinting.
Thanks, Mark. In addition to the .357 issue, I also have a character named T-Bone, which I noticed is also getting split at line wraps as well. So I’m running into this problem more than I expected. Seems like Scrivener would have an easy way to code strings to keep them from splitting across line wraps (e.g. keep the strings together).
I was hoping the upgrade from v1 to v3 would have a really great compile function but I think I’m going to end up publishing my novel like I did with v1, which is by outputting a .docx, create a linked TOC in that file (can’t get TOC working in Scrivener), and then run the .docx through an online epub creator. Also planning to print from .docx to pdf to create the file for the paperback version, rather than trying to get Scrivener to do it. I figure I can code the .docx to keep strings from breaking and if not, I’ll just do it manually. I can’t be bothered to learn a bunch of complicated processes and workarounds in Scrivener since I rarely finish a novel (last time was six years ago). With the limited amount of features I use in Scrivener, turns out I’m not getting much from the upgrade to v3.