tree 4d437c886847abee0823dc17fb99f0ce0dae21a7
parent 9a040ad082dcebf326f23c4cf597bd73a95fbc7d
author Tom Sepez <tsepez@chromium.org> 1625175342 +0000
committer Pdfium LUCI CQ <pdfium-scoped@luci-project-accounts.iam.gserviceaccount.com> 1625175342 +0000

Fix enum type mismatch in CPDF_FontEncoding.

Apart from PDFFONT_ENCODING_BUILTIN and FT_ENCODING_NONE, none of
the PDFFONT_* definitions and FT_Encoding definitions have equivalent
values. Since we pass these around as ints, it is easy to mix them up
without compile-time detection. Once we re-write the FT_ functions to
take FT_Encoding enums, a couple of problems crop up:

CPDF_Type1Font.cpp:213 (and 275) are calling with the wrong enum, but
CPDF_FontEncoding.cpp:1810 handles a mismatched enum, but the
mismatched enum is not the one being passed by any of the mismatched
callers. The result is those calls always get back a 0.

So we are left to guess intent. The FT_ENCODING_ADOBE_STANDARD enum
matches against our StandardEncoding table, so perhaps that was the
intent when passing the mismatched PDFFONT_ENCODING_STANDARD value.
Alternatively, maybe the intent was to match against the odd
PDFFONT_ENCODING_PDFDOC case in the switch. Or it may just be that
getting 0 and removing dead code is the best option.

This CL tries the first option to see how it affects rendering,
since it the most uptight about type safety, and we remove the
mismatched case from the switch.

Change-Id: I08cf85a8adf1ddabc6c2aa4484972b262af7ee49
Reviewed-on: https://pdfium-review.googlesource.com/c/pdfium/+/80610
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>