LibreOffice Writer seems to have problems with displaying fonts under somewhat arbitrary conditions (zoom, font type).
Note:
- This problem doesn’t show up on
printed pages. - Monospaced fonts are not affected.
This image illustrates the issue:
I wonder if the problem might be with the internal co-ordinate system used to render pages, as opposed to the resolution of the actual screen. For instance:
I get a document on a 4K screen, I scale it to “Entire Page”. I view it in different desktop scaling factors. the point being that the actual text is being rendered at about the same physical size on the screen, with the same number of pixels available to it, even though the LibreOffice zoom % is different, so with the scaling factors applied, and bearing in mind we shouldn’t be scaling any bitmaps here, at any point, the text should look about the same.
-
At desktop scaling factor 100%, LibreOffice “Entire Page” zoom is 245%. The text looks fine.
-
At desktop scaling factor 200%, LibreOffice “Entire Page” zoom is 115%. The text looks, ok, not as good.
-
At desktop scaling factor 300%, LibreOffice “Entire Page” zoom is 72%. The text looks awful.
You would actually expect that kind of difference if you zoomed in, or out, on text in a single screen mode, and took screenshots.
But remember, the actual display resolution is the same. Ultimately we’re outputting text at similar sizes at 3840x2160. There are two scaling factors being applied, the desktop scaling factor and LibreOffice’s internal Zoom. But the upshot is that after the scaling has taken place, it has the same number of pixels in which to render the text at about the same size. (Only not the exact same size because of the different amounts of space taken up by window/desktop furniture in the 3 screen modes, so “Entire Page” zoom doesn’t produce exactly the same size. But it’s close.) So it’s not about the resolution of the output device.
But it’s not behaving like it has the same number of pixels to render it in. At the higher desktop scaling factors, it looks like it’s got fewer pixels to draw into. So the text is blurrier (more anti-aliasing) and the position of the letters is often a bit off, at least horizontally.
It looks like it could be the internal-to-LibreOffice co-ordinate system into which elements on the page are rendered. This would appear to be a fixed resolution. So when the desktop scaling factor goes up, this co-ordinate system is no longer granular enough to accurately position stuff in its space.
eg: if it’s an integer (or fixed-point) co-ordinate system, each unit is just too big. The co-ordinate system needs to be considerably more granular, eg: by another decimal point (or I suppose an order of magnitude).
If it’s a floating point co-ordinate system, I wonder if we might actually be seeing the effects of floating point inaccuracies being amplified into significance by the desktop scaling factor.
And of course anti-aliasing needs to be directly relative to the actual screen resolution.
EDIT:
I looked at OpenOffice.org. It does render the text properly, and consistently. However its HiDPI support appears to be mostly absent. Ironically I think it’s working because it doesn’t have proper HiDPI awareness. So for instance with desktop scaling at 100%, 200% or 300% the same internal zoom factor produces the same size text on the screen. Of course the rest of the application looks a mess at anything other than 100%.
When you use desktop scaling, you trick applications to think that it’s having proportionally less DPI. If you have, say, 240 DPI screen, and use 200% desktop scaling, it means that DM will tell applications that they are on 120-DPI screen, and if you use 300% scaling, apps will be told they have 80 DPI. So they render relevant image to screen, which is being stretched back to 240 DPI by DM, but all the problems of rounding errors are already there. Being unaware about HiDPI “fixes” that…
Yes. But it only affects LibreOffice, of otherwise HiDPI aware apps. Its internal co-ordinate space is being scaled with the desktop scaling factor; probably the right thing to do, but the granularity, or resolution, of that co-ordinate space doesn’t increase to match, and it needs to.
I assumed it’s not actually plotting into a bitmap and just scaling that, based on the 300% text not being obviously pixellated. But now wondering if that’s Image Viewer applying an upscaling algorithm.
If a HiDPI application uses sub-pixel positioning, then it will not have these problems that visible. LibreOffice does not have that support. LibreOffice “coordinate system” is in terms of document size (1/100 of mm), starting from document’s top left corner (e.g., in case of Writer). When it outputs the glyphs, it uses integer coordinates (here is the problem), and being HiDPI-aware, it uses the DPI reported by system to calculate coordinates.
exactly 
with a bit more detail than I had. I was all supposition. It probably needs to be working to micrometers now.
This may not be the correct answer but remember that the “dot density” is much smaller on screen than on printer.
The most frequent screen density is 96dpi while printers play with 300 or 600dpi. Fonts are usually designed with printer density in mind. What complicates the issue is that glyphs are also frequently described by curves (so-called vector definition) not by bitmaps (which do not scale well).
LO and other word processors compute the placement of glyphs at very high accuracy but then they must cope with the physical properties of the output device. This means characters will be aligned on the output device grid. A pixel is a pixel and you can’t draw anything which is not an integral multiple of pixels.
When a glyph dot must be displayed, decision is made to put it in a device pixel bin: the nearest, the one which will contain most of the dot or some other determined by a sophisticated algorithm.
You mention that the same word is not painted the same in different positions. This is so because the fractional part of the word origin (in screen coordinates) is not the same in these locations and the algorithm chose a different “rounding”.
What you see is a consequence of subsampling. The smaller the character size, the worse the aspect.
I do not think that LO is to blame. Usually, font display is an engine located in the OS. Consequently, all applications are affected, but it shows more in word processors because documents have many different fonts with different sizes whereas “technical” (or rather not document-oriented) applications use a single character size in a well-chosen font in order to be less sensitive to this phenomenon.
If this answer helps, please check the tick mark and, optionally, upvote it.
EDIT
Some font engines use a trick to provide “sub-pixel” positioning.
Considering that color screens are built with vertical color stripes (usually in order RGB), they send colored dots to address individual stripes. If you look at the screen from a sufficient distance so that cell colors blend, you get the desired effect.
There is also the “anti-aliasing” processing where characters are “blurred” with extra color pixels to deceive the eye and brain into imagining smaller pixels thanks to the human image recognition (we’re expecting characters and match “inexact” shapes to glyphs).
That explains a lot. I’ve noticed fonts always look well aligned on HiDPI displays. I’m assuming if I buy a 4k monitor the problem will be less apparent. Although having used Microsoft Word and even OpenOffice they seem to do a somewhat better job at this. I’ve managed to pick a font that works best and keep the zoom at 130% which works as a temporary workaround. Thanks for the answer.
Usually you have a ~2k ~20" monitor. I don’t know of 4k 20" monitors, they are commonly ~40". Which means you see the pixels under the same angle. Unless you display your characters very big, you won’t see any difference and you will use the same workaround.
There are 4k 24" monitors around (Dell for example), my tablet has 260+ DPI and every document looks great.
From what you’ve said, I gather that given a HiDPI display, when the program makes a bad judgement as to where to put the glyph and is off by few pixels in alignment it wouldn’t be as noticeable if there are lots of fine pixels (HiDPI) as opposed to few larger ones (my current 1920x1080 22" monitor).
Right, provided the application or OS makes the density adjustment. Unfortunately, most applications consider screen density to be fixed at 72dpi (the historical density) and 1 pixel = 1pt! They do not convert from the typography world where 72pt ~ 1" and the screen density which would require to fetch a different (bigger) font size, not to speak of TAB stops and other dimensions.
Sorry, but that’s not a solution. I have a screen with a proper resolution and all word processors except for the Linux flagship one do the job much better. This situation is hardly satisfactory…
I sort of remember having read that the font engine used by LO changed recently (read ~2-3 years ago) which seems still to lack some previously available features. Add to that that newest fonts are based on quadratic curves instead of cubic splines which will cause less nice-looking rendering at small sizes unless the font file contains adequate bitmap glyphs.
We don’t have sub-pixel positioning support. Our output uses integer coordinates, which only leaves us with anti-aliasing to handle the problem. There’s an RFE: tdf#103322 for that.
I should have followed that link to that bug report before. That’s it, isn’t it. Looks like it’s just waiting for someone to do the boring work of switching those types and following it through.
Thanks all for an enlightening thread. I find the LO screen font display sufficiently distracting to look it up in this forum. Planamesa’s NeoOffice does not mangle character kerning and baseline alignment, but unfortunately there are no more updates available to me (for Mavericks).
I have been trying to make myself live with the sub-standard aesthetics. But I would suppose they are challenging for anyone who is concerned with layout and typography.
I hate to put it back on the shelf, but I think I have to for the sake of my peace of mind while composing.