Discussion Forum

Forum Navigation
Please to create posts and topics.

Scrite Script Right-hand margin

Quote from bidmead on July 23, 2021, 2:43 pm

I'm having to do more than just "cheat" the formatting to get the various Scrite elements to behave as I believe they should. I'm having to blast the font size up from the industry-standard 12 point all the way to 22 point.

There is something clearly off with Scrite on your computer. May I ask you to post the following bits of information?

  1. I guess you are using Scrite on Linux, what's the PPI setting on it? It should ideally be 96.
  2. What kind of display do you use Scrite on? Is it a high-pixel-density display or a standard one?

 

Uploaded files:
  • ppi-setting.png
Quote from bidmead on July 23, 2021, 2:55 pm

…however, I've just discovered that in Scrited, the 12pt version of that same script is rendered much more closely to what I'd expect.

And thanks for the ability to whisk away the video window. Very helpful indeed.

Ok. This means that we have to figure out whatever is going on with PPI computation. Please post your responses to the questions I listed in the previous post. We should be able to find out what's going wrong and fix it.

Quote from bidmead on July 23, 2021, 2:43 pm

The only other problem I'm having with Scrite, independent of the wrapping, is the trackpad acceleration, which whooshes the scrolling faster than I'm able to control, making it very hard to shift up and down the script pages.

In the latest nightly build, there is a way to adjust scroll/flick speed.

Just head to Settings > Scroll/Flick Speed and move the slider to make it slow or fast.

 

Uploaded files:
  • scroll-flick-speed.png

Thanks, @prashanthudupa. That's helpful. The default resolution of this laptop, as reported by Scrite, is 158ppi. I'm very surprised that Scrite should need to know this—surely a line of text in 12 point Courier should wrap at the same position irrespective of the precision of the display? It seems that Scrite may be using one set of metrics to determine the font display and another to determine the margins.

Yes, setting Scrite's ppi to 96 does now match up the line breaks of the edit page with the line breaks appearing in the print preview.

I hadn't spotted that scroll/flick speed setting. That's helped a lot. The only remaining point here is that there's no control over the inertia, that is to say, the time taken for the screen scroll to halt once the finger has stopped scrolling on the touchpad. The most generally useful inertial scroll is zero—the screen scrolling stops the instant the touchpad scrolling stops. A higher inertial scroll value is useful for travelling across multiple pages but makes shorter hops very fiddly.

--

Chris

 

Quote from bidmead on July 24, 2021, 8:43 am

I'm very surprised that Scrite should need to know this—surely a line of text in 12 point Courier should wrap at the same position irrespective of the precision of the display?

Yes, ideally it should. But we found out through trials that it doesn't on a small subset of machines. Which is the reason why we have the DPI settings box in there.

By default Scrite resorts to 96 on Windows & Linux, 72 on Mac. I have no idea why it picked 158 on your computer.

Anyways, glad that the word-wrapping issue is resolved for you.

Quote from bidmead on July 24, 2021, 8:43 am

I hadn't spotted that scroll/flick speed setting. That's helped a lot. The only remaining point here is that there's no control over the inertia, that is to say, the time taken for the screen scroll to halt once the finger has stopped scrolling on the touchpad.

The scroll/flick setting currently impacts both flick-deceleration and flick-velocity. Perhaps we can split them apart as two distinct settings.

OK, thanks again, @prashanthudupa. As I say, I'm surprised to see that this PPI adjustment is necessary and I hope you'll manage to find some way around it once we leave the beta.

Meanwhile, I've been checking this on various machines around the office (It's magnificent that Scrite runs on all three major platforms) and it seems that a manual calibration process may be necessary before the margins in the editor line up properly.

Luckily, this is easy to do. This is the method I've been using—let me know if there's a better way.

  1. Import or write a page or two of script, using all the different elements (Scene heading, Character, Dialogue, Parenthesis, etc).
  2. Hit the left-most of the buttons on the top right of the window to "Preview the screenplay in print format".
  3. Take a screenshot of this or memorise where some of the words break at the end of several of the lines.
  4. Return to the editor. Are the line breaks the same? If so, all done. If not, proceed…
  5. Hit the Settings and Shortcuts cogwheel in the line of buttons up in the top left-hand corner.
  6. Open Settings/Additional. The Page Layout (Display) panel displays your current default resolution. This will need adjusting.
  7. If the lines in the editor are longer than the lines in the print preview, you'll need to type in a lower PPI number (and vice versa).
  8. This might take a bit of toing and froing but you should be able to get the line lengths to match up and Scrite should now remember this.

I'm very grateful to you, @prashanthudupa, for pointing me in this direction. If there's a better way, do please let me know. My first ignorant stab at this, blowing up the font size, kind of works but is definitely not the way to go.

I hope this helps.

--

Chris

 

 

Quote from bidmead on July 24, 2021, 4:39 pm

OK, thanks again, @prashanthudupa. As I say, I'm surprised to see that this PPI adjustment is necessary and I hope you'll manage to find some way around it once we leave the beta.

Thanks for confirming this. It appears that we do have an issue with Linux versions of the app. Looks like it is not picking up 96dpi by default, but it is picking up a value that is determined as a function of the display's pixel density and pixel-to-real-world-size ratio.

Since you say you have tried it around on various computers in your office, just wondering if any of them were Windows PCs or Macs. If yes, do you notice this issue on those systems as well?

Thanks @bidmead for being so patient and helping with uncovering the mischief behind this.

Apologies, @prashanthudupa. "Around the office" was a bit grandiose.  Specifically, an Ubuntu laptop (the original figures from which I've already reported), a desktop Hackintosh running MacOS 10.12.6 (default resolution reported by Scrite as 90, tuned by the procedure I've described to 70) and a dual-screen Intel NUC also running Ubuntu (default=118, tuned=95).

I've approximated the default ppi to integers. Scrite reports this value to 14 places of decimals (Mac and Linux), which is also something you might want to fix.

--

Chris

Prashanth Udupa has reacted to this post.
Prashanth Udupa

@bidmead: In the latest version we show a rounded off integer for resolution. Thanks for pointing out this blooper.