Full-screen mode and underlined text

Nope, it is definitely something messed up in the RTF itself. I can copy and paste the problematic text into a new document and reproduce it there. This is why duplication transmitted the error before. This is probably an Apple bug, but who knows.

Dan: It seems the only way to “fix” it is to create a new document, and paste the contents of the old document into the new document with Paste and Match Style. I can find no command or way to fix a document already displaying the bug. This isn’t the best work-around, because it destroys existing styling.

This is why I like MultiMarkdown. :smiling_imp:

This is similar to what I’ve discovered. But it now appears that, contrary to what I reported earlier, it has nothing to do with when I created a file or which version of a template I used.

I’ll poke around some more with it, but what it looks like now is just as you’ve described for the disappearing underlines drawn in black, but only in the “Manuscript” section of a project. In the “Research” section, for example, I can see the underline, though faint, and Phil’s baseline trick helps a great deal.

And yes, I, too, have tried other fonts and noticed the same problem, so it’s not just Courier.



Hi Amber,

I created a new project and some new docs before reporting the issue. Some of the files are imported, but there doesn’t seem to be a difference.
Some files are new, some imported (all either RTF or RTFD – I rarely use Word’s DOC binary format so I can save RTF versions with RCS… way too many acronyms/abbreviations there!).

I used Scrivener’s novel template. I definitely see a difference in underlining behavior between the “Manuscript” and “Research” sections.


Quoth AmberV Godess of Code:

Mère de Lucifer! There speaks my kind of woman! :smiling_imp:

Le Directeur

If someone could send me a piece of RTF text or a project in which this bug always occurs, I would be grateful - that way I can see it for myself. Somebody did once report that underlines had not turned up at all in full screen in one piece of text, but it was very isolated. I have never been able to reproduce it. In any case, it’s very odd. Scrivener uses Apple’s “temporary text” attributes to colour text in full screen mode, so it must be their code in this area that is the problem. There is another way of doing it, but it’s a bit involved, so I would like to see the bug before trying out the other way of colouring text…

Oi, I’ll try to if I can get it to appear again. As of this morning the documents that were exhibiting the error no longer do. I was able to reproduce part of the bug in TextEdit, by the way. The part where selecting a range and colouring it does not affect underlines.

Thanks, Amber for the Bitstream Vera Sans Monospace link.

That’s a really readable font and I think it’ll become my new fave.

I always read your posts with interest even though I only understand half of them ( which is not quite the same thing as understanding half of what you say).

Dan - could you please do me a favour and download WriteRoom from hogbaysoftware.com and see if you get the same problems in that application. WriteRoom uses a different way of rendering the coloured text in full screen, so if you don’t get the problems there, I might switch over to using that method.

You are very welcome, nib!

Hi Keith,

I had the free version of WriteRoom already installed, so tried that… underlining was not supported. Next, I downloaded the trial-version of WriteRoom and tried… again, not supported, but this time you can at least see underlining in as a grayed-out option on the menu. It appears that underlining is not supported in the trial version. Oh well.



(Dan, WriteRoom is set to edit in plain text by default. You need to hit cmd-shift-T to get into rich text mode, or change the default setting in the Preferences.)

Thanks, that worked. And the underlined text looks okay.


Strange… I’ve been in touch with Jesse, the creator of WriteRoom, and he uses pretty much the same method for colouring text as I do, as it turns out. I may try his code anyway, as it is a simpler method, and we can see how that turns out…

For what it’s worth, I’ve been having the same kind of problem, and did a search on the forum that brought me here. Sometimes my underlines appear, and sometimes they’re invisible, in full screen mode. In fs mode I use either white or green on a black background. Sometimes the underline is the same colour as the text, and sometimes it’s invisible. To elaborate further - if I’ve used an underline on a previous edit, when I come back, it’s still there, but sometimes when I try and underline a new word … the underline is black and invisible. It’s really, really infuriating, and I simply don’t understand it.

One other thing is, that if I scroll back, and copy and paste an underlined word, and place it in the new non-underlining-text I’m working on … it works, even if I have to retype the new word. Maybe I could just do italics from now on, and convert it all to underline in Word at a later date, just prior to the last touches on the manuscript. But in the meantime, i’ve got dozens of underlines I can’t see, and to make what I’m working on make sense I’d have to go back, manually find them all (since Scrivener doesn’t appear to be able to search on a style and replace it with another), and change each one by hand, which isn’t really feasible with a 70k document split up into two dozen separate text files.

Unless, of course, I’m doing something really obviously stupid.

Gary - could you try WriteRoom as well? I’m going to move over to Jesse’s way of doing this. I don’t really see why it should make any difference as Scrivener and WriteRoom use the same underlying method, although Scrivener does it in post-processing way whereas WriteRoom does it as you hit the key. This shouldn’t make a difference, but it might… So, as I say, I’ll try that, but if that doesn’t work, this has to be a problem with the text system.

Keith - I used Writeroom in the past as a trial version, so I’d have to buy it in order to check it out now.

The problem seems to crop up at the end of text files - when I’m writing new text. It might be part of something I’ve noticed in Word too - you start typing at the very last line, or start a new paragraph, and the new stuff you’re typing doesn’t match what goes before in terms of the font or paragraph style. It’s like some kind of default outside of your own personal settings reasserts itself, somehow.

No one ever sent me an RTF file that would reproduce this error. If someone could send me a document or Scrivener project that shows the underline problem, I would be very grateful. I cannot reproduce and am reluctant to implement the WriteRoom method given that it is a lot of work and uses teh same underlying text system methods as Scrivener, so I don’t see why they would act any differently.

P.S. One thing that could cause this I have just found out. The underline can have a separate colour to the text. You can set it via the font panel (cmd-T). It seems that for some reason, the text system - and I’m guessing this is an Apple bug rather than intentional behaviour - respects the underline colour over the temporary colour assigned.

You can reproduce this thus:

  1. Select some text.
  2. Underline it.
  3. With the underlined text still selected, hit cmd-T to bring up the fonts panel.
  4. From the underline dropdown menu in the top-left, select “Color” and assign a colour to the underline.

Now enter full screen - you will see that the underline colour is used rather than the full screen text colour.

If you copy an paste the text into WriteRoom or MacJournal, you will see the same thing.

So, my guess would be that for some reason, the text with which you are experiencing these problems has its underline colour set to black. This then won’t show up in full screen mode. (Normally, underlines have no colour assigned and are just drawn in the text colour - and in this instance they can have the colour overridden in full screen.) I’m not sure why some underlines would be assigned as black and others not; maybe it depends on the program in which they were created.

I’m not really sure as yet how you can reset the colour to none, though…


Keith! I just tried this and it works beautifully. I selected a whole text file in Scriv, command t, underline colour, deselect text (in full screen) and underline a random word. It works! Genius.

I’ve been struggling to find a work-around that resets the underline text color to “none.” Here’s what I’ve found:

  1. Take a snapshot of the file first, just in case.
  2. While in standard-screen mode, select all text in the file ().
  3. Delete the text (, , etc.).
  4. Paste the text back where it was ().
  5. Test the file in full-screen mode.

Seems to work. If I see any peculiarities with this work-around (i.e., must be redone periodically, etc.) I’ll let you know.