[ft] Get copyright information from ttf file

2010-11-12 Thread Aniruddha Apte
Hello,

Is there any api in FreeType2 that returns copyright, author, legal,
license, and similar other information present in the .ttf file?

thanks
aniruddha
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype


Re: [ft] Get copyright information from ttf file

2010-11-12 Thread Henk Jan Priester

Aniruddha Apte wrote:

Hello,

Is there any api in FreeType2 that returns copyright, author, legal, 
license, and similar other information present in the .ttf file?


You can use the:

FT_Get_Sfnt_Name_Count
FT_Get_Sfnt_Name

And then parse these records.

I had written once a small program using these 2 functions to
get the 'localized' font names.

My program reports something like

Name-rec 0: type 0, (c) Copyright ZHONGYI Electronic Co. 1995
Name-rec 1: type 1, SimSun
Name-rec 2: type 2, Regular
Name-rec 3: type 3, SimSun
Name-rec 4: type 4, SimSun
Name-rec 5: type 5, Version 3.03
Name-rec 6: type 6, SimSun
Name-rec 7: type 7, Trademark of ZHONGYI Electronic Co., Beijing
Name-rec 8: type 0 for PEL 3, 1, 1033 82 bytes
Name-rec 9: type 1 for PEL 3, 1, 1033 12 bytes
Bytes:  0 53  0 69  0 6d  0 53  0 75  0 6e

I have attached it so you can play with it if you wish.

Henk Jan




thanks
aniruddhaFT_Get_Sfnt_Name




___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype




#include stdio.h
#include stdlib.h
#include ctype.h

#include ft2build.h
#include FT_FREETYPE_H
#include FT_SFNT_NAMES_H 


/* see FreeType ttnameid.h for values */
#define TT_NAME_ID_COPYRIGHT0
#define TT_NAME_ID_FONT_FAMILY  1
#define TT_NAME_ID_FONT_SUBFAMILY   2
#define TT_NAME_ID_UNIQUE_ID3
#define TT_NAME_ID_FULL_NAME4
#define TT_NAME_ID_VERSION_STRING   5
#define TT_NAME_ID_PS_NAME  6
#define TT_NAME_ID_TRADEMARK7



void dumpFace( 
   FT_Face  face
)
{
   FT_UInt cnt, i, j;

   fprintf(stdout, Family: %s\n\n, face-family_name); 

   cnt = FT_Get_Sfnt_Name_Count(face);
   fprintf(stdout, Number of names: %d\n, cnt);
   for( i=0; i  cnt; i++)
   {
  FT_SfntName  fontname;

  if ( FT_Get_Sfnt_Name(face, i, fontname) == 0 )
  {
 if ( fontname.platform_id == 1 
  fontname.encoding_id == 0 
  fontname.language_id == 0 )
 {
char szBuf[255];
int  iLen = (int)fontname.string_len;
if ( iLen  (sizeof(szBuf) - 1) )
iLen = sizeof(szBuf) - 1;
memcpy(szBuf, (char *)fontname.string, iLen);
szBuf[iLen] = '\0';  

fprintf(stdout, Name-rec %u: type %u, %s\n, i,
fontname.name_id, szBuf);   
 }
 else 
 {
int skip_bytes;

skip_bytes = 0;
/* 0 copyright, 2 sub-family, 5 version, 6 ps name, 7 trademark */
if ( fontname.name_id != 1 ) 
{
   skip_bytes = 1;
}
fprintf(stdout, 
  Name-rec %u: type %u for PEL %u, %u, %u %u bytes\n, 
   i, fontname.name_id, fontname.platform_id,
   fontname.encoding_id, fontname.language_id,
   fontname.string_len );
if ( !skip_bytes )
{
   int ascii = 0;
   fprintf(stdout, Bytes: );
   for (j=0; j  fontname.string_len; j++)
   {
  fprintf(stdout, %2x , fontname.string[j]);
  if ( isascii(fontname.string[j]) )
 ascii++;
   }
   fprintf(stdout, \n);
   if ( ascii == fontname.string_len )
   {
  char szTmp[255];
  if (ascii = (sizeof(szTmp)) )
 ascii = sizeof(szTmp) - 1;
  memcpy(szTmp, fontname.string, ascii);
  szTmp[ascii] = '\0';
  fprintf(stdout, (In Ascii: %s), szTmp);
   }
}
 }
  }
  else
 fprintf(stdout, Error getting fontname %d\n, i);
   }
   fprintf(stdout, \n);
}



