aboutsummaryrefslogtreecommitdiffstats
path: root/libglitter.7
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--libglitter.743
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