Lite text editor

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Lite text editor

Petri Häkkinen
Check out this amazing open-source text editor:

It’s written in Lua and it’s very easily extendable. Its architecture is elegant and minimalistic, qualities it shares with Lua.

Petri
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Felipe Tavares

Em sáb., 30 de mai. de 2020 às 19:20, Petri Häkkinen <[hidden email]> escreveu:
Check out this amazing open-source text editor:

It’s written in Lua and it’s very easily extendable. Its architecture is elegant and minimalistic, qualities it shares with Lua.

Petri


--
--
Felipe Tavares
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Philippe Verdy-2
In reply to this post by Petri Häkkinen

Le dim. 31 mai 2020 à 00:20, Petri Häkkinen <[hidden email]> a écrit :
Check out this amazing open-source text editor:

It’s written in Lua and it’s very easily extendable. Its architecture is elegant and minimalistic, qualities it shares with Lua.

Thanks, an interesting alternative to Notepad++ for non-Windows users.

I still prefer Notepad++ in Windows, which already features many plugins, plus a full-powered Lua 5.3 plugin, with binding to the Scintilla API to control almost all aspects of the editor, that also supports more extended regular expressions (notably ECMAScript regexp, but still not those in PCRE or Perl style). Only one bad thing about Notepad++ is that it has only two editor panels presetned side by side, instead of generic tabs.)
and Notepad++ can load very large files that RxiLite cannot. Its Scintilla API is also much very fast for complex operations and for syntax coloring, and scrolling of long texts.

(In the past, Notepad++ was not very safe and the undo-history could be corrupted by large search-replace operations: this seems to have been fixed when Notepad++ abandonned the basic Microsoft Rich-text component for the new Scintilla widget, which handles buffers and styling/coloring much more safely and much faster for loading buffers).

Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Albert Krewinkel
In reply to this post by Petri Häkkinen
This looks really nice, thank you for sharing!

Out of curiosity: lite is currently built with Lua 5.2.4. Is this a
historical thing, or are there specific reasons for choosing that
version?

Cheers,
Albert

Petri Häkkinen writes:

> Check out this amazing open-source text editor:
> https://github.com/rxi/lite
>
> It’s written in Lua and it’s very easily extendable. Its architecture is elegant and minimalistic, qualities it shares with Lua.
>
> Petri


--
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Enrico Colombini
In reply to this post by Philippe Verdy-2
On 31-May-20 00:44, Philippe Verdy wrote:
> Only one bad thing about Notepad++ is that it has only two editor panels
> presetned side by side, instead of generic tabs.

Are you sure you are talking about Notepad++? I routinely keep lots of
tabs opened in it.
(under Linux I use SciTE which is basically the same thing, except than
some of the settings can only be changed by manually editing the
configuration files)

--
   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Petri Häkkinen
In reply to this post by Albert Krewinkel

> On 31. May 2020, at 9.48, Albert Krewinkel <[hidden email]> wrote:
>
> Out of curiosity: lite is currently built with Lua 5.2.4. Is this a
> historical thing, or are there specific reasons for choosing that
> version?

The author mentioned that he wants to keep it compatible with LuaJIT.

Petri

Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Philippe Verdy-2
In reply to this post by Enrico Colombini
I'm really speaking about Notepad++: it has multiple "tabs", but only two can be visible (side by side: an editor 1 on the left, and an editor2 on the right).
The "tabs" are just buttons to select which text will go into one of the two possible editors (these two views may show different position in the same single document).
There's still no way to have 3 or 4 tabs simultaneously, either side by side, or below each other (which should be the prefered presentation for "tabs" open on the same document).




Le dim. 31 mai 2020 à 11:25, Enrico Colombini <[hidden email]> a écrit :
On 31-May-20 00:44, Philippe Verdy wrote:
> Only one bad thing about Notepad++ is that it has only two editor panels
> presetned side by side, instead of generic tabs.

Are you sure you are talking about Notepad++? I routinely keep lots of
tabs opened in it.
(under Linux I use SciTE which is basically the same thing, except than
some of the settings can only be changed by manually editing the
configuration files)

--
   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Philippe Verdy-2
Le dim. 31 mai 2020 à 11:25, Enrico Colombini <[hidden email]> a écrit :
Are you sure you are talking about Notepad++? I routinely keep lots of
tabs opened in it.
 