int main( int argc, char *argv[] )
{
   FT_Library   FTlib;
   FT_Face  FTface;
   int  i, iFaces;

   if ( argc  2 )
   {
  printf(\nUsage: fontcheck file\n);
  return EXIT_FAILURE;
   }
   
   FT_Init_FreeType(FTlib);

   if ( FT_New_Face(FTlib, argv[1], 0, FTface) == 0 )
   {
  iFaces = FTface-num_faces;
  fprintf(stdout, Processing font %s - %d faces found\n\n, argv[1],
  iFaces);
  dumpFace(FTface);
  FT_Done_Face(FTface); 
  for(i=1; i  iFaces; i++)
  {
 FT_New_Face(FTlib, argv[1], i, FTface);
 dumpFace(FTface);
 FT_Done_Face(FTface);
  }
   }
   else
  fprintf(stdout, Error: %s is not a correct font\n, argv[1]);

   FT_Done_FreeType(FTlib);
}
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype


Re: [ft] Get copyright information from ttf file

2010-11-12 Thread suzuki toshiya
Hi,

TrueType/OpenType has the entries to hold copyright, license,
manufacture, designers etc. Please find the ID of the strings
in the name subtable in
http://www.microsoft.com/typography/otspec/name.htm

And, FreeType2 has a feature to get the strings in the name
subtable by the ID:
http://www.freetype.org/freetype2/docs/reference/ft2-sfnt_names.html#FT_Get_Sfnt_Name

And, if you want to see a source showing how to do,
please check the source of ftdump source in ft2demos.

--

However, there is the problem that the font vendors do not
utilize them seriously. Please find a discussion about the
request fontconfig should cache such informations in its
database file? at:
https://bugs.freedesktop.org/show_bug.cgi?id=18340

Regards,
mpsuzuki

Aniruddha Apte wrote:
 Hello,
 
 Is there any api in FreeType2 that returns copyright, author, legal,
 license, and similar other information present in the .ttf file?
 
 thanks
 aniruddha
 
 
 
 
 
 ___
 Freetype mailing list
 Freetype@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/freetype


___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype


Re: [ft] Freetype license query

2010-11-12 Thread Glenn Pierce
Hi sent the follow to the free software foundation

I have an LGPL library (Version 3) in which I would like to use
Freetype.  Can I link to freetype and still distribute my library as
a binary?

 I asked on the freetype mailing list and was directed here so it would
 be good to get a definitive answer.
 Your website says GPL and Freetype licenses are compatible but does
 not mention the LGPL.

I received the following reply.

Given that the LGPLv3 is essentially an extra set of permissions on top
of the GPLv3, then if a license is compatible with the GPLv3, it is also
compatible with the LGPLv3.

 Is this true just for dynamic linking or statically as well ?

It is true of both dynamic and static linking.


As the Freetype license is on the fsf website as being compatibale with the GPL
I guess it is also compatible with the LGPL.

Thanks

___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype


Re: [ft-devel] cubic clean up

2010-11-12 Thread Werner LEMBERG

 Shaded areas Before and After in the attached figures show where
 control points have should be to permit flattening.  Is this a risky
 change?  If anything, it is slightly more conservative, yet the
 conditional is quite a bit simpler.

Uh, oh, I have no idea what you are talking about.  Please provide
more context, especially the formulae you are referring to.  It would
also help if you use lines to connect the control points in the image.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


