Re: [Devel] QA: latest FT2 snapshot & Serif fonts

[Vadim Plessky]

Hi David,

On Sunday 23 March 2003 02:04, David Chester wrote:
|  Hello,
|
|  --- Vadim Plessky wrote:
|  > I should tell you here that quality of rendering of non-hinted font (TTF
|  > with autohinter, no bytecode interpreter compiled) improved
|  > significantly over FreeType 2.1.3.  And it seems that it was at expense
|  > of PS hinter/AA renderer.
|
|  It doesn't look like the changes in the ps hinter had anything to do with
| the changes in the autohinter.
|
|  > Times New Roman (TNR) TTF looks like sharp and consistant, while two
|  > other fonts have problem with rendering of 'e' (blurred top part withot
|  > hole) and 'a' (too wide) - see screenshot atatched.
|
|  My first suggestion would be to force autohinting on ps fonts.  You can
| test this in ftview with the 'f' key.

This is indeed an option, and using PfaEdit I can produce version of my fonts 
with all PS Type1 hints stripped.
But, as you can notice from screenshot in my previous mail, autohinter has 
problem with latin 'g', not speaking about problems with Cyrillic 'д', 'Д', 
'ц', 'Ц' (de, tse) - horizontal stem at the bottom of those stems disappears 
when you apply autohinter.

|
|  If you don't want to force the autohinter, you can try applying the
| following patches to the ps hinter.  The first one implements the bluescale
| optimization for the ps hinter, and it will help with the problem of the

Speaking about BlueScale value - is default value used in most fonts (.039625) 
ok for FreeType, or ther eis some algorithm applicable to this value which 
can enhance rendering?
Besides, are those values:
BlueShift = 7
BlueFuzz = 1

taken into consideration in FT PS hinter and how I can tune those values to 
modify rendering?

Adobe specs are very unclear on those values, and Ihave heard that latest 
version sof Adobe PS T1 fonts use modified PS private dictionary with updated 
"Blue***" values and updated rendering algorithms.
Can someone add something to this?

| closed 'e'.  It appears that this is not destined for 2.1.4, but you can
| find it at the end of this post:
|
|  http://www.freetype.org/pipermail/devel/2003-February/008889.html

well, if that patch can fix closed 'e' - that I would strongly insist to 
include this patch in FT 2.1.4!

BTW:  is it possible to utilize this functionality via some API?
Than it would be posisble to have this patch built-in, and turn specific 
calculations off when those are unnecessary.
(when this patch is not desired, BTW?)

|
|  The next patch turns stem width quantization back on; the patch was
| suggested in this post:
|
|  http://www.freetype.org/pipermail/freetype/2003-March/005998.html
|
|  In my opinion, more text at more sizes looks better the way it is in CVS
| now, with the quantization code toggled off.  As you get into the 15-17pt
| range, that code on has the effect of making stem weight noticeably
| inconsistent. However, at the size you are testing with, toggling the code
| on has the positive effect of giving more weight to the cross bars of
| lowercase e's, and otherwise making things a bit crisper in some cases.

Not that I test at specific size:
I use 9pt or 10pt text in most of documents, plus it's standard text size for 
my mail client (message body, message list, etc.) and in text editor 
(modifying HTML markup, etc.)
So, IMHO it's critical to achieve good rendeirng at 9pt-11pt.
There are no huge problems with 12pt+ rendering, at least if you have 
90dpi-100dpi+ display.

Thanks a lot for your clarifications!

|
|  David Chester
|
|  _______________________________________________
|  Devel mailing list
|  address@hidden
|  http://www.freetype.org/mailman/listinfo/devel

-- 

Best Regards,

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net