diff options
author | Michael Stahl <mstahl@redhat.com> | 2015-01-27 00:20:58 +0100 |
---|---|---|
committer | Caolán McNamara <caolanm@redhat.com> | 2015-01-30 12:28:04 +0000 |
commit | a548059718082f9a0823645e92246c98e5d07c24 (patch) | |
tree | 22c58f7b7a62cde63a576041190c99d209f24298 /connectivity | |
parent | 9565480cc6b58e22db762a8cad69e210e38d0a7c (diff) |
rhbz#1177022: vcl: fix PDF embedding of Type 1 fonts
Problem is that for the "CM Typewriter" font the Width for "space" (32)
is exported as 0 instead of 525, which is the correct value in the AFM.
The reason is that PDFWriterImpl::emitEmbeddedFont() has various arrays
to map from font code points to Unicode code points, and there are
duplicate mappings, so the 160->32 mapping overrides 32->32.
The PrintFontManager::PrintFont::readAfmMetrics() actually creates a
Unicode to font code mapping (which may legitimately be n:1) that is
then inverted; add an additional hack to store a set of "preferred"
Unicodes so that PDFWriterImpl can pick the right Unicode.
Presumably the code that is stored explicitly via "C" or "CH" in the
AFM should take priority over more generic mappings.
(cherry picked from commit 5183910a90e97cafc3cfaaad40acdaec0b792f6d)
Conflicts:
vcl/inc/cairotextrender.hxx
vcl/inc/textrender.hxx
vcl/inc/unx/salgdi.h
vcl/source/gdi/pdfwriter_impl.cxx
Change-Id: Id4205a1cd45ba6a0a5facee1e39f70c3535e7dd4
Reviewed-on: https://gerrit.libreoffice.org/14205
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Diffstat (limited to 'connectivity')
0 files changed, 0 insertions, 0 deletions