Compiling a “Novel with Parts” (templated) project and using the Scrivener-supplied Paperback (6x9) model and PDF output, I see italicized text in some areas. But in Scrivener’s editor, there is no visible evidence of the italics.
Compiling to other output models (including Default) do NOT show this failure.
I’ve also noted this same problem using the “Short Story” (template), compiling to both the Short Story (Courier) and Short Story (Times) models, PDF output from both. The same areas (as above) show in italics (or underline, as appropriate).
As noted above, compiling to other output models do NOT show this failure.
I have the two *.scriv projects and their failing output PDFs available.
Specs:
MacBook Pro (M2 silicon), Sonoma 14.2
Scrivener 3.3.6
Steps:
Create a new project using the Fiction → Novel with Parts template.
Drag-and-drop the only section from one of my failing projects to the newly created one. (You’ll need my ZIP file for this.)
Note the absence of italicized text in the Scrivener editor’s view.
Compile to PDF for the Paperback (6x9) output format.
Note the mystery italicized text in the output PDF.
Repeat the above using the Fiction → Short Story template, and compile to either of the “Default Format” selections for Short Story (courier or NY Times).
The italics appear in the output from compile in the body (text). They span whole paragraphs.
For example paragraph 1 and 4 (see below) are normal but 2 and 3 show in italics, but only with the particular compile formats I’ve mentioned.
“So,” she continued, “the Party chose the teachers. Almost none were qualified. And that’s when I started First Grade. It was little more than babysitting.”
If Megyn was in first grade in China in 1970, would that be six years old like in the US? If so, Megyn would’ve been born in ’64.
Five years younger than me, Blake realized. She’s forty-eight.
And she was more beautiful than women twenty, thirty years younger.
I have two Scrivener projects and the example outputs I can send you.
The Short Story compile formats do not use italics anywhere within their settings, and while Paperback does, it only does for Heading 2, and centre-aligns as well, but you don’t mention that happening. They do both change the font though, and so there is a strange possibility that the font you use to write with is acting oddly and is set to oblique or italic, but not showing it, so when the text ends up in TNR or Courier it then shows. A format like Default which doesn’t change the font would allow the original problem to carry through.
You could probably check for that by selecting the paragraphs and the adjacent ones around them, cutting, and then pasting with Edit ▸ Paste and Match Style to forcibly strip all formatting. You want to select not only the problematic paragraphs but the ones around them so as to paste into text formatting that works correctly.
If that doesn’t help, I think the zip would be most helpful, as it sounds like you can reproduce this by dragging the problem data from one project into another. If it is a font glitch though, it may well be we don’t see it, or what we get is Helvetica with the italics plainly visible.
I have no styling in use across or within the text.
Scrivener’s editor shows no italics in these areas, but if I apply it intentionally, then it is visible in the editor (so the font I’m using with the editor DOES show italics).
I tried Zap Gremlins and have Show Invisibles turned on but neither helps or gives a clue.
Edit → Paste and Match Style removes the erroneous italics, but it also removes any I’ve added intentionally. Re-applying it manually is an error-prone task.
I was hoping Scrivener would have a way of showing the funkiness rather than having to manually (visually) check the compile’s output. (Find by Format isn’t available when viewing a PDF in Scrivener.)
It depends on the size, if the problem is as contained as it seems (you mentioned being able to drag one thing over into a blank project’s binder to demonstrate it), then the result of that test is all we’d need and that’s probably hardly anything, a few kilobytes if that. If it is much larger though, several dozen megabytes, then you’ll need to use a file sharing link.
Either way, click on my avatar here, to send a private message.
Thanks for the provided information. It’s interesting how this style is in the underlying RTF, as normally it would be stripped out when pasted or imported if the project itself does not have the style defined. If it is defined then it would add Scrivener-specific coding around the text, invisible in the editor, but used by the editor to indicate it is styled. Scrivener itself does not use native RTF stylesheet codes as they are not directly supported by the text engine, which is probably where things are getting a bit weird.
That it does not have these markings, and only has raw RTF styling applied, indicates there is some gap in how it got into Scrivener that way—or perhaps it got in via some other means, such as editing the RTF file manually?
Tentatively I would say the safest thing to do is the procedure I described, to ensure this “rogue” formatting is completely wiped out, even though that would mean, as you say, repairing any intentional formatting within the range.
But another approach that may work is exporting the sections with (File ▸ Export ▸ Files... to RTF format, and then dragging them back into the binder to see if that behaviour I referred to correctly detects and converts them to its native style handling.
Hi Amber,
Thanks for the info. The files in question have been to an editor and back – as *.docx – so I’m gonna guess they picked up the contamination from Microsoft. (No surprises there. )
The difficulty is in identifying which ones are contaminated. The project in question is a 100,000 word novel; a visual scan is error prone and just confirms that it’s difficult for an author to edit his/her own work.
Unfortunately, saving the RTF and then drag-and-drop back in didn’t undo the problem.
GOOD NEWS: With the contamination identified, I can save the RTFs as you suggest and then “grep stylesheet *.rtf | grep emphasis” to determine which ones are in question. A hand-edit in Macs Text Edit (with Settings → Display RTF files as RTF code instead of formatted text) is then feasible followed by a drag-and-drop back into Scrivener.
FEATURE ADDITION? Being able to open RTFs in an External Editor would be a useful addition in this particular case, but I recognize that’s opening Pandora’s Box for many of your users.
With the “how to find it” and “how to fix it” worked out, I consider this problem solved. (And I’ll be monitoring things as they come back from my editors to figure out who has this communicable social disease.)
All right, that’s a good solution to switch off TextEdit’s RTF parsing and just brute force it with search and replace.
FEATURE ADDITION? Being able to open RTFs in an External Editor would be a useful addition in this particular case, but I recognize that’s opening Pandora’s Box for many of your users.
Well, that’s just the thing… what we’re looking at here is indeed one case where Scrivener’s use of RTF isn’t technically pure specification. It doesn’t break the spec for the most part, but it does do things RTF can’t do, or in some cases like this, things RTF can do but the underlying text engine cannot, meaning the capability has to be an overlay on top to avoid as much data loss as possible. Some of this is achieved with codes that would appear as raw text in any other text editor, other things would probably just vanish or break, like embedded PDFs or images (which the basic Mac text engine cannot handle, hence RTFD).
In short there needs to be a translation layer that converts all of this internal stuff like having multiple notation streams, images linked to the disk and so forth… and we’ve got that: File ▸ Sync ▸ with External Folder.... It’s not perfect, because these things have no direct translation in some cases (you can’t get inline annotations and comments back out of an editor that only works with comments), but that’s the best you’re going to get for being able to work on material outside of Scrivener in a safe way.
)