have we been here before - font rendering on screen?

Scrivener Scrivener for Windows
1

We have, in early days and in detail, and my memory is that it was all decently cleared up. A certain Qt release was involved, as they admitted the problem.

Now there is apparently a problem again, if you are not using Microsoft fonts, which generally look fine. As the included screen image and pdf show, the screen is where the problem is. With Scrivener 1.9.5.0, the printing even direct to PDF or printer looks fine, as does the result compiled to Word 2013.

There’s lots of talk over Qt versions for font rendering issues on the web recently. Most of it is Linux-orientated, and it is possible one of the configuration file fixes there would work at least to reasonable degree. There in fact appear to be several problems, with errors on certain kernings within certain fonts even if the weight and general kerning looks right.

My model for thinking this can be fixed adequately is Calibre, and I wonder if Kovid Goyal, who seems to be a very generous type, wouldn’t be able to give some advice. I find his current Calibre ebook reader part of the platform has that right-weights, right general kerning, and only specific pairs on specific fonts issues at all. A few of those is much preferable to spindly all the time as many Adobe fonts for example have apparently at present on Scrivener, no?

It’s great to have the iOS-ready Windows Scrivener today, and to know the feature-parity 3.0 is coming. I would think going after font rendering again would be pretty important to the nice work intended.

Many thanks for it all, and I hope this minor analysis can help. While remembering early days, Lee :wink:, where you were so patient, as ever.

Clive

Hmm. Forum’s not going to let me upload the fonta.pdf which shows the good compiled/printing results, too big with the included fonts, so will do that via Dropbox, here: dl.dropboxusercontent.com/u/2904697/fonta.pdf

The fonta.png attached shows the hard cases with the good, those mainly Microsoft, which we know uses an entirely separate and separate kind of renderer (if we still know that…!).

fonta.png
fonta.png997×896 92.5 KB

2

A note or two further.

  • I had a moment where I thought I might take back my report. But no, the problems are there, just can be masked a bit by magnifying.
    The png was taken at 135% magnification, which matches to paper size for my screen, nominally 96ppi. You can see the bad kern on Sabon, and the thinness of Adobe Text, Brioso, Hypatia, Minion and so forth, also Frutiger 55, Tekton, etc. for certain non-Adobe renders.

  • if you go up to 175% zoom, then the kerning tends to smooth out, and the fonts appear better, though the weights are still off. This might be a workaround to use them for now, if your screen is big enough and you can get along with it, as it doesn’t affect any Compile output file results.

  • I remember now to say that turning hinting on and off in Options made no discernable difference, which may be a strong ‘hint’ itself.

  • I’m having a problem at the moment that Zoom or manually setting the percentage at the bottom of the screen isn’t ‘taking’ – the change only shows if you use the Microsoft full/partial screen box at the top right of the window. This continues across reboots of Scrivener 1.9.5.0, so it is probably a bug also.

  • all these fonts look reasonably fine in MS Word 2013, at 108% to give ‘real size’ compared to my printout.

  • If you want a very quick check on the response with MS vs non-MS fonts, just compare Adobe Text to Times New Roman, on screen. Text is thin, yet it is supposed to be a modern replacement newspaper font for Times. On the pdf, you can see that it really is, very similar weighting if the form is a bit different but still in a kind of ‘look’ as they wanted.

  • I tried both of the config file contents here, putting them in my Win10 ‘home’’ directory (/Users/narra) at a guess where they should go on Windows, but no results. Maybe they go somewhere else? As the appearance change on Linux appears in the ballpark for what’s wanted. http://forums.debian.net/viewtopic.php?f=6&t=46535#p265839

3

The font rendering issue seems to be due to the fact that in Scrivener 1.9.5 they’ve broken DPI-awareness (if it ever worked).

Scrivener now renders at low res and upscales, which would explain why the text rendering is odd - everything is blurry.

I don’t think the text rendering is at fault, the app just isn’t DPI aware.

4

Right, Scrivener 1.x isn’t (has never been) HiDPI aware; it’s a limitation of the older Qt framework that will be resolved with the next major version of Scrivener, which uses a newer Qt build that does support true HiDPI awareness. Previously, Scrivener did not scale at all on high resolution displays, causing tiny windows, etc. and the solution was for users to have to make a modification to the registry settings to allow the scaling. Many users did this and appreciated the scaling, but having to modify the registry does come off as a bit daunting. 1.9.5 now allows the scaling automatically, so that Scrivener will respond to your Windows settings for this. You can right-click the Scrivener.exe and choose Properties > Compatibility > Disable Display Scaling if you have enabled display scaling on your PC but don’t want Scrivener to be affected by it.

That said, Clive, you might try that and see if it makes a difference; also check the Windows settings for ClearType. Font encoding was changed in 1.9.5, but nothing about the display.

Are you talking about Scrivener’s zoom in the editor or the zoom for the Windows display? Scrivener offers a selection of zoom percentages from the editor footer, but not place to manually enter it on a regular text document–are you referring to viewing PDFs in Scrivener’s editor?