The alternative in Notepad++ is to allow it to run multiple instances in separate windows, but then you cannot "clone" the same open document in two views, one below each other: each window will open a separate document copy, edited independently, and you loose vertical space  on screen because of title mars, menus, button bars, tabs at top, and status bar at the bottom (plus docked consoles like the Lua console in each window). This alternative is only for working on separate files.

The UI of Notepad++ is also aging, with its old fashioned look and feel, and the light color-model only. the newer look and feel of "Howl" is much better (even if it does not still have all the features of Notepad++ and its many plugins).

Notepad++ still does not allow "undocking" a view into a separate window (with its own menu/toolbars/status bar that could be placed more freely), while keeping the same edited documents "cloned".

May be Notepad++ is working on a freshened UI, that would allow docking/undocking editor view more freely, in the same window or separate windows (so instead of just "editor1" and "editor2" views, you could have any number of editors (named "editor3", "editor4"... for compatiblity, or in an indexed array "editors[n]" or "views[n]", as seen in the Lua API for "npp"), would avoid duplicating the list of tab buttons above each view, and would completely remove the need to run several instances in separate windows, and a new model of its look and feel (notably a dark theme, a refined design for its buttons, menus, toolbars, scrollbars, and  slidable view separators, including for accessiblity purpose on tactile screens...) I'm not criticising Scintilla which is very good, and plugins. But even the design of menus is not very good: menus are overpopulated, thay have no smart intelligence to adapt to the current context of use, and its preferences panels are quite complex to navigate, nad have poor/inacessible UI designs for its lists...

But for now Notepad++ is still the best on Windows for editing large files (forget Notepad) and its still relatively frienfly for user and offers exceelent performance (including fast startup) Its software updates or the way you can install/remove plugins is still old-aged (you need to restart the editor, Notepad++ has autosaved files in temporary files, but the state of existing plugins is lost; that's probably something that Howl could avoid by dynamically opening and closuing plugins on demand, thanks to its Lua implementation).

Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Enrico Colombini
In reply to this post by Philippe Verdy-2
On 31-May-20 14:39, Philippe Verdy wrote:
> I'm really speaking about Notepad++: it has multiple "tabs", but only
> two can be visible (side by side: an editor 1 on the left, and an
> editor2 on the right).
> The "tabs" are just buttons to select which text will go into one of the
> two possible editors (these two views may show different position in the
> same single document).
> There's still no way to have 3 or 4 tabs simultaneously, either side by
> side, or below each other (which should be the prefered presentation for
> "tabs" open on the same document).

Ah, OK, I misunderstood your posting. I am a minimalist and I prefer a
single editing pane, though :-)

--
   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Philippe Verdy-2
Le dim. 31 mai 2020 à 16:10, Enrico Colombini <[hidden email]> a écrit :
Ah, OK, I misunderstood your posting. I am a minimalist and I prefer a
single editing pane, though :-)
 
Having two views of the same document is practical: it avoids constant navigation in the text for looking at related sections of code

You could have a small part showing a list of declarations, and the rest showing long implementations.

For editing data it allows seeing which elements are already defined (example table values) before referencing them in a lower part
For editing code, it allows checking places where a set of variables receives values, or a comment where there are specifications, before writing the code using it.
You don't forget something, you can see all in one place.

You can refactor some code or data more easily (it's easier to make cut-and-paste between the two views).

This is also needed in other applications (like spreadsheets to see the column heading at top, while navigating/scrolling the rows below): large data tables are easier to read or edit without mixing the columns.

So I frequently use the two views of the same document.

Note that even if Notepad++ also has a "line grouping" feature, which allows easier editing of large tables, editing some long flat lists will still require scrolling down, so it's not evident to see the top of the group and return to where we were (even if you can put a "blue buccle" mark on some lines and use a keyboard shortcut to return to the previous/next mark: remembering line numbers is less easy as it will vary for the bottom mark when you edit the top part)

The bad thing is that the two views in N++ are only presented side by side, not on top of each other. So for editing tables with many columns, it's not so easy.
Instead, what I do is to paste some "template" line as comments to repeat some parts of the top. Once the edit is done, and tested, I can remove these comment lines (and thanks, in Lua syntax, the comments may be multiline blocks if needed, without having to change the "helper" template code they embed)




Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Philippe Verdy-2
In reply to this post by Enrico Colombini
Le dim. 31 mai 2020 à 16:10, Enrico Colombini <[hidden email]> a écrit :
Ah, OK, I misunderstood your posting. I am a minimalist and I prefer a
single editing pane, though :-)

So I assume that, as a user of the "single view" editing mode, you just trust your "immediate memory" when navigating inside an edited document.
I prefer not trusting my immediate memory (or instinct), and being able to compare things visually all at once on the same screen.
We've all frequently found nasty bugs that were caused by mismatched contents that were edited separately (such as forgetting a repeated item in an horizontal list)...


 
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Enrico Colombini
On 31-May-20 22:04, Philippe Verdy wrote:
> So I assume that, as a user of the "single view" editing mode, you
> just trust your "immediate memory" when navigating inside an edited
> document.

I use markers (and ad-hoc comments, when needed).

> I prefer not trusting my immediate memory (or instinct), and being able
> to compare things visually all at once on the same screen.
> We've all frequently found nasty bugs that were caused by mismatched
> contents that were edited separately (such as forgetting a repeated item
> in an horizontal list)...

To each one their way of working :-)

--
   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Francesco Abbate
In reply to this post by Petri Häkkinen
Le dim. 31 mai 2020 à 00:21, Petri Häkkinen <[hidden email]> a écrit :
Check out this amazing open-source text editor:

It’s written in Lua and it’s very easily extendable. Its architecture is elegant and minimalistic, qualities it shares with Lua.

Hi,

I think the Lite editor is a really great piece of software. It is small, light on resources and yet the graphism is beautiful and it runs smoothly. I also appreciate the Lua integration and all the power it brings.

The only aspect that seemed subpar to me was the font rendering. To improve this aspect I have been working on the Lite editor to add support for subpixel font rendering. I am now quite satisfied with the result but for the moment I didn't ask to merge my code into the main project.

The code is available in a branch of my fork of the Lite editor:


and can be compiled using Meson. It requires the SDL2 library plus libagg and the freetype library.

I have prepared some pre-compiled binary packages for linux and windows


I personally think that the subpixel font rendering is much better and it is close to Sublime Text but I would like to have some feedback.

Kind regards
Francesco
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Petri Häkkinen

> On 9. Jun 2020, at 13.21, Francesco Abbate <[hidden email]> wrote:
>
> The only aspect that seemed subpar to me was the font rendering. To improve this aspect I have been working on the Lite editor to add support for subpixel font rendering. I am now quite satisfied with the result but for the moment I didn't ask to merge my code into the main project.

Very interesting! Do you happen to have before & after screenshots somewhere?

However, I doubt this gets accepted to the main repo because it brings so many new dependencies, but definitely worth a try! In any case a fork is always a good option.

Petri
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Francesco Abbate
> Very interesting! Do you happen to have before & after screenshots somewhere?

Thank you for asking. It is a good idea so here there are some
screenshots to compare with and without subpixel font rendering.

https://github.com/rxi/lite/issues/145#issuecomment-641554095

Actually I have introduced not only subpixel but also "slight hinting"
i.e. hinting only in the y axis and gamma correction.

> However, I doubt this gets accepted to the main repo because it brings so many new dependencies, but definitely worth a try! In any case a fork is always a good option.

Agree, the Lite's author is very inclined on minimalism so he may not
accept the complexity brought by the AGG library with C++ and the
additional dependencies (AGG library and Freetype2). IMHO the result
is worth the additional complexity but other people may have a
different advice.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Philippe Verdy-2
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.
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).

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!

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).



Le mar. 9 juin 2020 à 22:43, Francesco Abbate <[hidden email]> a écrit :
> Very interesting! Do you happen to have before & after screenshots somewhere?

Thank you for asking. It is a good idea so here there are some
screenshots to compare with and without subpixel font rendering.

https://github.com/rxi/lite/issues/145#issuecomment-641554095

Actually I have introduced not only subpixel but also "slight hinting"
i.e. hinting only in the y axis and gamma correction.

> However, I doubt this gets accepted to the main repo because it brings so many new dependencies, but definitely worth a try! In any case a fork is always a good option.

