headers
Werner LEMBERG | 4 Feb 16:29
Picon

[ft] ttfautohint: separate GUI and console binaries


Folks,

it took me a whole week of intensive documentation reading and
compilation experiments, asking on various mailing list, etc., etc.,
to eventually find out that I need two binaries on Windows, one for
the console and one for the GUI.  For consistency I've decided to
create two binaries for all platform.

Sigh.  It's simply not possible to make a Windows program behave the
same way as a POSIX one.  I haven't believed it, now I know :-| Well,
I'm an absolute beginner w.r.t. to Windows programming...

After building from the current git there is now a `ttfautohint' and
`ttfautohintGUI' binary.  It compiles nicely on Windows also; I've
successfully used MinGW (but please check the `INSTALL.git' file for
more details).  The only drawback of creating a static GUI binary on
Windows is its size: Due to the Qt libraries it's about 8MByte
(compared to 150kByte on GNU/Linux using Qt DLLs).

I invite the adventurous user to compile and test!  If everything
works fine, I'll release a new version in a few days.

   Werner
Permalink | Reply | 3 comments |
headers
Wojciech Mamrak | 4 Feb 18:03
Picon

Re: [ft] ttfautohint: separate GUI and console binaries

Hi Werner,

may I ask about reasons of using static Qt libraries on windows? Or
maybe I have misunderstood you totally?

regards

2012/2/4 Werner LEMBERG <wl <at> gnu.org>:
>
> Folks,
>
>
> it took me a whole week of intensive documentation reading and
> compilation experiments, asking on various mailing list, etc., etc.,
> to eventually find out that I need two binaries on Windows, one for
> the console and one for the GUI.  For consistency I've decided to
> create two binaries for all platform.
>
> Sigh.  It's simply not possible to make a Windows program behave the
> same way as a POSIX one.  I haven't believed it, now I know :-| Well,
> I'm an absolute beginner w.r.t. to Windows programming...
>
> After building from the current git there is now a `ttfautohint' and
> `ttfautohintGUI' binary.  It compiles nicely on Windows also; I've
> successfully used MinGW (but please check the `INSTALL.git' file for
> more details).  The only drawback of creating a static GUI binary on
> Windows is its size: Due to the Qt libraries it's about 8MByte
> (compared to 150kByte on GNU/Linux using Qt DLLs).
>
> I invite the adventurous user to compile and test!  If everything
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wojciech Mamrak | 4 Feb 20:52
Picon

Re: [ft] ttfautohint: separate GUI and console binaries

Ok, I was just curious why are you "complaining" on size of the binary
under Windows while it is possible to reduce it by choosing other
linking method.

2012/2/4 Werner LEMBERG <wl <at> gnu.org>:
>
>> may I ask about reasons of using static Qt libraries on windows?  Or
>> maybe I have misunderstood you totally?
>
> The only reason is to make the distribution of the binaries easier.
> Actually, I don't see much difference in having a smaller
> `ttfautohintGUI.exe' which must be then distributed with `qtcore4.dll'
> and `qtgui4.dll'.  Due to the lack of a standard packaging system on
> Windows, I have to always provide the Qt libraries, either statically
> linked into the application or these two DLLs.
>
> Note that there is some code which could be shared between ttfautohint
> and ttfautohintGUI: the MinGW runtime and the FreeType library.
> However, since I need FreeType 2.4.5 or newer which is not distributed
> everywhere by default (in particular I got problem reports from Macs)
> I think it's better to have them statically linked also.
>
>
>    Werner
Permalink | Reply | 0 comments |
headers
Werner LEMBERG | 5 Feb 07:56
Picon

Re: [ft] [ft-devel] The Free Type License


> Why is this a file The free type project license on my imac, in my
> user information guide?

Because Apple apparently uses FreeType in the software or operating
system which gets provided with your iMac.  The FreeType License (FTL)
says that the FreeType project must be mentioned in the software
product, and Apple has decided that it is easiest to simply add the
license file for this purpose.

    Werner
Permalink | Reply | 0 comments |
headers
Peter Grandi | 11 Feb 21:04
X-Face
Picon

[ft] changing the depth of gray for anti-aliasing

I have been for a long time rather unhappy with anti-aliasing
because of it makes text bolder and fuzzier than it should be,
at least on monitors with 100DPI or so, but I have recently
realized, as described here:

  http://www.sabi.co.uk/blog/12-two.html#120206

and in particular by this side-by-side comparison image:

  http://www.sabi.co.uk/Misc/snapFontAliasingDarkLight.png

that anti-aliased text looks very different on dark backgrounds
(thinner, not so fuzzy) than on light ones (thicker, fuzzier).
This is all without subpixel anti-aliasing (gray-level only).

My guess is that this happens because at around 100DPI most 10
point fonts render with 1-pixel wide features, and ''graying''
around that makes it look thicker, but how dark the gray is
matters a lot: if it is lighter, on light backgrounds the
apparent extra thickness will be less apparent, and viceversa on
dark backgrounds.

Therefore it would be nice to be able to control how dark is the
anti-aliased "fuzz", so it can be rather lighter than the default
on light backgrounds and a little darker on dark backgrounds.

Is there a runtime tweakable already?
Permalink | Reply | 13 comments |
headers
Werner LEMBERG | 11 Feb 21:57
Picon

Re: [ft] changing the depth of gray for anti-aliasing


> Therefore it would be nice to be able to control how dark is the
> anti-aliased "fuzz", so it can be rather lighter than the default on
> light backgrounds and a little darker on dark backgrounds.
> 
> Is there a runtime tweakable already?

No.  However, you might experiment with changing the gamma value (this
is the job of your GUI).  To bypass the desktop, checking different
gamma values directly with FreeType, use the `ftview' demo program and
control the gamma with the `g' and `v' keys.

