Michael Reilly | 20 Jul 22:49 2016
Picon
Gravatar

[ft] Permission to use FreeType logo

Hello,

May I have permission to use the libfreetype logo in the credits of my 
project as part of a larger open source acknowledments section?

Thanks,

Michael
Werner LEMBERG | 5 Jul 20:16 2016
Picon

[ft] Announcing FreeType version 2.6.4


FreeType 2.6.4 has been released.

It is available from

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

or

    http://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.

Enjoy!

   Werner

PS: Downloads from  savannah.nongnu.org  will redirect to your nearest
    mirror site.   Files on  mirrors may  be subject to  a replication
    delay   of   up   to   24   hours.   In   case   of  problems  use
    http://download-mirror.savannah.gnu.org/releases/

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

http://www.freetype.org

FreeType 2  is a software  font engine that  is designed to  be small,
efficient,  highly   customizable,  and  portable   while  capable  of
(Continue reading)

Cao, Jun | 1 Jul 23:03 2016

[ft] Looking for an assistant to access the “True Type Font” library

FreeType:

 

We are looking for an assistant to display international fonts on a small LCD module (the LCD module is CGG162036B00-FKW-R-03.  The LCD controller is UC1609 ) through “True Type Font” library.  We have the “True Type Font” international library from previous project.  The main issue is how to access the “True Type Font” library, since after changed the OS, the corresponding support cannot be used anymore.   

We are so glad to find that FreeType is a freely available software library to render fonts include the “True Type Font” library.  Can you give us detail guidance or your specialist work for us as a consultant?

 

Thanks!

 

Jun Cao

Nielsen

7000 Columbia Gateway Drive

Suite 200

Columbia, MD 21046

+1 6677864635 (voice)
e-mail: Jun.X.Cao <at> Nielsen.com

 

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
vaibhav kale | 14 Jun 14:37 2016
Picon

[ft] Rendering of GD&T symbols

Hello,

Can FreeType font engine be used to render Geometric dimensioning and tolerancing symbols(wiki link: https://en.wikipedia.org/wiki/Geometric_dimensioning_and_tolerancing).

If yes,  from which version has this support been provided?

Thanks and Best Regards,
Vaibhav
_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
Kim Klingler | 14 Jun 11:55 2016
Picon

[ft] Network unlock code

Previous owner told me the phone was unlocked but it wasn't. Not real sure I am do this right. New to me so forgive me if I ask a dumb question.  Thank you Kim

_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
suzuki toshiya | 16 May 15:15 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Werner,

Oh, I slipped to mention a change from my patch in previous
post and committed one. In previous post in this list, I added
a public function FT_List_GetNodeAt(). But, now I moved it into
ttgload.c, as a private function. It is just because once we
publish some function, we cannot withdraw it. If there is a
better place to include the internal utility functions, I will
do so.

Regards,
mpsuzuki

suzuki toshiya wrote:
> Dear Werner,
> 
> Just I've committed the simpler patch.
> 
> Reading your comment carefully, "might not be working with the
> platform whose default pointer is less than 32-bit" was already
> commented :-).
> 
> Maybe just 16-bit compiler would not be sufficient, the compilers
> supporting Intel tiny/small/medium memory model should be used
> to check what will happen. Watcom compiler could be a candidate.
> But please let me work for this issue in later...
> 
> Regards,
> mpsuzuki
> 
> 
> Werner LEMBERG wrote:
>>> I updated the simplest fix in my hand.  I was going to commit it to
>>> head of git repository, but savannah is in some network trouble.
>>> Attached is the patch, but if anybody wants, I will make a "make
>>> dist" tarball which is ready to "./configure && make".  please let
>>> me know.
>> Savannah seems to be back, so please proceed!
>>
>>> Also I have more complex patch using same strategy but do not rely
>>> on arbitrary usage of GID.  I think the current patch would work on
>>> the platforms whose default pointer is 32-bit.  For the platform
>>> whose default pointer is 16-bit or shorter, some fonts having 64k
>>> glyphs can confuse the simplest fix.
>> I haven't tested 16bit support since years, given that you can't
>> create 16bit code with gcc.[*] However, I've just found in the
>> internet that recent clang versions support an `-m16' option that
>> apparently produces valid 16bit code!  So you might test compilation
>> of FreeType with this option, but I guess that you will find zillions
>> of problems...
>>
>> Today, I'm no longer sure whether 16bit support makes sense at all, so
>> maybe you shouldn't spend time on this.
>>
>>
>>     Werner
>>
>>
>> [*] Option `-m16' introduced in gcc 4.9.0 doesn't provide a real 16bit
>>     environment; it has a special usage for bootloader code and the
>>     like.
>>
> 
> _______________________________________________
> Freetype mailing list
> Freetype <at> nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype
> 
suzuki toshiya | 16 May 15:22 2016
Picon

