Mahendra Tallur | 1 Aug 2005 09:53

Re: [ft] Re French accents & Freetype2 :)


> when using ft2, trying to display some text in iso 8859-1 encoding, the
> French accents don't get displayed - I get empty boxes instead.

OK, so when keeping the most important bits, here is basically what I do
- in other word, I don't select another Charmap, because I can't find an
iso 8859-1 one, just unicode...

	
FT_Library library;
FT_Face face;

if ((error = FT_Init_FreeType( &library )))
{
	*ierr=2;
	return(-1);
}
		
if ((error = FT_New_Face( library, font, 0, &face )))
{
	*ierr=3;
	return(-1);
} 

(...)

glyph_index = FT_Get_Char_Index(face, text[i]); 

failure |= FT_Load_Glyph(face, glyph_index, FT_LOAD_DEFAULT ); 
failure |= FT_Render_Glyph(face->glyph, ft_render_mode_normal ); 
(Continue reading)

Werner LEMBERG | 1 Aug 2005 12:09
Picon

Re: [ft] Re French accents & Freetype2 :)


> OK, so when keeping the most important bits, here is basically what
> I do - in other word, I don't select another Charmap, because I
> can't find an iso 8859-1 one, just unicode...

Your snippet is not very useful because it doesn't show which variable
types you use.  If possible, provide a short stand-alone example which
can be compiled directly.

BTW, there is no default charmap, you have to select Unicode
explicitly.

    Werner
stefan.moritz | 1 Aug 2005 11:06
Picon

[ft] W.: Freetype2

Dear David, dear developers of Freetype

FreeType2 is a great project! It works also well under Windows.
But I've 3 questions.
The email adress devel <at> freetype.org doesn't exist anymore! 
1.)The structure FT_Resource   and the function  FT_New_Resource( engine, filename, &resource )does'nt 
exist too or have I overlooked it? There was nothing in the API doc.
2.)I want to run  Freetype2 under VxWorks(later perhaps QNX).
VXWorks uses the UGL Lib.
How can I integrate Freetype2 with less effort in Vxworks?
Is there already a demo?
3.) Vx Works uses in the ROM coded fonts(see below ), no binary font files
How can I read the datas from the fonts (C coded) correctly in the face object?
Many thanks in advance!
A german developer can also answer in german!

Kind regards
Stefan 

/*
  C-file generated by emWin Font Converter V2.14 Beta
  Compiled:    Oct 23 2001 at 16:50:09

    Source file: Frutiger55Roman19AA4.c
  Font:        Frutiger 55 Roman
  Height:      19
*/

#include "GUI.H"

(Continue reading)

listes | 3 Aug 2005 10:56

[ft] Still some accents issues :)

Hi again everyone,

I must be really really bad, but I still didn't manage to display a single
latin-1 specific characters. I found an article
(http://apia.u-strasbg.fr/vrml/utile/special.html) with a piece of code
explaining how to convert iso8859-1 to UTF8 but I still didn't manage to
achieve anything.

In fact, even this single call fails :

glyph_index = FT_Get_Char_Index(face, 0xC3A9);

0xC3A9 being, according to this article, the code for the french "é". It always
returns 0. Of course, I selected the unicode charmap and I also tried with
several fonts, just in case.

[A bit off topic, but out of curiosity : special characters in ASCII belong to
128-255 in the case of an unsigned char. Do the same symbols, in signed char or
unsigned char have the same values in terms of bits ? Do bitwise operations have
the same effects if applied to signed / unsigned variables ?]

Thanks again to everyone,

- mahen
David Bevan | 3 Aug 2005 11:31

Re: [ft] Still some accents issues :)


listes <at> mahen-fr.net wrote:

> I must be really really bad, but I still didn't manage to display a single
> latin-1 specific characters. I found an article
> (http://apia.u-strasbg.fr/vrml/utile/special.html) with a piece of code
> explaining how to convert iso8859-1 to UTF8 but I still didn't manage to
> achieve anything.
> 
> In fact, even this single call fails :
> 
> glyph_index = FT_Get_Char_Index(face, 0xC3A9);

> 0xC3A9 being, according to this article, the code for the french "é". It always
> returns 0. Of course, I selected the unicode charmap and I also tried with
> several fonts, just in case.

You don't want to use the UTF-8 encoding of the char. You need to use 
the Unicode value itself - 0xE9 for e-acute.

David %^>

--

-- 
  ________________________________________________________
  David Bevan, Emtex Ltd.
  Emtex House, Station Road, Kings Langley, Herts. WD4 8LH England
  Tel:    +44 (0)1923 270882
  E-mail: dbevan <at> emtex.com
  Web:    www.emtex.com
(Continue reading)

Jan Slupski | 3 Aug 2005 12:09

Re: [ft] Still some accents issues :)