RE: [ft-devel] cubic clean up

2010-11-12 Thread David Bevan

Aleksei,

If you relax the condition, you increase the number of splits. Normally, making 
such a change is a mistake because the benefit of simplifying the condition is 
easily outweighed by the greater cost of increasing the recursive depth. This 
is the very reason why we ended up with a much more complex set of conditions 
than in earlier version of FT: it reduces the number of splits very 
significantly.

I've just had a brief chance to look at your proposal, and I now understand why 
it makes no difference to the output. The chances of your relaxed condition 
causing a split when the current (theoretically correct) condition doesn't is 
very small: a control point would have to be in the small white areas in the 
bottom corners of the rectangle in your diagram. Note that this check is only 
made after subdivisions for the distance from the chord. Since this is the most 
expensive test, it is done last, and normally only once.

Since there is no performance improvement, I don't believe that your proposal 
should be included in the code. It would make the code more opaque: It is 
obvious why the current code [if P1 or P2 is outside P0-P3, split the curve] 
does what it does (especially if reference is made to Hain's paper); it would 
not be at all clear why your condition for splitting [if P1 or P2 is far from 
the center of P0-P3, split the curve] was there.

If you do come up with an improvement to the algorithm that is significantly 
faster (and still provably correct), then by all means submit it for review 
(but don't expect a quick or uncritical response).

Thanks.

David %^


-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org 
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of 
??? ?
Sent: 11 November 2010 20:23
To: GRAHAM ASHER
Cc: freetype-devel
Subject: Re: [ft-devel] cubic clean up

Shaded areas Before and After in the attached figures show
where control points have should be to permit flattening.
Is this a risky change? If anything, it is slightly more conservative,
yet the conditional is quite a bit simpler.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] cubic clean up

2010-11-12 Thread Алексей Подтележников
I am really annoyed by run-arounds and overzealous protection of code
by authors.

I was proposing a minor benign improvement. I am touching the water so to
speak. What's the big deal? Way to attract developers, freetypers! You go!

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] cubic clean up

2010-11-12 Thread Алексей Подтележников
I think I can get though to this guy...

2010/11/12 David Bevan david.be...@pb.com:

 I've just had a brief chance to look at your proposal, and I now understand 
 why it makes no difference to the output. The chances of your relaxed 
 condition causing a split when the current (theoretically correct) condition 
 doesn't is very small: a control point would have to be in the small white 
 areas in the bottom corners of the rectangle in your diagram. Note that this 
 check is only made after subdivisions for the distance from the chord. Since 
 this is the most expensive test, it is done last, and normally only once.

Think about it a little more. Imagine a long chord of a dozen pixels.
Those white areas are vanishing.
Now think about a short chord of a pixel and a half.
Those areas are large. However, do you really want to flatten a
curve which pitches orthogonally? Think about it.

 Since there is no performance improvement, I don't believe that your proposal 
 should be included in the code. It would make the code more opaque: It is 
 obvious why the current code [if P1 or P2 is outside P0-P3, split the curve] 
 does what it does (especially if reference is made to Hain's paper); it would 
 not be at all clear why your condition for splitting [if P1 or P2 is far from 
 the center of P0-P3, split the curve] was there.

Let's face it. It's only you and me who understand these conditions.
You were able to understand my code. Let's drop the opaque argument.
I changed the comment for a reason. We can improve it more.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] cubic clean up

2010-11-12 Thread GRAHAM ASHER
Aleksei,

you really shouldn't be annoyed. My earlier patch was shown to be inferior to 
David Bevan's, and I was obliged to accept the fact. The only possible criteria 
are objective ones: does it work? is it faster? is it simpler? I believe David 
has shown using objective arguments that the patch should not be included. 
That's not a run-around. It is a courteous consideration of your suggestion, 
and 
you should be grateful for it.

Also, you don't help your case at all by remarks like I think I can get though 
to this guy... and It's only you and me who understand these conditions. 
which are at best patronising and at worst impolite.

