[reportlab-users] Incorrect character composition

[Marius Gedminas]

On Fri, Apr 17, 2015 at 03:22:34PM +0100, Robin Becker wrote:
> Who is responsible for glyph positioning. I believe it is the font + the
> renderer who is responsible.

I think so too.

> I wrote the  script below to test various diacritic behaviours in reportlab.
...
> The TLDR is as follows, the TTF fonts seem to know about diacritics. The
> adobe builtins may or may not know about them, but with our standard
> encoding Helvetica clearly doesn't.
> 
> The script draws space + glyph + diacritic for some upper and lower case
> roman letters. It also draws the same after unicode normalization.
> 
> Where seen, all the diacritics have zero width. The DejaVuSans font seems to
> do slightly better than Arial in centring the common diacritics, where
> available the composed glyphs (obtained by normalization) seem much better.
> 
> With no width for centring it would seem we need to examine the curves to
> get any kind of centring right.

The font should have the positioning information in the GPOS table:
https://www.microsoft.com/typography/otspec/gpos.htm

I would hope that PDF renderers will take care to apply the position
adjustments, so the PDF generator doesn't have to emit any extra
positioning commands.

The problem is that ReportLab doesn't embed the font directly.  Instead
it constructs multiple subsets (each with < 256 codepoints), and those
subsets constructed by ReportLab do not have GPOS information (check the
TTFontFile.makeSubset method to see what TTF tables are copied and how
they're transformed; my apologies about the terrible code you'll find
therein).

The GPOS table cannot be copied directly: subsetting changes glyph
numbering, so the GPOS table would have to be taken apart and
reconstructed with the renumbered glyphs.

> Otherwise, generating a missing combined glyph dynamically is probably the
> way to go, but to do that we need information about how each combining
> character is supposed to be positioned. The alternative is to attempt to do
> the adjustment every time we render text using pdf operators; we still need
> the same information.

I hope the issue can be solved in a simpler way.

Marius Gedminas
-- 
The memory management on the PowerPC can be used to frighten small children.
                -- Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: Digital signature
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20150417/f336580d/attachment.pgp>