[ft-devel] a hidden gem: the autohint warper code

[Collyer, Oliver, SI]

Werner,

This looks interesting and I'll give it a go and feedback in due course, 
however are there any plans to make it warp in the y direction? It appears to 
be x-only unless I have misread the code on my brief foray into it. Was there a 
reason for this? Also, does it operate in tandem with existing hinting 
techniques, or as an alternative? Were/are there future plans to expand upon 
this concept?

The kind of rendering I am after is one where the shape of glyphs is retained 
as much as possible; so currently I use the light hinting mode to *only hint in 
the y direction and then rely on subpixel rendering to improve things in the x 
direction. I find this the best compromise; hinting in both directions just 
distorts things too much for my liking.

In terms of whether to activate the option I would think it better to make it 
optional, for the reasons specified above - some people are likely using the 
light hinting mode specifically because it only affects things vertically, and 
this might scupper that approach.

Of course, I am commenting without having really studied in detail the affects 
of enabling this option, though I can tell from your posted comparison that the 
warped text has significantly increased the overall length of the whole 
sentence.

Cheers

Oliver

*I have noticed however that inter-character spacing can still affected under 
LIGHT hinting, is that a bug?

==

Folks,


as mentioned in a previous post, the warper code of the autofit module
has been disabled a few years ago to get a clean release; later on,
David Turner has essentially stopped working on FreeType, and the code
hasn't been activated since then.

Furtunately, the code still works out of the box.  I ask you to define
the `AF_USE_WARPER' macro in src/autofit/aftypes.h to activate warping
for FT_RENDER_MODE_LIGHT.  It greatly enhances the `crispness' of
vertical stems; the attached images (using DejaVuSans.ttf) demonstrate
the difference.

Please comment.  I wonder whether this shall be activated again.


Werner


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

Re: [ft-devel] a hidden gem: the autohint warper code

[Collyer, Oliver, SI]

On 28 Feb 2011, at 23:10, Werner LEMBERG wrote:

