Re: Lite text editor

[Francesco Abbate <francesco.bbt@...>]

> The screenshots are not very helpful for me, given that the "subpixel" rendering uses a larger font size in these screenshots.
> To make a true difference the font metrics should be preserved.

Good point. I have got a problem with the exact font metrics because
stb_truetype and freetype2 behaves differently. This is something in
my list of things that I have to fix. Nevertheless I thought that it
was still meaningful to compare the image even if the font sizes are
slightly different.

My idea is also that people may try the application itself, either
using the binaries I provided either compiling the code.

> In fact I suppose that on Windows this is not even needed: the text rendering is already hinted by Windows's text renderer used by default with its existing display settings (so it is already using CleartType, with gamma correction and subpixel RGB/GBR display, using also a convolution matrix on the 2 nearest subpixels on each side to correct/avoid the color artefacts that could appear).

You are right when you say that windows use the ClearType technology
but Lite doesn't use it. It does sidestep whatever Windows may use and
it just writes by himself the fonts on a pixel buffer using its own
algorithm. What it does is grayscale rendering, without gamma
correction, without hinting, without subpixel.

If the Lite editor was using the native Windows font rendering I would
not have been no need to improve anything in the font's rendering
system.

> Note that subpixel rendering also has to take into account horizontal/vertical orientation of the screen (yes screens can be physically rotated, especially on mobile devices, but also on some desktop displays: Windows can capture the event where such rotation occurred and will adapt automatically the ClearType settings by using a different subpixel matrix, and font hinting will still occur appropriately; the convolution matrix is not a square but a rectangle, or 3 squares; and the grid of minimal resolution has one of the dimensions with triple resolution along the RGB/GBR axis which is not necessarily horizontal)
>
> Windows also is aware that some displays do not use RGB display (with horizontally aligned subpixels with the same surface): there are other display technologies that use 4 subpixels: R/G/B plus white, or R/G/B plus yellow and these subpixels are not aligned horizontally and don't have the same proportion. So basically the pixel grid is still prevailing, font hinting must still occur in both directions, and the adjustment for color correction has to take into account subpixels and consider their actual geometry in the two axis simultaneously if you want to improve the rendering!

Once again you are right. In theory one should get information about
the nature of the display and adapt the font rendering to the nature
of the display.

This is also on my list of things to do. In the mean time the rule of
the thumb is:
- on desktop system use subpixel rendering with RGB ordering
- on very high DPI system do not bother about subpixel and just do
grayscale rendering

or another option is to adopt OS native API for rendering the fonts
but this means you have to write very OS specific code for each OS you
want to address.

> For these devices, the subpixel matrix (for the coordinate resolution) is not 3x1 but 2x2 (if the subpixels form a regular grid of squares) or more accurately 3x3 or 4x4 (if they are not all the same size), and the color correction (into nearby pixels) is using a different convolution matrix (9x9 or 12x12, instead of 9x1 with classic RGB/GBR geometry). In all cases, there's still a gamma factor for this correction, but most LCD displays use the same gamma factor in order to be compliant to the sRGB color model. With this kind of display, you cannot just compute the 3 color planes separately (like for RGB/GBR), you compute 4 "virtual" color planes, then you recompose the 3 RGB color planes to generate the sRGB display (you have to know how the display transforms sRGB into the 4-components; this transform requires that sRGB is encoded with 9-bit per R/G/B plane at least, to get at least 8-bit on each one of the 4-component physical model; these displays actually take an sRGB color model on input with more than 24-bits, e.g. they take 10 bits for R, 11 bits for G and B for a total of 32 bits for all color components, and from this they will compute 4 components with at least 9-bit for each; some devices are now using 48-bit sRGB input and will accurately render 4 components with at least 12 bits for each: they generate a very great color gamut, especially in the natural brown-green colors, but as well in the darkest areas of images, or with improved contrast in the very light areas where the "grain" texturing is preserved; shadows are subtle but much more evidently visible, so the 3D-depth effect is improved as well).
>
> Such devices with improved colors (better than plain 24-bit sRGB) are still rare on the desktop, but now common on mobile Hi-DPI devices (like tablets and smartphones) and on large smartTV displays (see Samsung), it is even more economic than building an 8K display (a 4K display is enough, 8K displays are not worth the value if they still use the native sRGB horizontal subpixel geometry as their subpixel contrast is poor and the color gamut is too much restricted to see a convincing difference: the horizontal alignment of physical subpixels is not optimal and does not match the actual human vision); 4-component displays are definitely an excellent solution for the many people (most often male people, more of them Caucasian) that have color-vision "defects" but are still not dichromat or achromat (they are trichromat but with a modified green cone sensitivity slightly moved towards the red wavelengths), or for the rare people (most often female people and Caucasian) that can see more than 3 color planes and see more colors than the average population (e.g. they have the two different green cones centered at different wavelengths, or have an additional type of cones whose sensitivity is centered on orange or magenta wavelengths).

Yes, in the future subpixel font rendering for LCD display will become
a thing of the past and the RGB color model is too simplistic but for
the moment being LCD is widely used on desktop PC.

The problem is that if you use the Lite editor now, in a PC without
high dpi screen, you will probably found the text blurry.

My wish was to improve it to make it look beautiful like other editors
like sublime text, atom or other modern applications.

Kind regards
Francesco