Re: [ft-devel] Announcing FreeType 2.6.2

[Nikolaus Waxweiler]

2nd revision of my post. Reorganized headings and tried to better 
explain the blending examples.
diff --git a/index.html b/index.html
index c92d541..e4493a0 100644
--- a/index.html
+++ b/index.html
@@ -106,71 +106,9 @@
 
   FreeType 2.6.2 ships with three interesting details for
 users and developers of rendering libraries that deal with
-text.
-
-
-  The default LCD filter for subpixel rendering has been
-changed
-
-  
-
-
-  When you look at subpixel-rendered text, no matter
-whether it is on some kind of Unix, Windows, or Mac
-OSX, you might notice that it is slightly colored.
-Using subpixel rendering on LCD panels is a trade-off; you
-get three times higher resolution in the direction of the
-pixel-substripe (usually horizontal RGB) in exchange for
-color artifacts, also called color fringing.  For
-this reason it is necessary to filter a subpixel-rendered
-glyph to reduce those color-fringing before putting it
-somewhere on the screen.  The filter distributes the
-values of a subpixel to its neighbors, sacrificing some of
-the higher resolution and making the resulting glyph image
-blurrier – but the positioning improvement remains!  The
-ideal filter for you depends on your screen (gamma
-curves!), the capabilities of the used rendering system
-(linear alpha blending and gamma correction!), your vision
-and your taste, probably in that order.
-
-  A filter should have two properties: it should be
-normalized, meaning the values used in the filter should
-sum up to a figurative1 (here: 0x100 or 256) and it
-should be color-balanced, meaning that values for one
-subpixel are equally distributed to all other subpixels of
-a pixel to sacrifice some of the higher resolution to
-drastically reduce color-fringes.
-
-  Previously, FreeType's default LCD filter was neither
-normalized nor color-balanced.  That was a deliberate
-choice because there is still no rendering system on
-*nixes that does linear alpha blending and gamma
-correction by default to render glyphs correctly.  Going
-above a filter sum of1 increased contrast somewhat
-at the expense of slight distortions and increased
-color-fringing, so this can be seen as a hack.  You might
-have noticed that thumbnails in various places on your
-computer that show text could be quite colorful.  Now you
-know why.
-
-  The new default filter is both normalized and
-color-balanced.  It is indeed ever so slightly blurrier
-than the previous default one, but also lacks its
-harshness and is less color-happy.  The blurriness also
-means higher tolerance for non-ideal gamma of screens
-(viewing angles!) and rendering systems without linear
-alpha blending.  Note that color-fringing can only be
-really minimized when the rendering system will do linear
-alpha blending of text.
-
-  The light filter that has accompanied the
-default one for so long stays unchanged: it already is
-normalized and color-balanced.  It is sharper than the
-default one but less tolerant of uncalibrated screens and
-rendering systems without linear alpha blending, producing
-more color-fringes.
-
+text. This is the 2nd revision of my post, done on 2015-12-06.
+I reorganized the headings and tried to better explain the blending
+  examples.
 
   (S)light hinting will invoke the native hinter if possible
 
@@ -243,8 +181,7 @@
 one, as Ubuntu has proven over the years.
 
 
-  Stem darkening for the auto-hinter (disabled by default), also
-disabling stem darkening for the OpenType/CFF driver
+  Experimental: Stem darkening for the auto-hinter
 
   
 
 
   This is relevant because all our screens have a second
-problem: they are not linear.  1+1 is
+problem: they are not linear.  1+1 is
 not2.  Twice the value does not result in twice the
 brightness.  When a pixel is only 50% covered, the
 coverage map says 50% black, and this translates to a
@@ -332,13 +269,6 @@
 with http://lists.nongnu.org/archive/html/freetype-devel/2015-11/msg00020.html;>as
 little color-fringing as possible.
 
-  
-
-
-  We want to get to Gamma 1.8, darkened.
-Note how it is the cleanest rendering of all.
-
   Back to stem darkening.
 
 