Agree, the Lite's author is very inclined on minimalism so he may not
accept the complexity brought by the AGG library with C++ and the
additional dependencies (AGG library and Freetype2). IMHO the result
is worth the additional complexity but other people may have a
different advice.

Francesco
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Francesco Abbate
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Philippe Verdy-2
I don't think that subpixel rendering will a a "'thing of the past". Instead, the display drivers will provide accurate info about the subpixel geometry, the exact color model of their chromatic elements (wavelength emission  distribution), their respective effective gamma curve, their relative contribution to white lightness, their real geometry (this could be a set of matrix, like a calibrated bitmap showing their actual form, at a resolution higher than the subpixels themselves, i.e. sub-subpixels), and a set of convolution matrix showing the diffusion level into surrounding sub-sub-pixels.

This will many computing images with an even better subpixel resolution to avoid undesired artefacts that are still visible with simple full-square pixel geometry using the "uniform" color model for all their surface (notably the wellknown undesired "Moiré" effect created by full pixel grids, which is even worse than the "stairs" effect rendered by non-smoothed renderings. To work, these displays will require more powerful graphics cards, because they'll need to work on much larger framebuffers for intermediate computing before applying the gamma-correction, and the Gaussian averaging for the final image. To take into account subpixel geometries, you need to multiply the resolution by at least 4 in each dimension, so this requires 16-times larger framebuffers, and a graphics card capable of computing 16-times larger matrixes, possibly increased by the additional colorplanes (for now only 3, sometimes 4 with the alpha channel which is used for something else than color, used instead for compositing multiple objects on top of each other).

But before this happens, the 24-bit color depth (3 times 8-bit) with sRGB will be deprecated in favor of 32-bit (10+11+11) or 48-bit (3 times 16 bit), or 32-bit with 4 components (RGB+yellow or RGB+white, 8-bit each), or 64-bit (same as 48-bit but with a 4th component).

The "exact" subpixel geometry however is already used internally on costly large TV panels to greatly enhance the color gamut (by computing an additional color plane) and efficiently hide the undesired moiré and visible scales of large pixels on large screens, in their internal renderers (the effect is visible in very dark areas, or very light areas, where you can even clearly see the smooth shadows, notably on people's faces, that most of the cheap TV panels render with a "flattened" aspect with low 3D depth)

For text display however, subpixel geometry plays little role (except on desktop panels between 15 and 30 inches of diagonal), and Hi-DPI displays (used for now only on mobile devices with size much smaller than 15 inches) will solve molve most problems, even with just a basic 3-component RGB subpixels aligned equally on the same row.


Le mer. 10 juin 2020 à 07:52, Francesco Abbate <[hidden email]> a écrit :
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Lite text editor

Philippe Verdy-2
In reply to this post by Francesco Abbate
Also note that the sRGB color model is not tuned to model the human vision: it is based on the most common chromatic components of LCD panels used today. But their chromatic components (based on the chemical compound used, according to the narrow bandwidth of their wavelength of **emission**) are not centered correctly on the larger bandwidth wavelengths of **absorbtion** of human cones. That's why the perception of colors on these screens vary a lot between people (falsely accused to have "color vision defects").

If there's a defect, it's caused by the rendering technology for displays whose color gamut is too much restricted (something that editors of printed documents, already know since long, as they use many more color components than just 3): digital photography has not been a progress, argentic photography using many more chromatic components than just 3 were (and still are) much more accurate in terms of color gamut (let's not speak about use of colors in art: there are hundreds of distinct color components, not just 3 in the sRGB approximation) and most printers prefer the CMYK color model exactly for the same reason (also because of other effects like mutual aborbtions when inks drop are fused together or superposed, even if technologies of inks has also progressed, with much thinner grains, but with a limitation caused by diffusion on the surface of paper where droplets of inks will fuse together)

For now there does not exist any LCD panel using chromatic subpixels correctly centered on biological pigments present in human eyes (there has been some attempts, but the chemical compounds are unstable and don't have the stability found in animal cells; some researches are still in progress, using biotechnologies; the most significant progress has been those made in Korea by Samsung for its panels and notably with OLED based on **organic** chemical compounds that can better approximate the natural color pigments of human eyes),