Thanks THIO and yes what GIMOX said.
This is not just a nice to have…its imperative to the offering.
Some comments.
I don’t generally write screenplays. I looked at the format, and I understand it, kind of (since I don’t write them, I’m not really familiar with it).
But the biggest issue I see with the two samples you showed is this:
Across Scrivener, the ruler is not accurate.
On-screen in Scrivener, Courier 10-point looks to be about 9 characters per “inch” (54 characters in 6 “inches”). It should be 12 per inch. And Courier 12-point runs perhaps 7 (44 characters in 6 “inches”). It should be 10 per inch. The ruler is wrong. Period. And the amount that it’s off changes with zoom level.
This is why the width doesn’t look right on the screen; it ISN’T. If you use 10-point type, it’ll look okay on screen, but you can’t send them 10-point Screenplays; you’ll look like an idiot.
Screenshot sections –
This is Scrivener’s ruler, supposedly 6", versus Courier 12 point type. Note, I can get 43 characters in there. Should be 60.
Here is what the output looks like, in Adobe DC reader, with a measurement of the width in red:
43 characters =~4.27 inches. That’s about right.
Until the ruler is fixed, you cannot get them to look right on screen, unless you pull some tricks on it (and you shouldn’t have to, I know).
Possibility 1: If you use 10-point type, it’ll look right (or close, anyway). But you’ll want to override the font in Compile to use 12-point Courier Prime or Courier New, if you do that.
Possibility 2: Stretch the ruler. Remember, 6" in Scrivener equals 4.3" or so. So move it out to 8.3", and 60 characters of Courier 12 will fit. But your tabs need to be adjusted, too, because they’re wrong, unless you fix it in Compile.
*** Technical bits. I think the reason the ruler is off is because the ticks on it are eighth-inch ticks, and Scrivener uses 6 of them per “inch”. So 36 ticks should be 6 inches were they 1/6 inch ticks, but… those ticks are 1/8, not 1/6, so 36 of them only amount to 4.5", instead of 6. I could be wrong, but the numbers are close enough to draw me to think this.
*** This may be addressable by scaling the ruler to correspond.
Beta 22 and still no fix… 
All y’all,
Do you see the [LH543] in the topic subject line?
That’s the tracking number for the bug associated with this thread. If that bug is not listed as fixed in each new version’s release notes, then it has not been fixed yet. BUT this does not mean the developers have forgotten it – it simply means that it did not make triage as one of the important bugs to fix for the new version. They have a database and everything to help track these bugs – when you see that number added to the subject, that means they have added it to the bug tracking database – and what their status is, including lots of research and commentary that they choose to not make public on the forum.
This DOES NOT MEAN that they think your bug is unimportant. They simply could need to dig deeper into Qt or some other related library to figure out what the issue is and how to actually fix it. They could be clarifying whether or not the observed behavior is in fact technically correct. They could have found that it’s a bug triggered by a boundary condition with another, bigger bug and they have to fix that bigger bug first. The fix may be known, but it could have been long enough to implement that the fix wouldn’t have made the cut-off date for this release and it wasn’t deemed important enough to hold back the release. It could be just simply that this bug doesn’t affect many people who are currently actually using the beta (relatively speaking) so that it is not going to float to the top of the list yet. And that list is not exhaustive.
There is no need to keep posting “not fixed” on each thread when your personal bug is not yet fixed. It IS helpful to post if the bug says it’s fixed but you’re still seeing wrong/unexpected behavior. The bug that got fixed may not be the one you thought it was.
Feel free to extrapolate this to EVERY OTHER thread in the beta test forum.
Ok so 2020, Beta 36 and not only is the screenplay formating still broken it seems to have gotten worse.
I figured with ‘Scriptwriting spacing fixes and functional key fixes’ listed in the beta 36 bug fixes list this ancient bug may have been put to rest. But somehow you guys have made it worse with text wrapping to be even more cramped and out of spec.
I just have to ask again, is this bug being worked on and will we ever see a fix?
If you go look at the release notes for Beta36, this bug number is not included in them, so one can conclude that this bug is still open. Since L&L no longer provides timelines and estimates, that’s the most information we’re likely to get until it’s actually fixed.
Yes yes bug nubers, got you loud and clear the last time. However that mentioned fix which had no number did sugested the potential for some kind of remedy to this screenplay format mess. Thats why I had high hopes but never imagined they would somehow make this ancient bug WORSE.
LL need to know that it is getting worse as that is the point of these feedback forums. A response from them as to why its now worse wouldn’t go astray either.
Indeed the latest version produce the same alignment of text and recognizes correctly almost all Script elements which come from Mac projects. We have few issues with some script elements, which are in the process of fixing, due to newly added options under Mac.
Apart from this the same project and text look exactly the same under Mac and Windows, having in mind that you use the same font and the font is available on both platforms like “Courier Prime” for example.
The compiled PDFs in general also look aligned at the same word at each line when the project is compile to PDF under Mac and Win.
Can you please show with some screenshots and a demo project what is the problem that you experience?
The ruler is also scaling properly in the latest version it seems(due to other fixes), although scaling with the bottom status bar control and the mouse wheel produce different results. For scaling use only the status bar zoom control. The Mouse wheel zooming will be fixed in the next update.
Wow Im confused, so bug LH543 is, in your opinion, fixed???
I do beg to differ. Once again the top is how beta 36 handles layout and the bottom is the screenplay pdf you guys supply which is how a screenply should be formated. Its not even close.
I am not sure how you created your Screenplay project, but loading a new Screenplay project and typing the same text (as the “Scene” document comes up empty upon creating a new template), results in proper formatting exactly as seen inside the PDF.
Here comes a screenshot from my tests and the project itself.
Inside your screenshot the ruler is not visible, so it is not clear what is your page size and margins, which could also affect the display text alignment.
ScreenplayTest.scriv.zip (144 KB)
Here comes a screenshot with a zoomed ruler too. As one can see the text wraps exactly at the same place and words, as at 100% scaling.
As far as I can see, nothing has changed since I reported this a couple of years ago here
https://forum.literatureandlatte.com/t/lh543-lh2773-change-in-page-width-font-size/40015/1
My text is still incorrectly displayed, exactly the same as in the screenshots in that post.
I’ll email a copy of the project to win3beta@literatureandlatte.com.
– edit –
- well I tried, but it doesn’t look like I can do this because gmail will not accept the zipped .scriv file as an attachment.
– edit 2 – - ok, I’ve sent a link to the project to win3beta@literatureandlatte.com
How many ways are there to make a screenplay? I simply go to file, new project, scriptwriting and choose screenplay. I do nothing else other than start typing in the scene page already there. and this is what I get:
The top is your screenshot, below that is what i get, and have gotten for the past 2 years with rulers included. Clearly Im not the only one.
I have a fresh version of windows 10 and this is the first scriv beta Ive put on it. Given its a fresh windows version the default windows display setings, scale and layout out was set at 125%. I have now put back to 100%. and it changes the wrap slightly (but still incorectly. This is what led me to believe this problem was getting worse as this efects how scrivener wraps text. which it shouldnt in any way.
Indeed your screenshot is about a different bug related to HighDPI/Non-HighDPI monitors. I believe your monitor is a non-high-dpi monitor with a 96 dpi native resolution, while HighDPI monitors use 2x72dpi(144dpi) resolution. Because of this we have an offset of 33% the regular scale.
When you have a combination of HighDPI/Non-HighDPI monitors installed, the situation does not get better. We are working on this too. It is not just a screenplay formatting problem, but a general text formatting problem on non-high-dpi monitors. Sorry for the long delay in fixing this, due to the constantly changing high-dpi Qt functionality and our source code interaction. Once we switch to Qt 5.14 (which introduces major HighDPI improvements) we will need to adjust it again, which is a heavy task.
Thanks for the explanation, Tiho, but…
Is there anything I can do about it? This is a non-trivial problem for screen-writing, a show-stopper. If there is nothing I can do about it, then I can’t use Scrivener 3.
The only solution for Beta 36 is to use a HighDPI monitor, but we hope to provide a working solution for non-HighDPI monitors in the following versions too. Most likely you will have to choose the monitor DPI type, if automatic detection does not work. Most likely moving a project window between High to Non-High DPI monitors will cause problems, but at least the single monitor mode case will be working as expected,
What exactly do you mean here by a HighDPI monitor?
And now I’m confused about what my monitor specs actually are.
This website dpi.lv/ says: Resolution is 1920 x 1080 Diagonal 13.3 inches . 166 pixels per inch.
This website infobyip.com/detectmonitordpi.php says: Your monitor DPI: 120 x 120 per inch"
(And I only use one monitor).
Here is some more info about my system (Windows 10, fully up to date).
Note that the second shot says there is a custom scale factor set of 175%, and the third says it is 125%! I can’t say I know why that is, and I wouldn’t want to touch these settings without knowing a bit more. Apart from the Scrivener beta, everything is working fine for me.
Simeva, you made me curious, so I took the moment and tested my very-well-known 17.3 in laptop on each.
- InfoByIp got it right: 96x96 px/inch, or similar if you try their other sizes (bigger potentially better, if any. Their method also looks sound at first glance.
- DPI love, on the other hand – at first wildly inaccurate, then I noticed you have to tell it how large your screen is before it can give any kind of answer at all – unless you just happen to be at the default 13.3in.
- So I set my 17.3 via the tiny link, and…it said my screen was 103dpi. Not hardly. I would really give that one, DPI love, a miss…
Late, so that’s what I can say…
Hey guys,
There’s actually a preceding report of this same bug LH543 plus another related bug LH846 from November 2017.
https://forum.literatureandlatte.com/t/lh543-lh846-scriptwriting-mode/38420/1
I have the same problem as Simeva. It has not been solved yet.