> 
>> however are there any plans to make it warp in the y direction?
> 
> No.  By its very nature, such warping can't happen in the `main'
> hinting direction $(Q#| you would get uneven glyph heights if you do so.

Could it not do something like pick a selection of key letters and work out how 
best to vertically warp these, using the scoring system, and then apply the 
same warp consistently across all glyphs?

Similarly to how I assume regular hinting must work, at least in the sense that 
it must do the same thing to an F and an H with regards to snapping the middle 
horizontal bar.

Ignore me if I'm talking horseshit though :)

>> In terms of whether to activate the option I would think it better
>> to make it optional, for the reasons specified above - some people
>> are likely using the light hinting mode specifically because it only
>> affects things vertically, and this might scupper that approach.
> 
> Currently it's a compile-time option, cf. AF_CONFIG_OPTION_USE_WARPER.
> 

Personally, I think as many options like this should be runtime-configurable as 
possible, so that there is maximum flexibility for applications in choosing how 
they want things to render rather than enforce a particular style of 
rendering/hinting across the board that requires a recompile to be changed.

With that in mind, how about some more anti-aliasing options - it would be 
great to be able to emulate what Photoshop does with the 
*clear/sharp/strong/crisp selection 
(http://www.zeta.net/web-design/photoshop-anti-aliasing-for-web-design.html for 
examples) . as a games developer, the main complaint we have from the art 
team is "why can't we render fonts like our photoshop mock-ups?"

Anyway, off at a tangent, sorry...

Oliver.

*that said, those four modes might be achievable via applying a filter to the 
existing greyscale/LCD coverage values anyway...


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

Re: [ft-devel] a hidden gem: the autohint warper code

[Collyer, Oliver, SI]

On 1 Mar 2011, at 09:19, "Werner LEMBERG" mailto:w...@gnu.org>> 
wrote:


No.  By its very nature, such warping can't happen in the `main'
hinting direction $(Q#|(B you would get uneven glyph heights if you do
so.

Could it not do something like pick a selection of key letters and
work out how best to vertically warp these, using the scoring
system, and then apply the same warp consistently across all glyphs?

Similarly to how I assume regular hinting must work, at least in the
sense that it must do the same thing to an F and an H with regards
to snapping the middle horizontal bar.

Well, the code is already doing this!  This is exactly how the
autohinter works.


Yeah, what I meant is make the warper work vertically by warping a few sample 
glyphs to find the optimum warp and then apply to all glyphs.


Currently it's a compile-time option, cf. AF_CONFIG_OPTION_USE_WARPER.

Personally, I think as many options like this should be
runtime-configurable as possible, so that there is maximum
flexibility for applications in choosing how they want things to
render rather than enforce a particular style of rendering/hinting
across the board that requires a recompile to be changed.

OK.  Stay tuned.

With that in mind, how about some more anti-aliasing options - it
would be great to be able to emulate what Photoshop does with the
*clear/sharp/strong/crisp selection
(http://www.zeta.net/web-design/photoshop-anti-aliasing-for-web-design.html
for examples)

*that said, those four modes might be achievable via applying a
*filter to the existing greyscale/LCD coverage values anyway...

Well, within ftview, you can adjust the filter weights of the LCD
filters, and you can adjust the gamma values also.  Have you ever
tried this?  If you like to add more toys to ftview: patches are
highly welcomed.


Yeah I've tried all manner of gamma settings and LCD filters. Always end up 
back at the default LCD filter though, it's pretty solid.

I do have some WIP for an algorithm that *intensifies typefaces in the manner 
of OS X which I'll happily supply as a patch if and when I'm 100% happy with 
it. It basically distorts the post-filtered LCD (or grayscale) values by 
boosting the effects of lower values in a smooth manner (tends things toward a 
curve)

*aims to replicate the bolder/fuller effect of a) larger text and b) light text 
on dark backgrounds.


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

Re: [ft-devel] a hidden gem: the autohint warper code

[Collyer, Oliver, SI]

Werner,

I'll have to get back to you on that one, it was a little while ago.

I seem to recall that it was entire words that were shifting more than letters, 
so maybe it was something related to white space characters, but I'll try and 
reproduce it and give you more information.

Cheers

Oliver.

On 2 Mar 2011, at 09:47, Werner LEMBERG wrote:

