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
for the cases where we don't want the full result
and mark some ultra-dubious code with a TODO
Change-Id: I7cf57b8d44bbad2a6db86a8b862a757ae5062c50
Reviewed-on: https://gerrit.libreoffice.org/14189
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
With this patch I get the text boundary and use it to reduce the size
of the surface to this area. However, this is mainly needed for
OpenGLX11CairoTextRender, which creates a surface image and uses this
for OpenGL rendering.
Change-Id: Icffc19bed89aaa2ff84ae845d274258a6fca27da
Turns out it might be easier to actually subclass only the various SalLayout's
- let's try it first, and re-introduce this code again if not.
This reverts commit 309257ddadfdc3e46506036ed81f6e0695211ebe.