Re: [ft] Glyph 0xBB does not load from TTF-FreeFont FreeSerif.ttf since 6.12.2

Dear Volker,

Thank you for reporting, your issue seems to be same with
the issue discussed in "Failure in loading U+033F in DejaVu fonts".

I think the latest git head fixes this issue. If possible,
please test. I tested by myself and the issue seems to be
fixed.

Regards,
mpsuzuki

Volker Schatz wrote:
>     Hello,
> 
> I am using freetype in a personal fork of the text/graphical links browser and
> have the following issue since a few months ago.
> 
> As of version 6.12.2, a single glyph from FreeSerif.ttf (from
> http://www.nongnu.org/freefont/) cannot be loaded any more, namely code point
> 0xBB (">>", guillemotright).
> 
> This small program demonstrates the problem:
> http://volkerschatz.com/tmp/freetype2-0xBB.c
> With my current freetype version, 6.12.3, it fails, but when LD_PRELOADing
> version 6.12.1, it succeeds.  As far as I can tell, the problem occurs only
> with FreeSerif.ttf and only with glyph 0xBB.
> 
> The error code is 0x15, "invalid composite glyph".  As far as I can see with
> fontforge, this looks like a composite glyph, as each of the ">" angles has a
> caption "guilsinglright" attached.  But the same goes for 0xAB (guillemotleft),
> which loads OK with the current freetype library.  I do not have the tools to
> investigate the font file further.
> 
> Should I file a bug report for freetype, am I doing something wrong, or is it a
> bug in FreeSerif.ttf?
> 
> Thanks in advance for any help.
> 
> Volker
> 
> 
> PS: I am using Arch Linux.  System details:
> $ uname -a
> Linux octopus 4.4.10-1-lts #1 SMP Wed May 11 21:03:02 CEST 2016 x86_64 GNU/Linux
> $ ldd /usr/lib/libfreetype.so.6.12.3 
>     linux-vdso.so.1 (0x00007ffd3386b000)
>     libz.so.1 => /usr/lib/libz.so.1 (0x00007f643b189000)
>     libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f643af79000)
>     libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f643ad41000)
>     libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007f643aac1000)
>     libc.so.6 => /usr/lib/libc.so.6 (0x00007f643a719000)
>     libm.so.6 => /usr/lib/libm.so.6 (0x00007f643a411000)
>     libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f643a101000)
>     libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007f6439ed1000)
>     /usr/lib64/ld-linux-x86-64.so.2 (0x000055d7c14f3000)
>     libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f6439c61000)
>     libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f6439a41000)
> 
> 
> 
> _______________________________________________
> Freetype mailing list
> Freetype <at> nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype
> 
suzuki toshiya | 16 May 15:08 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Werner,

Just I've committed the simpler patch.

Reading your comment carefully, "might not be working with the
platform whose default pointer is less than 32-bit" was already
commented :-).

Maybe just 16-bit compiler would not be sufficient, the compilers
supporting Intel tiny/small/medium memory model should be used
to check what will happen. Watcom compiler could be a candidate.
But please let me work for this issue in later...

Regards,
mpsuzuki

Werner LEMBERG wrote:
>> I updated the simplest fix in my hand.  I was going to commit it to
>> head of git repository, but savannah is in some network trouble.
>> Attached is the patch, but if anybody wants, I will make a "make
>> dist" tarball which is ready to "./configure && make".  please let
>> me know.
> 
> Savannah seems to be back, so please proceed!
> 
>> Also I have more complex patch using same strategy but do not rely
>> on arbitrary usage of GID.  I think the current patch would work on
>> the platforms whose default pointer is 32-bit.  For the platform
>> whose default pointer is 16-bit or shorter, some fonts having 64k
>> glyphs can confuse the simplest fix.
> 
> I haven't tested 16bit support since years, given that you can't
> create 16bit code with gcc.[*] However, I've just found in the
> internet that recent clang versions support an `-m16' option that
> apparently produces valid 16bit code!  So you might test compilation
> of FreeType with this option, but I guess that you will find zillions
> of problems...
> 
> Today, I'm no longer sure whether 16bit support makes sense at all, so
> maybe you shouldn't spend time on this.
> 
> 
>     Werner
> 
> 
> [*] Option `-m16' introduced in gcc 4.9.0 doesn't provide a real 16bit
>     environment; it has a special usage for bootloader code and the
>     like.
> 
Volker Schatz | 16 May 14:01 2016

[ft] Glyph 0xBB does not load from TTF-FreeFont FreeSerif.ttf since 6.12.2

    Hello,

I am using freetype in a personal fork of the text/graphical links browser and
have the following issue since a few months ago.

As of version 6.12.2, a single glyph from FreeSerif.ttf (from
http://www.nongnu.org/freefont/) cannot be loaded any more, namely code point
0xBB (">>", guillemotright).

This small program demonstrates the problem:
http://volkerschatz.com/tmp/freetype2-0xBB.c
With my current freetype version, 6.12.3, it fails, but when LD_PRELOADing
version 6.12.1, it succeeds.  As far as I can tell, the problem occurs only
with FreeSerif.ttf and only with glyph 0xBB.

The error code is 0x15, "invalid composite glyph".  As far as I can see with
fontforge, this looks like a composite glyph, as each of the ">" angles has a
caption "guilsinglright" attached.  But the same goes for 0xAB (guillemotleft),
which loads OK with the current freetype library.  I do not have the tools to
investigate the font file further.

Should I file a bug report for freetype, am I doing something wrong, or is it a
bug in FreeSerif.ttf?

Thanks in advance for any help.

Volker

PS: I am using Arch Linux.  System details:
$ uname -a
Linux octopus 4.4.10-1-lts #1 SMP Wed May 11 21:03:02 CEST 2016 x86_64 GNU/Linux
$ ldd /usr/lib/libfreetype.so.6.12.3 
    linux-vdso.so.1 (0x00007ffd3386b000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007f643b189000)
    libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f643af79000)
    libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f643ad41000)
    libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007f643aac1000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f643a719000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f643a411000)
    libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f643a101000)
    libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007f6439ed1000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x000055d7c14f3000)
    libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f6439c61000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f6439a41000)
suzuki toshiya | 15 May 04:38 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Khaled,

Thank you for providing another example. It seems that
oriya.ttf is really including a recursive reference
(gid=8 refers gid=64 & gid=8).

I updated the simplest fix in my hand. I was going to
commit it to head of git repository, but savannah is
in some network trouble. Attached is the patch, but
if anybody wants, I will make a "make dist" tarball
which is ready to "./configure && make". please let me
know.

Also I have more complex patch using same strategy but
do not rely on arbitrary usage of GID. I think the
current patch would work on the platforms whose default
pointer is 32-bit. For the platform whose default pointer
is 16-bit or shorter, some fonts having 64k glyphs can
confuse the simplest fix.

Regards,
mpsuzuki

Khaled Hosny wrote:
> On Tue, May 10, 2016 at 08:32:48PM +0900, suzuki toshiya wrote:
>> Dear Werner,
>>
>>> Should I consider overwriting (and extend if required)
>>> storategy, to minimize the memory management?
>> If we can assume the recurse_count in load_truetype_glyph()
>> is always incrementally changed, it is possible to use
>> the index of the node to record the recurse_count.
>> This assumption reduces the size of the patch.
>>
>> To reduce the repeated allocation & freeing the node,
>> I fill the unused nodes by gid = -1.
> 
> I can not comment on the code, but I confirm this patch fixes the issue
> for DejaVu fonts. However I’m having a similar issues with oriya.ttf
> font from http://www.indlinux.org/downloads/files/indic-otf-0.2.tar.gz:
> 
> $ FT2_DEBUG="any:2" ftview -m ଅ 100 oriya.ttf
> 
> Gives the same error, but I can’t ttx the font so it might be broken.
> 
> Regards,
> Khaled
> 
Attachment (mps20160515-1130.diff): text/x-patch, 4881 bytes
_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype
suzuki toshiya | 10 May 13:32 2016
Picon

Re: [ft] Failure in loading U+033F in DejaVu fonts

Dear Werner,

> Should I consider overwriting (and extend if required)
> storategy, to minimize the memory management?

If we can assume the recurse_count in load_truetype_glyph()
is always incrementally changed, it is possible to use
the index of the node to record the recurse_count.
This assumption reduces the size of the patch.

To reduce the repeated allocation & freeing the node,
I fill the unused nodes by gid = -1.

Regards,
mpsuzuki

Attachment (mps20160510-1900.diff): text/x-patch, 4430 bytes
_______________________________________________
Freetype mailing list
Freetype <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype

Gmane