[ft-devel] FreeType 2.3.5 has been released.

FreeType 2.3.5 has been released.

It is available from

    http://savannah.nongnu.org/download/freetype/

or

    http://sourceforge.net/project/showfiles.php?group_id=3157

The latter site also holds older versions of the FreeType library.

See below  for the relevant snippet  from the CHANGES  file; all users
should upgrade.

Enjoy!

   Werner

----------------------------------------------------------------------

FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
producing high-quality output (glyph images) of most vector and bitmap
font formats.

Note that  FreeType 2 is  a font service  and doesn't provide  APIs to
perform higher-level features, like text layout or graphics processing
(e.g.,  colored  text  rendering,  `hollowing',  etc.).   However,  it

[ft] Idea for way of enabling subpixel hinting

Hello,

As far as I know subpixel hinting is disabled if I compile freetype2
using default configuration. It's because of patents. Because of this
same reason the most of distros provide freetype with subpixel hinting
disabled.

As the result if someone is using freetype provided with his/her
distro and want to enable subpixel hinting it is necessary to
recompile freetype. It makes all the operation quite comlicated and
avaliable for advanced Linux-users only.

I think I would be nice if every freetype user could enable subpixel
hinting just editing some text file. So we would kept subpixel hinting
disabled by default but it would be much easier to enable it. No more
compiling, installing. Just editing one line in one file.

Is my idea possible to realize?

--

-- 
Rafał Miłecki

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype

Re: [ft] Idea for way of enabling subpixel hinting

Hello Rafal,

unfortunately, implementing your idea means that we would be distributing
patent-infringing code, even if the configuration option is not enabled.

the current scheme is really the only reasonable alternative, due to the
current patent regime. Blame it on the laws, not the technology.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)

On Wed, 4 Jul 2007 16:13:58 +0200, "Rafal Milecki" <zajec5 <at> gmail.com> said:
> Hello,
> 
> As far as I know subpixel hinting is disabled if I compile freetype2
> using default configuration. It's because of patents. Because of this
> same reason the most of distros provide freetype with subpixel hinting
> disabled.
> 
> As the result if someone is using freetype provided with his/her
> distro and want to enable subpixel hinting it is necessary to
> recompile freetype. It makes all the operation quite comlicated and
> avaliable for advanced Linux-users only.
> 
> I think I would be nice if every freetype user could enable subpixel
> hinting just editing some text file. So we would kept subpixel hinting
> disabled by default but it would be much easier to enable it. No more
> compiling, installing. Just editing one line in one file.

Re: [ft] Idea for way of enabling subpixel hinting

2007/7/4, David Turner <david <at> freetype.org>:
> unfortunately, implementing your idea means that we would be distributing
> patent-infringing code, even if the configuration option is not enabled.

Is there really any difference from the law point of view if option
that enables subpixel hinting is available before or after compilation
of application? Law accepts existing of such an option in source of
application, but doesn't accept existing in configuration file?

--

-- 
Rafał Miłecki

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype

[ft] 2.3.5 compile error on Mac OS X

I'm trying to build 2.3.5 on OSX 10.4, and I get this error:

 gcc -pedantic -ansi
-I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/objs
-I./builds/unix
-I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/include -c
-Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DHAVE_ANSI_OS_INLINE=1
"-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY
"-DFT_CONFIG_MODULES_H=<ftmodule.h>"
-I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype
/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/truetype.c
 -fno-common -DPIC -o
/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/objs/.libs/truetype.o
In file included from
/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/truetype.c:24:
/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/ttgload.c:
In function 'load_truetype_glyph':
/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/ttgload.c:1406:
error: dereferencing pointer to incomplete type
/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/ttgload.c:1418:
error: dereferencing pointer to incomplete type

Any ideas what's going on?

Re: [ft] 2.3.5 compile error on Mac OS X

Hi,

I will check the issue next Monday (Jul-9th), please wait.

Regards,
mpsuzuki

Benjamin Reed wrote:
> I'm trying to build 2.3.5 on OSX 10.4, and I get this error:
>
> gcc -pedantic -ansi
> -I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/objs
> -I./builds/unix
> -I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/include -c
> -Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DHAVE_ANSI_OS_INLINE=1
> "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY
> "-DFT_CONFIG_MODULES_H=<ftmodule.h>"
> -I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype
> /Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/truetype.c 
>
> -fno-common -DPIC -o
> /Volumes/Shared/fink.build/freetype219/freetype-2.3.5/objs/.libs/truetype.o 
>
> In file included from
> /Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/truetype.c:24: 
>
> /Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/ttgload.c: 
>
> In function 'load_truetype_glyph':
> /Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/ttgload.c:1406: 

Re: [ft] 2.3.5 compile error on Mac OS X

Dear BenJamin Reed,

I couldn't reproduce the problem on Mac OS X 10.4.10
on PowerPC. You're using Intel Mac?

Regards,
mpsuzuki

suzuki toshiya wrote:
> Hi,
>
> I will check the issue next Monday (Jul-9th), please wait.
>
> Regards,
> mpsuzuki
>
> Benjamin Reed wrote:
>> I'm trying to build 2.3.5 on OSX 10.4, and I get this error:
>>
>> gcc -pedantic -ansi
>> -I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/objs
>> -I./builds/unix
>> -I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/include -c
>> -Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DHAVE_ANSI_OS_INLINE=1
>> "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY
>> "-DFT_CONFIG_MODULES_H=<ftmodule.h>"
>> -I/Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype
>> /Volumes/Shared/fink.build/freetype219/freetype-2.3.5/src/truetype/truetype.c 
>>
>> -fno-common -DPIC -o

[ft] Fwd: Re: Texts Rasterization Exposures

By the way, here's my answer to Maxim's questions

----- Original message -----
From: "David Turner" <david <at> freetype.org>
To: "Maxim Shemanarev" <mcseem <at> antigrain.com>, freetype <at> freetype.org
Date: Tue, 10 Jul 2007 14:58:28 +0200
Subject: Re: Texts Rasterization Exposures

Hello Maxim,

On Sun, 8 Jul 2007 16:20:50 -0400, "Maxim Shemanarev" <mcseem <at> antigrain.com> said:
> Hi David,
> 
> I'm the author of the Anti-Grain Geometry project, and we have a contact 
> with you about 3 years ago. 

Yes, I remember pretty well. Good to be in contact again..

> I finally tried to summarize my experience and observations concerning the
> situation with text rasterization in Windows and Linux. The article also 
> contains demo applications to play with my method of RGB sub-pixel text
> rendering. I admit some statements may  sound questionable, so, I appreciate
> any comments, criticism, and  discussions. So, here it is:
> http://antigrain.com/research/font_rasterization/index.html
> 
> It would be very interesting to learn about your opinion. The simple method 
> I propose may be of potential interest in the GNU/Linux community.
> 
ok, I've read your page, and here are my remarks, in no relevant order:

[ft] Re: Texts Rasterization Exposures

Hi Maxim,

On Wed, 11 Jul 2007 11:32:11 -0400, mcseem <at> antigrain.com said:
> Hi David, 
> 
> Thanks for reading the article and Many thanks for your comprehensive
> response!
> I'll reply quickly.
> 
> 1. I agree that the backward compatibility is a real curse. But 5 years
> ago, when MS introduced ClearType, it was *very* possible to provide the
> possibility of accurate layout making, *along* with the existing API.
> They didn't do that. I'm sure if they did, the situation with scalable
> forms would be much better nowadays. Besides, You can take Adobe Acrobat
> Reader and turn AA off. Everything remains readable while preserving the
> layout. It means it's very possible with all methods, B&W mono,
> grayscale, and RGB sub-pixel.
> 
Acrobat does a lot of subtle things with text, for example they implement
sub-pixel hinting[1] (i.e. they hint sub-pixel positioned linearly stretched
vectors), they also change the inter-word spacing, and can expand/contract
glyph shapes as well to better fit a paragraph line width.

generally speaking, high-quality text layout is a subtle thing that requires
some pretty heavy computations to do well. You can read the explanations of
the TeX layout algorithm for an overview. All of this is rather complex and
slow, and I can understand why this is not part of any standard text rendering
engine on any consumer-grade operating system, OS X included.

Apart from that, I believe that Microsoft is obsessed with backwards legacy

[ft] Re: Texts Rasterization Exposures

Hi Maxim,

thanks, it's look like a bug (the FT_Set_Char_Size function is
more or less truncating the scale to integer pixel sizes, which
is only really needed for hinted rendering).

I'm leaving for a 2-weeks vacations right now. I don't know if
I'll have internet access there, so I'll commit a fix after I
come back at worst.

Regards,

- David

On Wed, 11 Jul 2007 12:53:03 -0400, mcseem <at> antigrain.com said:
> Thanks for the info!
> 
> > This definitely looks like a bug, because the 
> > linearHoriAdvance field is designed precisely 
> > to return a non-snapped value. Could you give 
> > me a concrete example of the problem, so I can 
> > have a look at it ?
> 
> Font: cour.ttf from WinXP
> Hinting: FT_LOAD_NO_HINTING
> Then I use:
> FT_Set_Char_Size(face, 0, height, 72, 72); 
> where "heights" are: 
> 7.02, 7.80, 8.58, 9.36, 10.14, 10.92, 11.70, 12.48, 
> 13.26, 14.04, 14.82, 15.60