> 
>>> *I have noticed however that inter-character spacing can still
>>> *affected under LIGHT hinting, is that a bug?
>> 
>> Good question.  I don't know yet, but I'm studying the code right
>> now and I probably can answer this soon.
> 
> I've just played a bit with ftdiff: Activating the light hinter
> (by pressing `h') and comparing with the unhinted outlines, I don't
> see such an effect.  Could you please give more details?
> 
> 
>Werner


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

[ft-devel] Hinting glitch?

[Collyer, Oliver, SI]

I'm just wondering if I have found a bug in FreeType's TrueType hinting 
implementation.

Attached is how the font "NanumGothic.ttf" (downloadable from here : 
http://hangeul.naver.com/download.nhn scroll down to the 7 green boxes and it's 
the third one along the top row) looks:

@ Pixel Size 13

[cid:C2DDDF1F-E850-4D87-B865-45318241A5C1]

Notice how the letter i appears to be too tall in relation to the other letters.

@ Pixel Size 14

Now the i looks ok:

[cid:FD1C366E-B3AA-4D86-ADF4-BCEEB6D2BC19]

When hinted with the FT hinter, the letter i remains consistent.

This is with FreeType 2.4.4, with the BCI switched on as is the default.

- Oliver
<><>___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Correct way to calculate line gap/external leading

[Collyer, Oliver, SI]

>> 64 looks wrong... surely /64 or >>6 assuming those are in 26.6.

Sent from my iPigeon

On 13 Apr 2011, at 05:44, "Jjgod Jiang"  wrote:

> Hi,
> 
> I can't find in FreeType's docs on how to calculate the line gap,
> currently we are using:
> 
>FT_Size_Metrics metrics = face->size->metrics;
>leading = (metrics.height - metrics.ascender + metrics.descender) >> 64;
> 
> but sometimes I get -1 as the leading (Lucida Grande from Mac OS X, Ubuntu
> fonts, Inconsolata, DejaVu Sans). Is it fine to have negative leading? or
> is there anything wrong with my code? Thanks.
> 
> Attached my code to test.
> 
> - Jiang
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/freetype-devel

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

Re: [ft-devel] Hinting glitch?

[Collyer, Oliver, SI]

Thankyou Werner.

I just quickly loaded it up in Notepad under Windows 7 ClearType and it showed 
the same glitch so I guess it must be a bug in the hints for the font or 
something...

Sent from my iPigeon

On 19 Apr 2011, at 13:37, "Werner LEMBERG"  wrote:

> 
>> Attached is how the font "NanumGothic.ttf" (downloadable from here :
>> http://hangeul.naver.com/download.nhn scroll down to the 7 green
>> boxes and it's the third one along the top row) looks:
>> 
>> @ Pixel Size 13
>> 
>> [cid:C2DDDF1F-E850-4D87-B865-45318241A5C1]
>> 
>> Notice how the letter i appears to be too tall in relation to the
>> other letters.
>> 
>> @ Pixel Size 14
>> 
>> Now the i looks ok:
>> 
>> [cid:FD1C366E-B3AA-4D86-ADF4-BCEEB6D2BC19]
>> 
>> When hinted with the FT hinter, the letter i remains consistent.
> 
> I can confirm this observation, however, I don't see any problem with
> the FreeType code, and debugging doesn't show a problem either: There
> is no border case which could cause a rounding to a different vertical
> value.
> 
> It would be interesting to see what Windows does, testing with both
> ClearType switched on and off.
> 
> 
>   Werner


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

Re: [ft-devel] FreeType patches to support amalgamation

[Collyer, Oliver, SI]

Unless I've misunderstood, It seems to me that the changes being made are not 
to amalgamate FreeType into a couple of files, but just to rename some 
stuff/change some #defines to make this possible for another tool to optionally 
do.

If so, I really can't see what the problem is and why you're being offensive on 
the mailing list - it just makes FreeType usable in a different way for those 
who would like it, doesn't it?

As for your earlier comment:

"You will make people who borrow from FreeType miserable and make
them curse at you for renaming stuff for no good reason whatsoever."

I can't speak for anyone else, but FreeType has been a fantastic and 
much-appreciated library over the years for us and we have total respect for 
the people who have put so much time into creating it, so if a bunch of stuff 
gets renamed that makes it easier to use for others to benefit from then it's 
fine with us.

On 21 Feb 2012, at 17:12, Alexei Podtelezhnikov wrote:

> How about a shared header file if those modules share a structure?
> Don't you see that this patch set is just a pile of pure stinking crap???
> 
> On Tue, Feb 21, 2012 at 9:56 AM, Vinnie  wrote:
>> Werner:
>> 
>> 2012-02-20  Vinnie Falco 
>> 
>> 
>>   ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, 
>> TRaster
>> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel


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

Re: [ft-devel] Seams with disjoint composite

[Collyer, Oliver, SI]

What's wrong with that?

Stick it on a canvas, call it modern art and you'll make a fortune.

Sent from my iPigeon

On 7 Jun 2012, at 23:10, "Behdad Esfahbod"  wrote:

> On 06/07/2012 03:28 PM, Werner LEMBERG wrote:
>> 
>>> BTW, checkout DejaVuSans at 4pt.  I see all kinds of triangular
>>> artifacts.
>> 
>> Not my problem :-) According to the font's gasp table, hinting should
>> be switched off below 9pt.
> 
> See attachment.
> 
> behdad
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel


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