Scrivener above, final draft below. Fonts, zoom, etc. identical. You can see in both the action and dialogue that the text wraps too soon forcing odd formatting. Noteworthy that this is also a problem in the Windows Scrivener 1.9 release. Final Drafts handeling has been confirmed against Fade In Pro as well. Haven’t tested it, but maybe this is an issue globally within scrivener outside of the screenplay mode as well?
Hmm. I thought to try this out on a non-Script, and there’s a problem, but what I noticed appears to be a different one, looking back at your pictures. So let’s look there first.
I can’t eye-measure it closely enough, but if you type ‘everyone’ letter by letter, does it actually wrap as you get to the last letter or so? Because it appears there may be a difference in either the font or its rendering which causes a slight difference in measure.
Whether that would be an error or not is something Tiho will have to know.
Now, I found actually a different problem, as another picture shows. I set left and right indents via the Format | Paragraph | Indents and Tabs dialog — and got a big mistake as to where the right Indent was actually set,
The text in the next paragraph explains, after I’d manually pulled the indent over to give it a right indent directly. Something appears quite wrong in the dialog – both from entry there, and for what it reflects after pulling the indent on the ruler.
The Paragraph > Tabs and Indents dialog is broken in Beta 40. I have added this to our bug tracking system and a fix will be available in the next update.
@NARRSD: It wraps “everything” down to the next line when I type the “g”. Font rendering looks the same to my eye, but maybe your’s is sharper.
Bumping this just to mention the text wrapping is still an issue in B42.
I am afraid I do not see the problem. If you set left/right indent to 1.5" you wrap at the same position. If you need left indent 1.5" and right indent 6", you must type, 1.5" and 6". Right indent is not offset from the right, but from the left border. This is how Mac works too.
Let me know, if I am missing something that still does not work as expected.
About the Final Draft comparison, you might want to try adjusting the font. As much as I know Final Draft have their own font. Install it under Windows and set the imported Scrivener text to that font too. Most likely in this case the wrapping will match.
Ok so here you can see what I’m talking about; it seems to be a character-per-line issue and not an indent issue per se. Interestingly enough Final Draft and Fade In don’t seem to totally agree with each other as well, but they’re pretty close, within 1 or 2 characters for each element besides for Parentheticals which Fade In seems to truncate quite a bit for some reason. Scrivener seems to deviate on a consistantly wider basis, particularly for Scene Heading, Action, and Dialogue elements, which lead to some odd formatting. This is most noticable, in my opinion, for the Dialogue element as it is the shortest character-wise to start with, and leads to lots of lines with only two or three words and lots of empty space on the end when it wraps the final word to the next line, and probably has the most impact of these discrepancies in altering the final page count of the screenplay. I guess one can’t say that Scrivener isn’t “conforming to the standard” since other softwares seem to display discrepancies in relation to each other as well, but I think Scrivener’s wider margin of deviation from other programs definitely has a material effect on the final project both logistically and aesthetically (as in noticability of something “incorrect”), and impacts its practicality in the use of screenwriting. It might be worth mentioning again that this may not be a “Beta” bug, but an issue with how Scrivener handles this type of thing in general as this behavior is identical in the non-beta release as well. Any idea what might be going on here, or am I overlooking something obvious?
How off is Scrivener when you switch to 10pt font size?
Could you please try using the Final Draft font in Scrivener too.
I am afraid this is something to do with the Qt font engine, and we do not have much control over it.
Oh just a note, in my last screen shot it is still Courier Prime just at 10pt. I missed that you asked for Courier Final Draft. My trial of FD has since expired so if anywone else out there wants to give it a shot…
FWIW, screenplays in USA require a 12-point, 10-pitch monospace font.
Points refers to the height of the font, and pitch refers to the number of characters per inch horizontally.
A 10-pitch monospace font will render 10 characters per inch, regardless of which letters are used.
Any of these fonts can be used to good result:
Courier
Courier Final Draft (from Final Draft)
Courier Screenplay (from FadeIn)
Courier Prime (from Highland)
Courier MM Screenwriter (from MM Screenwriter)
The most commonly used font is Courier Final Draft.
You can download Courier Screenplay here for free.
If you want Courier Final Draft, you can download a free 30 day demo and copy the font from the app.
(Do not use Courier New, as it is not a 12-point, 10-pitch mono font, and it will misrepresent your page count.)
Here is a table listing the correct line length for standard Studio screenplay formatting:
You may find that Scrivener’s defaul margins/line widths are not to standard. You may have to make your own margin template.
Hope that helps.
Yes Courier screenplay 12pt is my normal font, it displays this same odd behaviour in Scrivener relative to Final Draft and Fade In. I just used Courier Prime in this illustration as I figured it would be a more “standard” font across platforms.
It just seems odd that scrivener, or the Qt font engine (which I admittingly know absolutely nothing about) as Tiho mentioned would wrap words so many characters before the element margins.
Tiho, is there possibly some work around for this through custom formatting of the elements?
The Qt engine generally has all the text rendering features and adjustment. Most likely the font kerning is something that one could play with. At the moment we do not expose this property to the user for modification, but use the engine and font defaults. I might give it a spin and try to expose this feature easily to the users. My best proposal meanwhile is to find a font which matches as close as possible the layout you treat as “correct”.