bugThe FreeType Project - Bugs: bug #51156, Expose pstables.h...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #51156: Expose pstables.h ft_adobe_glyph_list and ft_get_adobe_glyph_index as public API

Submitter:  Dominik Röttsches <drott>
Submitted:  Thu 01 Jun 2017 10:41:53 AM UTC
   
 
Severity:  3 - Normal Item Group:  Wishlist
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Planned Release:  None

Jump to the original submission

Thu 31 Aug 2017 03:16:02 PM UTC, comment #7: 

FreeType already generates a missing Unicode cmap for Type1 and CFF and makes it active. CIDs do not have names, do they? We'll do it for TrueType in the next release as well. The default active face->charmap is always Unicode or NULL. Other face->charmaps can only be activated manually, see FT_Set_Charmap.

You've already copied some code. Why stop there? Compare:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/psnames/psmodule.c#n63
https://cs.chromium.org/chromium/src/third_party/pdfium/core/fxge/freetype/fx_freetype.cpp?l=56

I am just asking for a more careful analysis of actual needs.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 31 Aug 2017 02:17:58 PM UTC, comment #6: 


> In the next release we'll generate a Unicode map for subsetted fonts with names. There is good interface out there already.


Thanks, this might be helpful. I see your commit http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=75cb071b3fbfa2315c5d458fee2bb465a14568ae

Would you have additional information on how this API is used, perhaps in the form of a short snippet or pseudocode?

Is my interpretation of the tt_cmap_* prefix correct in a way that this synthesized Unicode CMAP would only be generated for TrueType fonts?

FWIW, looking at the references for PDF_UnicodeFromAdobeName, code search shows [1] that this method is used by PDFium not only for TTF but also for CID and Type1 fonts.

[1] https://cs.chromium.org/chromium/src/third_party/pdfium/core/fpdfapi/font/cpdf_fontencoding.h?sq=package:chromium&l=30

Dominik Röttsches <drott>
Thu 31 Aug 2017 01:55:35 PM UTC, comment #5: 

Keep in mind that FreeType psnames module is optional. We also hate bloat. Basically declaring a huge table public is not an option. In the next release we'll generate a Unicode map for subsetted fonts with names. There is good interface out there already.

What's the PDFium workflow? Glyph name -> Unicode -> then what? Why is the Unicode step even necessary? I suspect that we are discussing a poor design choices in PDFium. Let's discuss PDFium actual needs rather than papering over some issues with a shotgun.

In addition, please do not consider AGL circa 2002 (no kidding!) a good Unicode reference. The concept of glyph names is basically obsolete. It is best to just avoid the conversions.


Alexei Podtelezhnikov <podtelez>
Group Member
Thu 31 Aug 2017 12:48:33 PM UTC, comment #4: 

We are trying hard to avoid unnecessary binary bloat in PDFium as well as ultimately in Chromium, in which PDFium is included, compare issue #49949.

FreeType and PDFium share the requirement of coming up with a mapping back from glyph ids to unicode text. Behind FreeType's public API, this mapping functionality itself is in scope for FreeType, otherwise it would not need pstables.h.

I believe PDFium would be very flexible about the specifics of the interface to the AGL as long as we could avoid copying the AGL data and duplicating this in our binaries.

I agree that this is at the periphery of FreeType's main functionality. But since the AGL structure is anyway necessarily contained in FreeType, clients would profit from not having to copy this structure or coming up with their own representation of it, but instead save a good portion of binary storage by accessing the efficient copy in FreeType directly.

Dominik Röttsches <drott>
Thu 31 Aug 2017 12:19:07 PM UTC, comment #3: 

I think the best approach is to copy the code.

The general unicode<->name conversion if out of FreeType scope. Strictly speaking, it does not bring you any closer to the desired glyph image ultimately accessible by its font index.

FreeType also uses this functionality to build and provide a missing unicode cmap, which is actually useful. The interface that you propose is not useful in general.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 31 Aug 2017 07:54:56 AM UTC, comment #2: 

While I am not familiar with the internals of the PDF or Postscript format, PDFium uses the Adobe Glyph List for a reverse lookup heuristic from glyph IDs in a PDF to map back to a unicode char sequence. See https://github.com/adobe-type-tools/agl-specification

AFAIK, PDFs can have aggressively subsetted fonts, only storing a minimal, sparse glyph set, and may lose any similarity with the CMAPs of the original font used when creating the PDF document.

In PDFium, this is done through FXFT_unicode_from_adobe_name and  FXFT_adobe_name_from_unicode functions in
https://cs.chromium.org/chromium/src/third_party/pdfium/core/fxge/freetype/fx_freetype.cpp?sq=package:chromium&l=56

These lookup functions make use of FreeType's ft_adobe_glyph_list structure, as well as the ft_get_adobe_glyph_index lookup function from pstables.h.

By contrast, FT_Get_Name_Index retrieves a glyph ID for a glyph name for a specific font, FT_Get_Glyph_Name performs a glyph id lookup given a glyph name. However, neither of these functions attempt to map back to a unicode codepoint sequence. That's why they are not suitable for this specific mapping purpose in PDFium.

PDFium would benefit if the optimized Adobe Glyph List information that FreeType stores would be externally available.

Thanks in advance if there would be any volunteer considering to expose such an API.

Dominik Röttsches <drott>
Wed 30 Aug 2017 08:18:04 PM UTC, comment #1: 

We have a pair:

FT_Get_Name_Index
FT_Get_Glyph_Name

Why is this not sufficient?

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 01 Jun 2017 10:41:53 AM UTC, original submission:  

Chrome generally builds with its own version of FreeType. But there is a Chromium unbundled compilation mode used by certain distributions to build their own Chromium, which build against the host system's FreeType version.

Builds in these cases may fail, because PDFium inside Chromium accesses private API of FreeType's pstables.h.

We're filing this bug to request public API for accessing the

  • ft_adobe_glyph_list optimized array/table-lookup structure as well as
  • the ft_get_adobe_glyph_index lookup function.


This would help for the unbundled build of Chromium, as well as generally cleaning up PDFium's usage of FreeType API.


Dominik Röttsches <drott>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by drott (Submitted the item)
  • -email is unavailable- added by drott
  • -email is unavailable- added by drott
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-06-01 drott Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code