Re: [ft-devel] Announcing FreeType 2.6.2

[Nikolaus Waxweiler]

Would you be willing to host the site on Github Pages?

http://pages.github.com


Is this addressed to Werner? I personally would vote in favor of moving 
the FreeType site and main code repository to GitHub, simply because 
it's the most popular service with the largest user base and has nice 
things for running a project. I think this can make it easier for people 
to contribute to FreeType.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Announcing FreeType 2.6.2

[Dave Crossland]

On 6 December 2015 at 22:42, Nikolaus Waxweiler  wrote:

> Would you be willing to host the site on Github Pages?
>>
>> http://pages.github.com
>>
>
> Is this addressed to Werner?


Yes


> I personally would vote in favor of moving the FreeType site and main code
> repository to GitHub, simply because it's the most popular service with the
> largest user base and has nice things for running a project. I think this
> can make it easier for people to contribute to FreeType.
>

I agree :)



-- 
Cheers
Dave
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] typos in the documentation

[Nikolaus Waxweiler]

If the entire text could be made available in a formatted and readable
form, I would be happy to proof-read it for typos, grammar and correct
English.


Gladly! Love must be spread correctly (old German sentiment). Thanks :)


freetype-262-blog.odt
Description: application/vnd.oasis.opendocument.text
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Announcing FreeType 2.6.2

[Dave Crossland]

On 1 December 2015 at 04:07, Werner LEMBERG  wrote:

> Basically, I don't object.


Would you be willing to host the site on Github Pages?

http://pages.github.com
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] typos in the documentation

[Graham Asher]

On 06/12/2015 15:19, Nikolaus Waxweiler wrote:

The autohinter has a new toggable stem darkening property

A couple of typos:

"The autohinter has a new toggable stem darkening property": The word 
'toggable' doesn't exist. I think you mean 'toggleable' (although that 
is not the happiest of coinages).


"to reduce those color-fringing": should be "to reduce those color fringes".

Oh, I just noticed something else:

"the capabilities of the used rendering system" should be "the 
capabilities of the rendering system"; the word 'used' is redundant and 
a 'used rendering system' is a second-hand one.


If the entire text could be made available in a formatted and readable 
form, I would be happy to proof-read it for typos, grammar and correct 
English.


Best regards,

Graham

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] State of TrueType interpreter v38 and up?

[Nikolaus Waxweiler]

It must

   (a) ignore changes of the horizontal advance widths due to
   hinting instructions (not implemented yet), and

   (b) ensure that all instructions behave correctly even if the
   horizontal resolution is increased (this is ClearType
   compatibility mode, already implemented).


Ah, okay :) is (a) so complicated or is it that simply nobody did the 
work yet? And regarding your other post dealing with DWRITE equivalents, 
I think FT then with the above only ever does 
DWRITE_RENDERING_MODE_NATURAL_SYMMETRIC, which is probably what we want 
for light mode.



No. This is what *effectively* happens, due to the strongly
increased horizontal resolution. However, at least in `native' mode,
you can still enforce non-integer positions along the x axis.



Such a mode doesn't exist in the MS engine. However, Adobe's
modified TT engine essentially hints only along the y axis, if I've
understood Dave Arnold correctly, replacing x axis hints with
emboldening.


How complicated. So I guess ClearType
- without stem darkening: let font modify x-coordinates at will but 
ignore modifications to advance width
- with stem-darkening: nop everything that deals with x-coordinates and 
embolden just the x-axis? Dave?
The latter would make backwards compatibility irrelevant because we 
would only honor Y-hints anyway, right?



... the MS approach is superior IMHO.  It

   (a) elegantly circumvents many problems due to the extreme
   difference between horizontal and vertical resolution – it
   basically makes the compatibillity mode redundant, and

   (b) the increased resolution is around 10 times in both horizontal
   and vertical direction, compared to a threefold horizontal
   resolution increase of FreeType.


Hm. Something for a hypothetical FreeType 3 :) ClearType patents should 
have run out by then ;)


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel