[ft] charmap

Hi,

I am using the Arial.ttf and cant get the right character mapping for 
special german characters "äöüß" although my charmap is unicode.
Can it have to do with the character values of those being negative?
string text;
text[i] --> negative number for "äöüßâàá..."
FT_Get_Char_Index( face, text[i]); --> returns always 0 for those 
special characters.

thank you
martin.

Re: [ft] charmap

Martin Olbrich wrote:
>I am using the Arial.ttf and cant get the right character mapping for 
>special german characters "äöüß" although my charmap is unicode.
>Can it have to do with the character values of those being negative?

Positive:

  FT_EXPORT( FT_UInt )
  FT_Get_Char_Index( FT_Face   face,
                     FT_ULong  charcode );

So, if you pass a small negative value to unsigned long charcode, you
will get a problem, that means a really big number.

I don't know what is best practice in C, declare text unsigned char * or
tell the compiler chars are unsigned or insert a type cast.

Hope that helps,

Christian

[ft] sub-pixel-hinting of ft 2.2.1 and ft 2.1.10 differs

I wonder why the results for sub-pixel-hinting differ between 
Freetype 2.1.10 and Freetype 2.2.1.20061027 (CVS from 2006-10-27).

The byte code interpreter is compiled in in both versions
of freetype.

Here are two screen shots:

http://lisa.goe.net/~mfabian/freetype2-luxi-mono-sub-pixel-hinting-problem/luxi-mono-sub-pixel-hinting-ft-2.1.10.png
http://lisa.goe.net/~mfabian/freetype2-luxi-mono-sub-pixel-hinting-problem/luxi-mono-sub-pixel-hinting-ft-2.2.1.20061027.png

(Luxi Mono is just an arbitrary example, it seems to happen with all
fonts).

In the ft-2.1.10 screen shot, the vertical lines are solid black. In
the ft-2.2.1.20061027 screen shot, all the vertical lines have light
blue shadow at the right side.

This is easy to see when enlarging with "xmag", but I can see that
easily already without enlarging while reading text with
sub-pixel-hinting rendered by ft-2.2.1.20061027. Looks strange to me.

Is that a bug or is this light blue shadow there on purpose?

--

-- 
Mike FABIAN   <mfabian <at> suse.de>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

Re: [ft] sub-pixel-hinting of ft 2.2.1 and ft 2.1.10 differs

02 Kas 2006 Per 19:00 tarihinde, Mike FABIAN şunları yazmıştı: 
> I wonder why the results for sub-pixel-hinting differ between
> Freetype 2.1.10 and Freetype 2.2.1.20061027 (CVS from 2006-10-27).
>
> The byte code interpreter is compiled in in both versions
> of freetype.
>
> Here are two screen shots:
>
> http://lisa.goe.net/~mfabian/freetype2-luxi-mono-sub-pixel-hinting-problem/
>luxi-mono-sub-pixel-hinting-ft-2.1.10.png
> http://lisa.goe.net/~mfabian/freetype2-luxi-mono-sub-pixel-hinting-problem/
>luxi-mono-sub-pixel-hinting-ft-2.2.1.20061027.png
>

Hmm I know Suse switched to new LCD rendering for for libXft so I guess this 
is the same issue I reported[1] , solution is to use old libXft LCD rendering 
patch.

[1] http://www.nabble.com/Testing-new-LCD-rendering-mode-tf2382905.html

Regards,
ismail

[ft] Re: sub-pixel-hinting of ft 2.2.1 and ft 2.1.10 differs

Ismail Donmez <ismail <at> pardus.org.tr> さんは書きました:

> 02 Kas 2006 Per 19:00 tarihinde, Mike FABIAN şunları yazmıştı: 
>> I wonder why the results for sub-pixel-hinting differ between
>> Freetype 2.1.10 and Freetype 2.2.1.20061027 (CVS from 2006-10-27).
>>
>> The byte code interpreter is compiled in in both versions
>> of freetype.
>>
>> Here are two screen shots:
>>
>> http://lisa.goe.net/~mfabian/freetype2-luxi-mono-sub-pixel-hinting-problem/
>>luxi-mono-sub-pixel-hinting-ft-2.1.10.png
>> http://lisa.goe.net/~mfabian/freetype2-luxi-mono-sub-pixel-hinting-problem/
>>luxi-mono-sub-pixel-hinting-ft-2.2.1.20061027.png
>>
>
> Hmm I know Suse switched to new LCD rendering for for libXft so I guess this 
> is the same issue I reported[1] , solution is to use old libXft LCD rendering 
> patch.

The screen shots have been made with ftview which isn't linked against
libXft:

mfabian <at> magellan:~$ ldd /usr/bin/ftview | grep -i xft
mfabian <at> magellan:~$ ldd /usr/bin/xfd | grep -i xft
        libXft.so.2 => /usr/lib64/libXft.so.2 (0x00002ae7db8f2000)
mfabian <at> magellan:~$

> [1] http://www.nabble.com/Testing-new-LCD-rendering-mode-tf2382905.html

Re: [ft] sub-pixel-hinting of ft 2.2.1 and ft 2.1.10 differs

>>>>> "Mike" == Mike FABIAN <mfabian <at> suse.de> writes:

Mike> I wonder why the results for sub-pixel-hinting differ between 
Mike> Freetype 2.1.10 and Freetype 2.2.1.20061027 (CVS from 2006-10-27).

