Re: [ft-devel] gamma correction and FreeType

2013-11-09 Thread another gol
But I don't agree that a monitor's white = a bright lamp ( it's fortunate for our eyes that it isn't). In order to emulate a bright lamp, or generally the sun in videogames, you add a halo, that will make the white so saturated that it will bleed around it. And this is what will make a dark thin

Re: [ft-devel] gamma correction and FreeType

2013-11-08 Thread another gol
. Smoother curves and diagonals is another goal, as is cancellation of color in subpixel rendering. I believe that there is a single gamma function that will do all of these at the same time, because it is primarily a physics problem. Thanks. -Dave On 11/7/2013 10:29 AM, another gol wrote

Re: [ft-devel] gamma correction and FreeType

2013-11-08 Thread another gol
in subpixel rendering. I believe that there is a single gamma function that will do all of these at the same time, because it is primarily a physics problem. Thanks. -Dave On 11/7/2013 10:29 AM, another gol wrote: Still, IMHO gamma correction shouldn't be about the look, but the -weight-. I

Re: [ft-devel] gamma correction and FreeType

2013-11-01 Thread another gol
True that converting to/from linear is usually done using lookup tables. Even though I try to avoid lookup tables these days, the problem is that most API/tools out there work on 8bit RGB(A). Usually you convert 8bit to 16bit, work on that, then 16bit back to 8bit. But for this to be lossless, the

Re: [ft-devel] gamma correction and FreeType

2013-10-31 Thread another gol
He must be talking about the old greyscale antialiasing in the GDI. That one is better forgotten, it sucked for many reasons, Cleartype wasn't that much better because of RGB sub-pixelling, but mainly because it was a much better antialiaser ( yet not amazing) than the poor old one. Cleartype is

Re: [ft-devel] [08/08] gamma correction issues with FreeType

2013-10-29 Thread another gol
No, I'm not talking about a whole pixel line spread over 2 pixels, I'm talking about dimmed fonts due to the fact that a stem is smaller than a pixel in width. It's not a technical problem at all, it just seems to be how most popular fonts are designed, stems a little thinner than a pixel at

Re: [ft-devel] points under baseline shifted up

2013-10-21 Thread another gol
the baseline looks shifted up by the same amount. ) On Tue, Oct 22, 2013 at 1:36 AM, another gol another...@gmail.com wrote: Hi, I'm seeing something weird in the ouline given out by freetype (2.5), when hinting is disabled (or set to the TTF's own there's none), the geometry below

[ft-devel] points under baseline shifted up

2013-10-21 Thread another gol
Hi, I'm seeing something weird in the ouline given out by freetype (2.5), when hinting is disabled (or set to the TTF's own there's none), the geometry below the baseline seems to be shifted up by a tiny fraction. My test is a font of 2048 units/EM, used at height 16, so that 128 units=1 pixel

[ft-devel] X-Height CapHeight

2013-08-21 Thread another gol
Hi, Would be nice to have x-height capheight published (I know I'm not the first one to ask). I fully understand that they're only available in a truetype chunk, but when the info is there, it beats having to guess it. Both are quite important for balanced text vertical centering. How does

[ft-devel] hinting halftoning

2013-08-16 Thread another gol
Hello, I'm using Freetype along with a custom rasterizer (based on Antigrain's) in my app. I have a few questions as well as some thoughts I'd like to share. 1. my rasterizer doesn't use horizontal hinting at all, only vertical. Again, this was proved to work well in Antigrain's test