Best regards,

Graham




- Original Message 
From: Алексей Подтележников apodt...@gmail.com
To: freetype-devel freetype-devel@nongnu.org
Sent: Friday, 12 November, 2010 12:16:14
Subject: Re: [ft-devel] cubic clean up

I am really annoyed by run-arounds and overzealous protection of code
by authors.

I was proposing a minor benign improvement. I am touching the water so to
speak. What's the big deal? Way to attract developers, freetypers! You go!

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] cubic clean up

2010-11-12 Thread Алексей Подтележников
All,

If you at least admitted that my patch would produce a better code...
If you at least admitted that my patch is interesting...
I would gladly provide more explanation.
Instead, I hear should not be applied for some bogus reasons,
actually just one reason I do not understand it.

Now you are pulling the politeness argument... Please stop.

Alexei


2010/11/12 GRAHAM ASHER graham.as...@btinternet.com:
 Aleksei,

 you really shouldn't be annoyed. My earlier patch was shown to be inferior to
 David Bevan's, and I was obliged to accept the fact. The only possible 
 criteria
 are objective ones: does it work? is it faster? is it simpler? I believe David
 has shown using objective arguments that the patch should not be included.
 That's not a run-around. It is a courteous consideration of your suggestion, 
 and
 you should be grateful for it.

 Also, you don't help your case at all by remarks like I think I can get 
 though
 to this guy... and It's only you and me who understand these conditions.
 which are at best patronising and at worst impolite.

 Best regards,

 Graham




 - Original Message 
 From: Алексей Подтележников apodt...@gmail.com
 To: freetype-devel freetype-devel@nongnu.org
 Sent: Friday, 12 November, 2010 12:16:14
 Subject: Re: [ft-devel] cubic clean up

 I am really annoyed by run-arounds and overzealous protection of code
 by authors.

 I was proposing a minor benign improvement. I am touching the water so to
 speak. What's the big deal? Way to attract developers, freetypers! You go!

 ___
 Freetype-devel mailing list
 Freetype-devel@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/freetype-devel





-- 
Alexei A. Podtelezhnikov, PhD

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] cubic clean up

2010-11-12 Thread Behdad Esfahbod
On 11/12/10 07:56, Алексей Подтележников wrote:
 Let's face it. It's only you and me who understand these conditions.

Not really.  The rest of us just don't care.  Because it's just a Bezier
flattener after all...

No personal attacks on this list.  We're grown ups.

behdad

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] Re: About Gsub table in opentype.

2010-11-12 Thread Behdad Esfahbod
[+harfbuzz list, Kenichi Handa]

On 11/06/10 05:22, mpsuz...@hiroshima-u.ac.jp wrote:
 Hi,
 
 To parse OpenType tables at low level and
 obtain the substituted glyph index, libotf
 might be useful.
 
   http://www.m17n.org/libotf/

Interesting.  I had totally forgotten about libotf.  I hope now that new
harfbuzz is in a usable state Kenichi abandons the libotf and helps with 
harfbuzz.

behdad


 It does not provide the database of the
 tags of script, language and features, and
 no dependency/conflict checker of each
 features. So libotf client programmer have
 to read OpenType spec and choose appropriate
 script/language/feature to apply to the serie
 of the glyph index.
 
 Regards,
 mpsuzuki
 
 On Sat, 06 Nov 2010 09:50:28 +0100 (CET)
 Werner LEMBERG w...@gnu.org wrote:
 

 do you know any other small open source library can do this job?

 No.

 i just want to display the vertical characters, the layout engine is
 to big for me.

 Then load the GSUB table with FT_Load_Sfnt_Table and parse the data by
 yourself.  This is rather straightforward.


Werner

 ___
 Freetype-devel mailing list
 Freetype-devel@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/freetype-devel
 
 ___
 Freetype-devel mailing list
 Freetype-devel@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/freetype-devel
 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel