[LH543] Screenplay formatting still broken??

pcook · July 2, 2019, 8:20am

With the missed release date just gone and the new, new, revised released date put out, just wondering if the script layout mess which has been with us and noted since the very first beta is ever going to get some love?

The top is how the beta spaces and wraps text, the bottom is how an actual screenplay should look. The bottom is how it looks on any screenplay app you care to name, its how it looks on the original windows 1.9x, its how it looks on the ipad app and its how it looks on scriv 3 for mac.

Please tell me this is being worked on? I cant believe something as simple as formatting has eluded a fix for 18 iterations of beta releases.

thePhilosoraptor · August 6, 2019, 10:31pm

This has been filed. Thanks.

pcook · August 20, 2019, 7:26am

Ok we are now at beta 21 so just wondering is there something I need to do like settings reset or spin in a circle 3 times and clap my hands to make the screenwriting module workable?

I mean surely after a year and a half, 21 betas, two missed weekly betas and an official release candidate…a simple formatting / layout bug fix isn’t too much to ask???

I really hope I’m missing something here…

devinganger · August 20, 2019, 7:54am

Patience?

pcook · August 20, 2019, 11:34am

tiho_d · August 21, 2019, 10:33pm

Please, send me an archive copy of the sample project to tiho at literatureandlatte.com and I will have a look at it. Thanks!

pcook · August 22, 2019, 7:58am

Not sure I understand why you would need that?

If you create a new screenplay project and type out the sample script included in the template as I have done do you not get the same incorrect layout as I and many others do as illustrated in the screenshot examples provided?

EDIT Ive just installed beta 21 on a brand new laptop that has never had any version of scrivener on it with the same result. Ive opened a new project and under the scriptwriting option I choose the screenplay template. In this template is a sample script in the research folder. How this pdf looks in terms of layout is EXACTLY how a screenplay needs to look and is EXACTLY how any other screenwriting software on the face of the planet formats it. Except for betas 1 through 21

tiho_d · August 22, 2019, 11:32am

Thanks PCOOK! After looking deeper into the issue, I recall the problem and you are correct. I do not need a demo project. Unfortunately this issue is not easy to fix, but we will give it another try with the latest Qt version.

gimox · August 22, 2019, 12:15pm

Yes please, i really respect your work and i love Scrivener so much, but this is literally one of the oldest bugs and to still see it in a release candidate it’s a bit disheartening for us screenwriters. Of course the software is solid overall, but then again you have the Screenplay format that is still in early alpha stage and unusable not even for testing purposes, figure for professional use.

We owe you patience and respect for your work, but please fix it before official release, it’s a really huge bug that makes the screenplay format just broken.

Thanks

pcook · August 23, 2019, 5:14am

Thanks THIO and yes what GIMOX said.

This is not just a nice to have…its imperative to the offering.

rwfranz · August 23, 2019, 7:11am

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.

pcook · August 28, 2019, 6:31am

Beta 22 and still no fix…

devinganger · August 29, 2019, 5:56am

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.

pcook · January 31, 2020, 6:32am

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?

devinganger · January 31, 2020, 7:54am

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.

pcook · January 31, 2020, 8:47pm

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.

tiho_d · February 1, 2020, 9:10am

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.

pcook · February 1, 2020, 12:22pm

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.

tiho_d · February 1, 2020, 2:52pm

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)

tiho_d · February 1, 2020, 2:57pm

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.