Options window displays with bottom part out of view and inaccessible

Beta realease: 3-12-20- – 31-12-20

Options window displays with bottom part out of view and inaccessible . I can’t resize or drag the window to access the control buttons along the bottom. Attempts to resize window just jump back to previous display.

Your monitor resolution is too low, or the scaling is too big. Recommended number of vertical resolution is 1080 px or more. If you use less then 768 px we do not guarantee that all Scrivener windows will fit. The Compiler window is another window which might not fit on small displays.

I’ve had the following settings as is for 10 years:
Laptop is 15.6" set to 1366 x 768.
Magnification increased from normal (100%) to medium (125%.)

The options pane on all previous versions of Scrivener has had no trouble displaying or enabling re-sizing/positioning of the options window pane on these settings up until now so something’s changed in the 3-12-20 beta. My Scrivener V1.9.16 displays the options pane in full without this issue too.

I would therefore conclude this is a legitimate bug.


Windows no longer allows us to move a window by mouse or keystrokes to a point where its title bar is beyond the top of the screen, making it difficult at times to get the bottom edge of a large window into view. Fortunately we can still move the window into negative territory via AutoHotkey. The sample code below will move the left corner of the active window 250 pixels above the top of the screen, on Ctrl-T. Dragging any visible edge of the window will reposition it to display the title bar again.


Rgds - Jerome

Most likely you have used the Non-HighDPI version of Scrivener previously.

I wasn’t aware the beta came in high and low DPI - only 32 and 64 bit where i’ve been downloading 64bit when available. The last,64bit beta which expired on 2-12-20 displayed the options pane fine.

Can you not just enable floating panes to be re sizable where that’s a basic function of any pc interface, especially if you’re going to build in increased/variable DPI ?

The workaround offered by JJ Slote isn’t really suitable for non programmers and is inelegant, where part of the pane always remains lost.


Fitting displays with less than 768px (as you are using 125% Windows Scaling) for all Scrivener windows is a significant overhead, as they must be equipped with scrollbars to show you all the options, which also makes them harder to work with. Making the Windows smaller is also not possible as we cannot fit all the options and text. The current window size is the minimum Window size needed to fit all the options. You can resize the window to get it bigger, but cannot resize the window to make it smaller, because this is the minimum size needed by the controls within the window.

In RC13 we switched the default Scrivener update and download to the HighDPI version of Scrivener, which handles properly the Windows Scaling factors and multi-monitor PCs. The previous version of Scrivener used an older version of the Qt library, which did not follow properly the Windows scaling factors.

That’s a real pain because it means setting options in Scrivener on any of my windows 15.6" laptops requires me to me re-scale the display down to 100% and then log out/in and then re-scale to 125% and then log out/in when i finish setting options… All this just for one window. I don’t seem to have this issue for any of the other floating windows.

This new Scrivener handicap introduces hyperopic (requiring larger characters) prejudice because it favours myopic-centric (requiring smaller characters) vision. This tendency has plagued Scrivener development, particularly regarding the Binder icons.

In terms of software targeting people who spend their lives writing text on a pc screen, it’s not reflective of the trajectory of visual-health -diminishment over a life time to constrain Scrivener to myopic-centric users alone. I would have thought it would be considered central to Scrivener’s success to accommodate changes to the user’s visual health over a life time as part of overheads rather than outside them.


Sorry but you write on a small 768px screen and worry about your eye health? If this is your main concern buying and decent size monitor should be your first thought. These small size(tablet size resolutions) might be useful for work on the road, but I would never use such a small display for an everyday use, because I care about my eye health.

Most tablets nowadays have higher vertical resolution.


I don’t think you should be knocking the ubiquitous portable screen size of 15.6" for windows laptops - it’s a perfectly acceptable, in fact, very good size for on-the-go writing - also with visual health in mind. I also note that as far as windows was/is concerned, it is it’s presence on a wide range of pc/laptops which is seen as it’s advantage.

Point taken about laptops currently mostly HD or HD ready resolution.

So with that said could you confirm the following:

Will the new DPI Scrivener released in RC13 installed on a portable windows device with display up-scaled from 100% to 125% have it’s floating panes fully visible for:

  1. HD Ready 1366 x 768
  2. HD 1920 x 1080
  • on both a 15.6" or a 14" windows laptop. I specify these 2 screen sizes because they are the most prevalent screen-size windows-laptop currently on the market .

I’m clearly going to have to purchase a new laptop so guidance is appreciated now the DPI issue has surfaced and as, previously stated, where the display up-scaling facility is an important tool for those with hyperopic orientated vision.


Display at 768px at 100% scaling should be boundary line but OK. Display with 768px at 125% scaling (which results in ~614 logical pixels) is not OK.

Having a 1080px display or above is recommended. Obviously using 1080 physical pixels monitor at 200% scaling (resulting in 540 logical pixels) is not OK.

If you prefer working with bigger fonts you should aim for a bigger and preferably higher resolution monitor, or you will end up reducing the monitor scaling if you cannot reach at least 768 logical pixels display.