5

Hi Jennifer, and will keep this simple, so I don’t lose track…

  • DPI awareness – yes, definitely sounds likely cause. It’s the one thing I won’t fiddle with on this Win10 laptop, having been bitten hard there before, and as an actual software-capable guy, sensing the rat pit.

  • my problem on screen magnification had been with the Scrivener pop-up at the bottom of the screen. It’s back to working, and there was a laptop reboot in between, so that’s probably the source of problem. I had had it up doing all kinds of things for days, Docker, etc., and you know, even with a very stable and up-to-date Win10-64, esp. in graphics driver area it will eventually go flonky. So don’t concern about this one.

  • now, there is one you want to look at, which I’d prefer not to menction at present here. There’s another email with three zips in it and account of what happened, also its recovery…red star on this one.

  • what I was doing when the previous came up is trying to ascertain which fonts survive being synced to iOS and back. I believe the answer is, only those on the ‘Recommended’ part of the iOS app’s font list (paintbrush popup). That’s a small set, I have no idea why. I have for example Palatino on the Laptop, but it doesn’t agree with Palatino on the iOS app. Anything off the Recommended list gets marked to Arial in the iOS app, and comes back similarly transposed on Win Scrivener. Although sometimes I get Arial/Helvetica or something similarly benign, and sometimes I get that weird script font, which I do have installed. It must be defaulted somewhere (by number no doubt), and I have not been able to find iOS Scrivener’s defauilts. Maybe if I find and reset on Windows Scrivener, will see. I would certainly like to suggest feature addition, that the font records are separate for Win/Mac and iOS, so that when you get a file back, it returns to whatever decoratives you’ve used. Or not, if that’s Keith’s view, of course.

  • I tried Disable Display Scaling, but as you might guess, it didn’t work, on this 1600x900 ordinary laptop.

  • Added: I tried ClearType settings, was on and ok, but set it for a darker/bolder look as that will help my eyes. Result: it improves the spindly look a bit, but the real weighting is clearly not done. Compare Adobe Text with Times New Roman, a good test as they should be similarly newsprint-capable heavy, and Times as an MS Font is; Adobe Text definitely not so much. If I compile a Preview, still looks bad. If I compile to PDF, the fonts all have good weights – Adobe Text is heavy as should be, for example, now matches Times New Roman, all other non-MS fonts now looking as they should individually. QED something :wink: am sure…

Cheers on all,
Clive

6

Well, ‘simple’…but I tried, on each item.

Do note that addition at end please, as I tested further and wrote that after the initial post.

C.

7

As everyone has noticed, the GUI on HighDPI monitors is much better, but font rendering on HighDPI monitors is bad. These fixes might have spoiled the GUI resolution on Non-HighDPI monitors, but we never experienced issues with this in our tests. As soon as we have a reproducible use case and a hardware to test it, we are more than happy to fix it.

Fixing the font HighDPI rendering in Qt4 is not easy. Have in mind that we also have custom buffers to provide proper font zooming. Qt4 does not provide proper font zooming out of the box. Qt4 also does not report any window changes when moved in between HighDPI and Non-HighDPI monitors. This has been improved dramatically and fixed in Qt5. We also test fixing it in Qt4 at the moment, but without much success. Fixing the HighDPI GUI is one thing, but fixing the HighDPI font rendering with custom extensions is a totally different story. Have in mind that Qt4 can be compiled only with VS2010, which also lacks some manifest HighDPI adjustments available in an up to date VS. With Scrivener v3 and Qt5 it will be much better, but we are also doing our best to fix it in Scrivener v1.X with Qt4 if possible. Please, have some patience.

8

Thank you very much! That’s really helpful.

PS. You can apply a custom manifest in any VS version, so that shouldn’t be an issue in practice (eg. we use VS 2005 in order to target XP & 2K through to Windows 10, and we can set a dpi-aware manifest there).

9

Hi Tiho, and thanks also very much for this.

Please be assured that we do have patience; are just trying to get you the best data to work with. As mentioned elsewhere (and echoed in your mention of 2010 libraries necessarily used, good old Microsoft…) , certainly everything gross and difficult about this area is well appreciated.

I’m trying to think of a non-Microsoft font you can use for validating on ordinary-DPI screens, and then can provide a test project. I think I’ll use a ‘good’ free font which is dramatic enough with the problem, and pass that to you along with.

Coming up, then.

Kind regards,
Clive

10

And, here are your test materials, Tiho.

Included: a Scrivener Project, three free fonts it uses, and a PDF output to compare with screen.

An edge case mentioned (Museo 500) as i think it’s a tricky point to be aware of, showing with other naturally heavy fonts.

The project and PDF include a few Adobe or Linotype fonts, which if you might have at least one of them, can view the more serious problems there. And actually, I can show those and the Museo issue too, so now there is a png provided straight from the Scrivener screen.

Enjoy please; hope this build your desired test case, Tiho.

Kind regards,
Clive
tiho screen appearnce materials.zip (989 KB)