New issue
Advanced search Search tips
Starred by 6 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 19
Cc:



Sign in to add a comment

pdfium uses private freetype API (pstables.h)

Project Member Reported by phajdan.jr@chromium.org, May 24 2017 Back to list

Issue description

When trying to build pdfium with system freetype, I encountered the following error:

FAILED: obj/third_party/pdfium/fxge/fx_freetype.o
x86_64-pc-linux-gnu-g++ -MMD -MF obj/third_party/pdfium/fxge/fx_freetype.o.d -DDEFINE_PS_TABLES -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DDISABLE_NACL -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_DEPRECATION_WARNINGS -D_FX_CPU_=_FX_X64_ -DOPJ_STATIC -DPNG_PREFIX -DPNG_USE_READ_MACROS -DPDF_ENABLE_V8 -DPDFIUM_PRINT_TEXT_WITH_GDI -I../.. -Igen -I../../third_party/pdfium -Igen/shim_headers/freetype_shim -I/usr/include/freetype2 -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -m64 -march=x86-64 -pthread -Wall -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -fomit-frame-pointer -g0 -fvisibility=hidden -fPIC -std=gnu++11 -Wno-narrowing -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -O2 -pipe -march=native -fno-delete-null-pointer-checks -c ../../third_party/pdfium/core/fxge/freetype/fx_freetype.cpp -o obj/third_party/pdfium/fxge/fx_freetype.o
../../third_party/pdfium/core/fxge/freetype/fx_freetype.cpp:9:59: fatal error: third_party/freetype/src/src/psnames/pstables.h: No such file or directory
 #include "third_party/freetype/src/src/psnames/pstables.h"
                                                           ^
compilation terminated.

pstables.h is not installed by system freetype packages, which would suggest it's not part of public API.

While obviously not strictly required for pdfium/chromium, please consider restructuring the code (or working with upstream) so that it doesn't need to use non-public APIs.

Let me know if/how I could help with that.
 
Project Member

Comment 1 by thestig@chromium.org, May 25 2017

Cc: npm@chromium.org drott@chromium.org
Status: Accepted
Project Member

Comment 2 by npm@chromium.org, May 25 2017

Isn't this a problem with the include too? The path being used makes sense for chromium/pdfium freetype but not for the system one. Also, could you describe your gn args or whatever you're doing to crash the compiler? I couldn't figure it out.
"third_party" in includes isn't a big deal. We handle that using shim headers - see https://cs.chromium.org/chromium/src/build/linux/unbundle/README and http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon%202014%20Slides_0.pdf (slides 20-22).

To repro you'd need to delete bundled freetype and replace the GN file. Not sure if the following will work, but it's based on my command history:

find third_party/freetype -type f \! -iname '*.gn' \! -ipath '*.git*' -delete
build/linux/unbundle/replace_gn_files.py --system-libraries freetype

Bottom line is, see what headers system ffmpeg installs, and make sure to only use these headers (or work towards freetype exposing needed functionality as part of its public API).

Let me know if you have further questions.
Project Member

Comment 4 by drott@chromium.org, May 30 2017

Cc: w...@gnu.org
I think Werner (the very helpful FreeType maintainer) is at least aware of the fact that PDFium uses the ft_adobe_glyph_list and lookup struct and the ft_get_adobe_glyph_index of pstables, if I am not mistaken. 

Perhaps this could indeed be made part of public API so that building against system FreeType works for Chromium unbundled. Are there any objections, Werner? Should we file a bug on http://savannah.nongnu.org/bugs/?group=freetype ?
No, I wasn't aware of this.

And yes, it could be made a public API.  Please open a report (and tag it as `wishlist').

If possible, please provide a patch also :-)  You could use, say, `FT_Get_Multi_Master' as a template to call the `postscript-cmaps' service.

Project Member

Comment 6 by drott@chromium.org, May 30 2017

Cc: -w...@gnu.org lemzw...@googlemail.com
Project Member

Comment 7 by thestig@chromium.org, May 30 2017

drott: Would you mind filing the bug since you are probably more familiar with the FT bug reporting process?
Sorry, no time currently.  In particular, I don't have time to analyze the pdfium code to find out what *really* is needed.
Project Member

Comment 9 by drott@chromium.org, Jun 1 2017

Status: ExternalDependency
Filed as https://savannah.nongnu.org/bugs/index.php?51156
Project Member

Comment 10 by drott@chromium.org, Jun 1 2017

Owner: npm@chromium.org
Could you follow up on this, Nicolás, if there are updates in FreeType? May I assign this to you? Thanks.

Comment 11 by wbr...@gmail.com, Jun 30 2017

stable channel 59.0.3071.115 is also affected

Comment 12 by apodt...@gmail.com, Aug 30 2017

FreeType provides a pair:

FT_Get_Name_Index
FT_Get_Glyph_Name

Why is this not sufficient? 
Project Member

Comment 13 by drott@chromium.org, Aug 31 2017

Thanks for taking a look. 

I commented on https://savannah.nongnu.org/bugs/index.php?51156 - in short: FT_Get_Name_Index and FT_Get_Glyph_Name perform glyph ID to glyph name lookups/reverse lookups for a specific font. What PDFium requires is access to FreeType's optimized Adobe Glyph List dictionary, so these API functions are not suitable.

Project Member

Comment 14 by thomasanderson@chromium.org, Dec 15

Cc: thestig@chromium.org
[1] recommends copying pstables.h into pdfium.  The main concern against doing this is that header contains a large table (56KiB) that would bloat the binary.  However, official builds already statically link freetype, so they would be unaffected.  Chromium packagers (who are currently forced to statically link freetype due to this issue) would see a net decrease in binary size.  Seems like a win-win to me.

[1] https://savannah.nongnu.org/bugs/index.php?51156
Project Member

Comment 16 by thestig@chromium.org, Dec 19

Owner: thomasanderson@chromium.org
Status: Fixed

Sign in to add a comment