> Unfortunatelly the commit messages shows me as an author, which is
> not the case, apart from `extern "C++"' and `inline' the code/idea
> is that of Richard Henderson. Sorry if i haven't made it crystal
> clear in the original posting :(
I've added his name to the ChangeLog entry, thanks.
On Mon, 12 Jul 2010, Werner LEMBERG wrote:
>
> > I've asked Richard Henderson about this, and his conclusion is:
> > a. the code is broken
>
> :-) We are no C++ experts...
>
> > b. following fixes it
>
> Thanks a lot! I've checked it in.
Unfortunatelly the commit messages shows me as an aut
FreeType 2.4.0 has been released.
It is available from
http://savannah.nongnu.org/download/freetype/
or
https://sourceforge.net/projects/freetype/files/
The latter site also holds older versions of the FreeType library.
See below for the relevant snippet from the CHANGES file; us
> I've asked Richard Henderson about this, and his conclusion is:
> a. the code is broken
:-) We are no C++ experts...
> b. following fixes it
Thanks a lot! I've checked it in.
> Following helps full with another issue.
This I've already fixed yesterday.
Werner
__
On Sun, 11 Jul 2010, Werner LEMBERG wrote:
>
> Folks,
>
>
> it seems that g++ 4.5.0 is ridiculously picky w.r.t. type-punning:
> While previous g++ versions have been made silent successfully, the
> latest version reports zillions of warnings.
>
> The code hasn't changed basically; all warning
The requirement for our software is backwards compatibility with current FT2
behaviour - not for identity between FT2 charmap index and TrueType cmap
subtable index.
It is possible, however, that we have never seen "heavily broken subtables" and
that (some of) our code does in fact depend on t
Dear David,
Thank you for information! I'm not pushing the
charmap sorting features to default behaviour, but
knowing the exist of softwares that requires the
consistency between FT2 charmap index versus TTF/OTF
cmap subtable index.
I want to ask another question about your software:
FT2 charm
Hi!
Our software uses the FreeType charmap index directly to access the appropriate
cmap. (In retrospect, that was perhaps a poor design decision.)
We will need to be able to retain the existing behaviour. However, if the
original index is available somehow, we would have no problems with a ch