summaryrefslogtreecommitdiff
path: root/core/fxge/fontdata/chromefontdata
diff options
context:
space:
mode:
authorTom Sepez <tsepez@chromium.org>2018-08-08 17:49:02 +0000
committerChromium commit bot <commit-bot@chromium.org>2018-08-08 17:49:02 +0000
commit34dab07ed6e826666fd0589069f2c9b5bd2ba4dc (patch)
tree0eb30bd1c76f54890a6d365258a7157ae9972748 /core/fxge/fontdata/chromefontdata
parent6d9897b103aef10b369eb999a40c22011a8ae4f5 (diff)
downloadpdfium-34dab07ed6e826666fd0589069f2c9b5bd2ba4dc.tar.xz
Move ByteString::FromUnicode() to WideString::ToDefANSI()
Turns out that "FromUnicode" is misleading in that, on linux, it simply removes any characters beyond 0xFF and passes the rest unchanged, so no unicode decoding actually takes place. On Windows, it passes it into the system function specifying FX_CODEPAGE_DefANSI, converting it into the so-called "default ANSI code plane", passing some characters, converting others to '?' and still others to 'A'. Either way, nothing resembling UTF8 comes out of this, so pick a better name. These now immediately look suspicious, so a follow-up CL will see which ones should really be WideString::UTF8Encode() instead. Making this a normal method on a widestring rather than a static method on a bytestring feels more natural; this is parallel to the UTF8Encode and UTF16LE_Encode functions. Add a test that shows these conversions. Change-Id: Ia7551b47199eba61b5c328a97bfe9176ac8e583c Reviewed-on: https://pdfium-review.googlesource.com/39690 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Tom Sepez <tsepez@chromium.org>
Diffstat (limited to 'core/fxge/fontdata/chromefontdata')
0 files changed, 0 insertions, 0 deletions