On Wed, 3 Aug 2005 listes <at> mahen-fr.net wrote:

> Hi again everyone,
>
> I must be really really bad, but I still didn't manage to display a single
> latin-1 specific characters. I found an article
> (http://apia.u-strasbg.fr/vrml/utile/special.html) with a piece of code
> explaining how to convert iso8859-1 to UTF8 but I still didn't manage to
> achieve anything.

You do not have to pass UTF8 encoded character. This is an error.
You need to pass Unicode index of the char in a 4-byte integer
(you can call it UCS4 encoded). For e-accent it would be just
FT_Get_Char_Index(face, 0xE9);

Also, do you call FT_Select_Charmap() to select Unicode before?
http://freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Select_Charmap
http://freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Encoding

Jan

    _  _  _  _  _____________________________________________
    | |_| |\ |  S L U P S K I             jslupski <at> juljas.net
  |_| | | | \|                             http://juljas.net/
Anthony Feick | 3 Aug 2005 22:53
Picon

[ft] crash loading font

We have 3 fonts that cause an illegal access violation in
"t1_builder_close_contour"  ("Adobe Jenson MM Italic Expert", "Kepler
MM Expert", and "Kepler MM Ornaments 1").  The
"decoder->builder->current" is null, and the function is trying to
access the "n_points" of "current".  It looks like "t1_builder_init"
is supposed to be called for every glyph, but it is only called once
in "t1_decoder_init".

Has anyone seen this problem of have any idea what the issue is here? 
 The only thing I can think is that most fonts don't use the
"op_endchar".  I can send the pfb font files to someone if that would
help.

We're using Freetype 2.1.9, but it doesn't like this stuff has been
changed in 2.1.10.
Anthony Feick | 5 Aug 2005 01:10
Picon

[ft] Licensing question

To: David Turner, Robert Wilhelm, and Werner Lemberg.  

In order to reduce the number of open file handles, I've had to use
our own mechanism for controlling the file handles for the fonts.   I
would like to use a couple functions in base/ftsystem.c, but they are
defined as "static" functions by default (ft_ansi_stream_close and
ft_ansi_stream_io).  Would it violate your license if I made a copy of
those functions in our code to control the streams?

The other option would be to remove the static keyword from the
definition in ftsystem.c, but I would prefer not having to change
freetype code everytime I get a new version.

BTW - We do aknowledge the Freetype Team in our credits.

Thanks,
Tony
Werner LEMBERG | 5 Aug 2005 07:20
Picon

Re: [ft] Licensing question


> In order to reduce the number of open file handles, I've had to use
> our own mechanism for controlling the file handles for the fonts.  I
> would like to use a couple functions in base/ftsystem.c, but they
> are defined as "static" functions by default (ft_ansi_stream_close
> and ft_ansi_stream_io).  Would it violate your license if I made a
> copy of those functions in our code to control the streams?

Of course not.

> BTW - We do acknowledge the Freetype Team in our credits.

This, together with distributing the appropriate FreeType license, is
sufficient.

    Werner
Werner LEMBERG | 5 Aug 2005 21:03
Picon

Re: [ft] crash loading font


> We have 3 fonts that cause an illegal access violation in
> "t1_builder_close_contour" ("Adobe Jenson MM Italic Expert", "Kepler
> MM Expert", and "Kepler MM Ornaments 1").  [...]
> 
> Has anyone seen this problem of have any idea what the issue is here? 

This is a *very* deep issue.  These Multiple Master fonts also fail
with fontforge, BTW.  [David, George, I've just sent you the smallest
of them privately.]  They reveal (at least) two serious bugs in
FreeType's Type 1 parser.

Bug 1:

The fonts contain this snippet (disassembled with t1disasm) somewhere
after the private dictionary:

  / <at> DInit {
          &thisfontdict /Private get /Subrs get exch get
          /cs exch def
          /ra rcs 256 idiv def
          /rb rcs 256 mod def
          /_i 0 def
          &thisfontdict /Private get /lenIV known
             {&thisfontdict /Private get /lenIV get
              dup 0 lt { pop / <at> decryptproc {} store 0 } if
             }
             {4} ifelse
            {  <at> Read pop } repeat
   } bind def
(Continue reading)


Gmane