Readability/ drawing issue (Text engine with Sierra when using Scrivener)

I have encountered readability problem when using Scrivener 2.8 with macOS 10.12.1.

It’s plausible that the problem is with text engine in Sierra.

Similar topic: https://forum.literatureandlatte.com/t/impossible-to-remove-highlight-in-text/35232/3

Basically Scrivener (macOS text engine) draws ”transparency highlights” (in tables with color in background) after saving and reopening the file with white text background. Ending up with total mess.

This wasn’t the case when editing Scrivener with El Capitan. The feature emerged when migrating to Sierra.

Recent system patch 10.12.1 haven’t solved the issue.

Have others encountered similar problems with highlighting (transparency) in Sierra?

Should I downgrade to El Capitan?

This appears to be the same exact problem you linked to in the other thread. I don’t quite understand what is going on in your screenshot though—is that a digital collage of a few dozen different text editor examples extracted from many screenshots, or what?

If it is easy to do so, I’d certainly consider it. I prefer to wait at least half a year or even a year to upgrade to Apple’s latest OS versions. Otherwise the only known workarounds are to stick with a conventional background and text colour, or not use highlights. Neither option is terribly attractive if you need them.

It looks like we’ll have to use our patch though instead of relying upon them to fix this, since 10.12.1 didn’t.

Hey AmberV.

Thanks for quick reply.

No, this isn’t the same than with elmatus. Though the thread ”Impossible to remove highlight in text” is familiar for me.

Theory: that they in Cupertino have screwed it up when developing Sierra’s text engine — seems plausible, since my troubles begun when migrating to Sierra in end of the Sep.

Anyhow for me:

I’ve ended up to use Scrivener to keep track of thematically large database for my study (qualitative research). With help of Scrivener I’ve systematized textual categories by having tables (with different colors by themes and key-wording tables according the sub-themes) besides of the actual text.

So — the whole line is one row of tables combined together. What you are seeing in screenshot is partially capture of that. It’s one text folder(!).

I really cannot attach to this public thread actual file or whole screenshot because of issues of confidentially. But I will attach screenshot that shows how the text folder should be drawn (older and non-altered file before Sierra):

Scrivener had been — so far — quite powerful in executing that. Even thought it might not haven been designed to work in that manner.

Ah, a table with backgrounds on the cells, that makes sense to me now, sorry I missed that in the initial description—and yes I do still think this is the same thing as in the other thread, it’s just showing up in a different context. What I’m basing that on is the RTF code itself and the mechanics of what are going on. There are distinct formatting methods for highlights as opposed to text backgrounds. Most word processors use the highlight codes for highlights, but for whatever reason Apple’s text engine has always used text backgrounds (hence why we had compatibility issues with highlights in some word processors prior to making it so compile converted background colours to highlights).

So when you set a highlight in Scrivener, TextEdit, DEVONthink, etc., it is actually using a \cb code to set the background, and then terminating that range with a \cb1 code, or “white”. Thus technically speaking whenever you use a highlight, from that point onward within the scope of the text, it will have a literal white background behind it.

The difference is that up until 10.12, the engine has always parsed \cb1 as transparent, or no effective background. Upgrade to 10.12, and suddenly it stops doing that and draws white backgrounds as fully opaque white backgrounds, obscuring any underlying background colour that may be drawn by text editor settings or local background settings on a table cell—which is what I’m pretty sure you’re seeing. (So yes, we agree Cupertino changed stuff without testing all of the consequences of the change.)

Here is my test:


[size=80]A table set up and ready to test, this was reloaded to make sure background cells function properly without highlights.[/size]

After setting that up, I selected the word “five” in cell A2, and press Shift-Cmd-H to highlight the word. At this point here is what we have:


[size=80]Expected look of a table with background filled cells and a highlighted word within them.[/size]

Now, after a reload, I get a very similar result to what you posted (at a much less complicated scale!):


[size=80]In retrospect I should have pulled the cell height out so it would look even closer to what you have, but you can see around the sides of each cell how the effect is only painted behind text, not within the blank areas of the cell.[/size]

Here is the line in the corresponding RTF document for that cell:

\cf0 four \cb4 five\cb1 six\cell

That’s the same formatting codes causing the display glitch in the other thread. \cb4 is the default yellow background colour (i.e. highlight) and \cb1 is white—which is not terminated anywhere, causing it to bleed through multiple cells and ultimate the rest of the document.

Let me know if I’m missing a detail though! We do have this fix already coded, so unless there is a new twist that involves something other than disregarding \cb1 and painting it as 0% opaque again, like 10.11 and every version of Mac OS X prior—I think your drawing problem will be fixed too.

You got it right, AmberV. That’s the whole picture. And I’ve tried what you’ve advised and it’s working.

Regrettably it would be senseless — from my part — to work around drawing issue with some more manual labour. I have had my fair share of that. I just hope that they fix the issue with next patch/build at Apple.

One thing — nonetheless — there isn’t a transparent (color) at separate colors palette/paintbox window in Scrivener. I tried to find but there isn’t such option. There is transparent to choose from at toolbar, a minor detail.

I have let the good people at Apple to know the issue via Apple Bug Reporter and Communities. Unhappily I am still waiting for a reply.

Open discussion at Communities: discussions.apple.com/message/30888144#30888144

Arguably — for me — downgrading is the simplest solution.

Thanks AmberV for your help with sorting things out.

That option is to strip any highlight codes from the text, rather than to set highlighting to transparent, that’s the difference. The colour palette itself is the stock panel you’ll find in most macOS software that makes use of one. It is itself unaware of implementation details in how it might be used, like text highlighting. It is the same tool you get when setting the background colour for the binder, etc. What it does is spit out a colour code whenever you touch a button within it, and on the end something is set up to listen for the colour codes it generates.

Thanks for posting to Apple as well. The more that do the better the odds of someone finally pushing it up the list to be fixed. Don’t expect to hear back from them though, even we rarely get comments on our reports through the developer interface. When you consider how pervasive a bug like this, I am sure they have thousands of reports at this point.

And again, if they don’t fix it we will. Sorry for the mess in the meanwhile.