Another possibility is to tweak FontConfig so that it uses a different
rendering mode.  Again, to bypass your desktop, try the `ftview' demo
program and cycle through the different rendering modes with the `L'
key.

    Werner
Permalink | Reply | 4 comments |
headers
Peter Grandi | 12 Feb 17:13
X-Face
Picon
Favicon

Re: [ft] changing the depth of gray for anti-aliasing

>> [ ... ]and in particular by this side-by-side comparison image:
>>  http://www.sabi.co.uk/Misc/snapFontAliasingDarkLight.png

>> that anti-aliased text looks very different on dark
>> backgrounds (thinner, not so fuzzy) than on light ones
>> (thicker, fuzzier).  [ ... ] Therefore it would be nice to be
>> able to control how dark is the anti-aliased "fuzz", [ ... ]
>> Is there a runtime tweakable already?

> No.  However, you might experiment with changing the gamma
> value (this is the job of your GUI). [ ... ]

Ahhh interesting indeed. It turns out that gamma has indeed a
profound effect. I tried by setting X gamma to 1.0 (that is,
default) and changing the monitor gamma.

At monitor gamma 2.2 which the default for most non-Mac monitors
there is indeed a very large difference between monochrome and
antialiased text, which seems to disapper around gamma 1.6-1.7
(my monitor reaches down to 1.8 so I had to use X gamma to go
down a further bit).

That is not so good because on PCs just about everything looks
rather washed out at gamma 1.8 (the Mac gamma), and even worse
at gamma 1.6-1.7.

  Note: I have a moderately high end recent h-IPS monitor with
  full 24-bit colors with really smooth and wide tone gradients.

However admittedly the light/medium/dark gamma tests in the KDE
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter Grandi | 13 Feb 01:01
X-Face
Picon

Re: [ft] changing the depth of gray for anti-aliasing

[ ... ]

>> [ ... ] However, you might experiment with changing the gamma
>> value (this is the job of your GUI). [ ... ]

> Ahhh interesting indeed. It turns out that gamma has indeed a
> profound effect.

Having seen that gamma matters I have used that as a keyword in
the archives for this mailing list and found for example these
two:

http://lists.nongnu.org/archive/html/freetype/2010-02/msg00055.html
 "An important thing is to apply gamma correction, if necessary.
  In particular, black on white needs a different gamma compared
  to white on black."

http://lists.nongnu.org/archive/html/freetype/2010-02/msg00037.html
 "As others have mentioned, you can also tweak the grayscale
  values by applying a gamma function on the bitmap. I've found
  a gamma value of 0.7 and 1.4 to be good for text rendering,
  depending on whether you're rendering black on white or white
  on black."

and it seems that it is the *application* that is supposed to
apply gamma correction, because only the application knows the
colors on which the pixmap created by Freetype2 will be applied.
Relying on monitor/X server gamma would I guess satisfy this.
There is some more discussion here:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Werner LEMBERG | 13 Feb 08:46
Picon

Re: [ft] changing the depth of gray for anti-aliasing


> However admittedly the light/medium/dark gamma tests in the KDE
> settings do look best on gamma 1.6-1.7, as in I can distinguish
> rather more dark grays than at gamma 2.2.
> 
> Which is unfortunate, because it looks like Freetype2 is set for
> the "right" gamma which nobody uses...

This is not correct.  What FreeType returns is simply the pixel
coverage of the outline.  It's really up to the OS to adjust this for
best viewing.

> '/etc/fonts/' file. First two things that seem bugs:
> 
>   * "'h' or "glyph hinting" seems to force antialiasing on
>     when "sbits cache" is active, but not with "normal cache".
>     I have thus done all tests with "normal cache".

I can't repeat this.  Please give an exact recipe how to reproduce the
effect you are observing.

>   * Sometimes the "glyph waterfall" (which I have used for all
>     testing) shows some sizes as essentially identical (e.g. for
>     Deja Vu Sans Mono 13pt and 14pt, 15pt and 16pt, and 20pt and
>     21pt are only slightly different, but same widths). This
>     happens only when (not necessarily an exhaustive list):
>       - "anti-aliasing" off, "forced auto-hinting" off.

First of all, DejaVu is not designed for B/W rendering; anti-aliasing
should always be activated.  Secondly, what you see is intended by the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Werner LEMBERG | 13 Feb 08:54
Picon

Re: [ft] changing the depth of gray for anti-aliasing


> [...] it seems that it is the *application* that is supposed to
> apply gamma correction, because only the application knows the
> colors on which the pixmap created by Freetype2 will be applied.

This is correct.  It's a tricky issue, but in most cases it should be
sufficient to handle black on white and white on black (or more
generally spoken, bright on dark or dark on bright).  No idea whether,
say, `konsole' on KDE does that.

> I found reference to an "infinality" patch that builds this into
> Freetype2,

It's planned to integrate these patches into FreeType itself.

>   The problem is TrueType hinting for small glyphs was designed
>   specifically for a regular, aliased B&W rasterizer! The use of
>   anti-aliasing of any kind is inappropriate, while most Linux
>   people do namely that.

Well, this holds for fonts which contain B/W hints, and which are
(incorrectly) rendered anti-aliased.  Today, many fonts only contain
hints for anti-aliased display, e.g. DejaVu.

    Werner
Permalink | Reply | 0 comments |

Gmane