summaryrefslogtreecommitdiff
path: root/vcl/inc/salgdi.hxx
diff options
context:
space:
mode:
authorMichael Stahl <mstahl@redhat.com>2015-01-27 00:20:58 +0100
committerMichael Stahl <mstahl@redhat.com>2015-01-27 14:42:13 +0100
commit5183910a90e97cafc3cfaaad40acdaec0b792f6d (patch)
tree659334063e885f5348e692faf7e8774ec67b080e /vcl/inc/salgdi.hxx
parentad3e0989d137ef765d634cb07a7a7a46ecc774ff (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. Change-Id: Id4205a1cd45ba6a0a5facee1e39f70c3535e7dd4
Diffstat (limited to 'vcl/inc/salgdi.hxx')
-rw-r--r--vcl/inc/salgdi.hxx4
1 files changed, 3 insertions, 1 deletions
diff --git a/vcl/inc/salgdi.hxx b/vcl/inc/salgdi.hxx
index b42e0b4a2ea1..6e5e80079296 100644
--- a/vcl/inc/salgdi.hxx
+++ b/vcl/inc/salgdi.hxx
@@ -34,6 +34,7 @@
#include "sallayout.hxx"
#include <map>
+#include <set>
class PhysicalFontCollection;
class SalBitmap;
@@ -188,7 +189,8 @@ public:
// as encoding for these cases
virtual const Ucs2SIntMap* GetFontEncodingVector(
const PhysicalFontFace*,
- const Ucs2OStrMap** ppNonEncoded ) = 0;
+ const Ucs2OStrMap** ppNonEncoded,
+ std::set<sal_Unicode> const** ppPriority) = 0;
// GetEmbedFontData: gets the font data for a font marked
// embeddable by GetDevFontList or NULL in case of error