Re: [ft-devel] [Regression] Font doesn't open with Freetype CVS but works with Freetype 2.2.1

2007-05-26 Thread mpsuzuki
Hi,

On Sat, 26 May 2007 02:16:54 +0300
 On Saturday 26 May 2007 02:13:52 Werner LEMBERG wrote:
 
  Hmm, this font doesn't have a `cmap' table, which is invalid according
  to the OpenType standard, and the behaviour is defined as
  `implementation specific' in PDF standard (see section 5.5. in the PDF
  1.6 specification).
 
 I see but lots of real world PDF files have this kind of fonts :-/

I remember, ft-devel list receives several posts per year
saying I found an embedded font in PDF that FT2 cannot
load, FT2 should load it. It's not always stated which
application or library using FT2 to load embedded TrueType
data from PDF.

In my opinion, embedded font in PDF is NOT self-standing
font file. Even if it's forcibly loaded by ignoring essential
tables, it is no more than jumping the first hurdle.
Without cmap, most character-based API are not usable.
One of the next expected hurdle might be we want to
convert glyph index to character code, to extract or
search a text in PDF. FT2 should do... It is impossible.
Such requirement should be supplied by slightly higher
level library which can associate the text object,
embedded font object, CMap object, ToUnicode object.
I think it's far higher than FT2. As a result,
the behaviour of current FT2 is reasonable, I think.

However, if somebody can define the reasonable subset of
FT2 API which is required by most PDF parser, it will be
quite helpful for both of FT2 and PDF-related softwares.
If you have some idea of subsetted API for embedded font,
please let me know.

Regards,
mpsuzuki


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


Re: [ft-devel] [Regression] Font doesn't open with Freetype CVS but works with Freetype 2.2.1

2007-05-26 Thread Albert Astals Cid
A Dissabte 26 Maig 2007, Ismail Dönmez va escriure:
 Hi

 On Saturday 26 May 2007 10:47:40 you wrote:
   On Saturday 26 May 2007 02:13:52 Werner LEMBERG wrote:
Hmm, this font doesn't have a `cmap' table, which is invalid
according to the OpenType standard, and the behaviour is defined as
`implementation specific' in PDF standard (see section 5.5. in the
PDF 1.6 specification).
  
   I see but lots of real world PDF files have this kind of fonts :-/
 
  I remember, ft-devel list receives several posts per year
  saying I found an embedded font in PDF that FT2 cannot
  load, FT2 should load it. It's not always stated which
  application or library using FT2 to load embedded TrueType
  data from PDF.
 
  In my opinion, embedded font in PDF is NOT self-standing
  font file. Even if it's forcibly loaded by ignoring essential
  tables, it is no more than jumping the first hurdle.
  Without cmap, most character-based API are not usable.
  One of the next expected hurdle might be we want to
  convert glyph index to character code, to extract or
  search a text in PDF. FT2 should do... It is impossible.
  Such requirement should be supplied by slightly higher
  level library which can associate the text object,
  embedded font object, CMap object, ToUnicode object.
  I think it's far higher than FT2. As a result,
  the behaviour of current FT2 is reasonable, I think.
 
  However, if somebody can define the reasonable subset of
  FT2 API which is required by most PDF parser, it will be
  quite helpful for both of FT2 and PDF-related softwares.
  If you have some idea of subsetted API for embedded font,
  please let me know.

Not sure what you want from me, you want the freetype functions we use?

We [1] use:
 * FT_Library_Version
 * FT_Init_FreeType
 * FT_Done_FreeType
 * FT_New_Face
 * FT_New_Memory_Face
 * FT_Done_Face
 * FT_Get_Name_Index
 * FT_New_Size
 * FT_Set_Pixel_Sizes
 * FT_Set_Transform
 * FT_Load_Glyph
 * FT_Render_Glyph
 * FT_Get_Glyph
 * FT_Outline_Decompose
 * FT_Done_Glyph

For text handling we don't use FreeType for anything.

Freetype 2.2.1 was able of giving us that functions working i would be happy 
if you could make newer versions work too, even if we have to set a flag 
somewhere specifically renouncing not to use some functions.

Albert

[1] We = kpdf and poppler, that are the same functions used by xpdf at the 
moment, but as i'm not involved in xpdf in any way it's not we


 I am CC'ing one of the KPDF's author Albert Astals Cid who extracted the
 problematic font for me. Maybe he might help us with whats the minimal api
 needed for a PDF viewer.

 Regards,
 ismail




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