Mike> The byte code interpreter is compiled in in both versions
Mike> of freetype.

Is -DFT_CONFIG_OPTION_SUBPIXEL_RENDERING also specified?

Using just -DTT_CONFIG_OPTION_BYTECODE_INTERPRETER isn't enough to
duplicate the previous behavior.

-JimC
--

-- 
James Cloos <cloos <at> jhcloos.com>         OpenPGP: 0xED7DAEA6

[ft] Re: sub-pixel-hinting of ft 2.2.1 and ft 2.1.10 differs

James Cloos <cloos <at> jhcloos.com> さんは書きました:

>>>>>> "Mike" == Mike FABIAN <mfabian <at> suse.de> writes:
>
> Mike> I wonder why the results for sub-pixel-hinting differ between 
> Mike> Freetype 2.1.10 and Freetype 2.2.1.20061027 (CVS from 2006-10-27).
>
> Mike> The byte code interpreter is compiled in in both versions
> Mike> of freetype.
>
> Is -DFT_CONFIG_OPTION_SUBPIXEL_RENDERING also specified?

Yes, of course. 

Without that option "ftview" shows only gray scale anti-aliasing when
cycling to "horizontal LCD-optimized rendering on (RGB)" using the 'L'
key.

But I don't see gray scale anti-aliasing, I see colour, i.e.  this
option is definitely set.

But the colours I see in ftview appear to be wrong.

> Using just -DTT_CONFIG_OPTION_BYTECODE_INTERPRETER isn't enough to
> duplicate the previous behavior.
>
> -JimC
> -- 
> James Cloos <cloos <at> jhcloos.com>         OpenPGP: 0xED7DAEA6
>

[ft] Speed/Quality adjustments

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

Re: [ft] Speed/Quality adjustments

Are you caching the bitmaps produced by freetype? If not, that's  
probably the best way to make it faster.

Tom

On Nov 10, 2006, at 7:45 AM, Riede.Edward wrote:

> I have been investigating embedding freetype into one of our  
> platforms, and it looks great, but runs really slow.  I was  
> wondering if there are any adjustments that I could make to the  
> engine to speed it up a bit?  The rendering times on our platform  
> are unbearably slow.   I would like a speed improvement of about  
> x32. (I know it is a lot to ask.)
>
>
>
> I am thinking about changing the sub pixel resolution.  Our  
> platform only displays in 16 bit color, so it seems to me that the  
> 64x64 sub-pixel’s/pixel could be reduced.  64x64 would give 4096  
> units/pixel.  I would think that this could be reduced to 32 units/ 
> pixel for the 5 bit component, or 96 units/pixel for lcd  
> rendering.  32 units per pixel would need a 5x5, and 96 would need  
> a 10 x 10.
>
>
>
> It seems like this could give me the speed improvements that I  
> need.  Is this possible?
>
>
>
>
>
> Ed
>
>
>
>
>
> _______________________________________________
> Freetype mailing list
> Freetype <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/freetype

文林 Wenlin Institute, Inc.        Software for Learning Chinese
E-mail: wenlin <at> wenlin.com     Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯

RE: [ft] Speed/Quality adjustments

Unfortunately the ftcache.c locks up the compiler for my target. (it just hangs, no warnings or errors), so
I am not caching the rendered bitmaps at the moment.  This is an option if I write my on cache or 'fix' the
included one, but it obviously won't speed the first rendering. The depth of the cache I can have and
available memory are not necessarily constant, so the subsequent renderings are questionalble.  I would
also like something deterministic if I could get it.  I am considering pre-rendering to eprom at compile
time, then copying the results without rendering on the target.   

Ed

-----Original Message-----
From: freetype-bounces+edward.riede=igt.com <at> nongnu.org
[mailto:freetype-bounces+edward.riede=igt.com <at> nongnu.org] On Behalf Of Wenlin Institute
Sent: Friday, November 10, 2006 10:21 AM
To: freetype <at> nongnu.org
Subject: Re: [ft] Speed/Quality adjustments

Are you caching the bitmaps produced by freetype? If not, that's  
probably the best way to make it faster.

Tom

On Nov 10, 2006, at 7:45 AM, Riede.Edward wrote:

> I have been investigating embedding freetype into one of our  
> platforms, and it looks great, but runs really slow.  I was  
> wondering if there are any adjustments that I could make to the  
> engine to speed it up a bit?  The rendering times on our platform  
> are unbearably slow.   I would like a speed improvement of about  
> x32. (I know it is a lot to ask.)
>
>
>
> I am thinking about changing the sub pixel resolution.  Our  
> platform only displays in 16 bit color, so it seems to me that the  
> 64x64 sub-pixel’s/pixel could be reduced.  64x64 would give 4096  
> units/pixel.  I would think that this could be reduced to 32 units/ 
> pixel for the 5 bit component, or 96 units/pixel for lcd  
> rendering.  32 units per pixel would need a 5x5, and 96 would need  
> a 10 x 10.
>
>
>
> It seems like this could give me the speed improvements that I  
> need.  Is this possible?
>
>
>
>
>
> Ed
>
>
>
>
>
> _______________________________________________
> Freetype mailing list
> Freetype <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/freetype



文林 Wenlin Institute, Inc.        Software for Learning Chinese
E-mail: wenlin <at> wenlin.com     Web: http://www.wenlin.com

Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯







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

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