diff options
Diffstat (limited to 'libglitter.7')
| -rw-r--r-- | libglitter.7 | 43 |
1 files changed, 30 insertions, 13 deletions
diff --git a/libglitter.7 b/libglitter.7 index 1e32967..bed8b56 100644 --- a/libglitter.7 +++ b/libglitter.7 @@ -13,7 +13,7 @@ layout or rendering configurations. .PP To use .B libglitter -you first apply hinting to the text so that +you first (optionally) apply hinting to the text so that the glyph outlines aligns with the output's pixel-grid as closely as possible. The next step is to get the output's subpixel arrangement and scaling factor, then assuming that @@ -24,6 +24,12 @@ sized according to the output's horizontal and vertical subpixel densities (rather than pixel densities as normally done with greyscale-antialiasing; some subpixels may have be counted multiple times depending on the subpixel arrangement). +At this point, depending on final result, you may (will +probably) want to use +.BR libglitter_redistribute_energy_double (3) +or +.BR libglitter_redistribute_energy_float (3) +to make the text a bit blurrier but reduce colour fringing. After this you create an uninitialised colour raster for text and the output's pixel density, and split it into one raster per colour channel using @@ -100,22 +106,24 @@ not for subpixel-antialiasing, and should even only used it if the user explicitly requests it. .PP Hinting is another important issue. For aliased text, hinting -is critical to ensure that strokes do not disable because they +is critical to ensure that strokes do not disappear because they are not wide enough, but also it is important so that a stroke's width is not doubled because it is a bit wider than a pixel or not aligned well with the pixel grid. Hinting attempts to align the font outline with the pixel grid. For greyscale-antialiased text, hinting as not as important, but it removes blurring and -dim strokes. For subpixel-antialiased text, hinting is not as -important as for aliased text, but it is more much important -that one greyscale-antialiased text. For subpixel-antialiased -text, hinting removes fringing (colours along the edge of a -stroke) and miscoloured strokes, strokes can even disappear: -for example, if the stroke only hits blue subpixels, but -should be rendered as pure red (the primary colour) on black, -there will only be black, as that is what primary red muliplied -by primary blue results in. Applications are discourage for -using subpixel-rendering on non-hinted text unless that user +dim strokes. However some people are more bothered by hinting +artefacts, so hinting should not always be applied. For +subpixel-antialiased text, hinting is not as important as for +aliased text, but it is more much important than on +greyscale-antialiased text. For subpixel-antialiased text, +hinting removes fringing (colours along the edge of a stroke) +and miscoloured strokes, strokes can even disappear: for +example, if the stroke only hits blue subpixels, but should be +rendered as pure red (the primary colour) on black, there will +only be black, as that is what primary red muliplied by primary +blue results in. Applications are discourage for using +subpixel-rendering on non-hinted text unless that user explicitly says it he wants subpixel-rendered text even it will look bad (presumably to see how it looks). Subpixel-rendering may also be a bad idea on coloured text. @@ -141,7 +149,16 @@ native colour model: as the primary colours' chromacity may differ from sRGB, it is possible that when outputing colour it is intepreted as sRGB, and converting to the output's colour model, which may change the activation level on the subpixels -as compared to how it was rendered. +as compared to how it was rendered. Applications should also +if possible attempt align strokes to the pixel-grid rather than +the subpixel grid: if you have a monitor with vertical stripes +of subpixels, and draw a white, one pixel wide vertical line +on black, it will look like a white-on-black line, but not so +if you shift the line over one pixel, suddenly it becomes two +inversely coloured lines (this does however depend on the +monitor: there are less common monitors that are actually +designed so that this doesn't happen: they use a different +pixel model). .PP Applications should be aware that the user's may use different monitors and may therefore need to render text differently |