You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bad interaction between kerning and non-latin1 characters in pdf output #18282
This bisects to #14940, before which kerning was reduced by a factor of 64 and thus the effect would have been still present but unnoticeable except for extreeeemely long strings.
My analysis of the bug is as follows:
First, note that for Type3 output (the default), non-latin1 characters are written to the pdf file separately from the rest of the string. I believe(?) that's a fundamental limitation of the pdf spec (see pdf spec. section 9.4.3 Text Showing Operators). (We could generate a custom encoding to only cover the glyphs we want, and split the font into multiple independent Type3 subsets if the string has more than 255 different glyphs, I guess...) So we measure the widths of the latin1 substrings (using standard kerning) and position the other glyphs relative to these.
However, when subsetting the font as a Type3 font (the default), kerning information is lost. Therefore, the pdf software (okular/etc.) draws the string "AVAVAVAVA" without kerning; in this case it is much wider than expected by Matplotlib and overflows the position where the € sign is drawn.
I believe the solutions are either to
Add an unkerned mode to _text_layout.layout and use that to measure the width of the latin1 substrings in this specific case. This isn't really worse than pre-Fix text kerning calculations and some FT2Font cleanup #14940, where we effectively never kerned.
Use the showkern (TJ) operator instead of show (Tj) to include the kerning values in the outputted string in the pdf file (we already do this for usetex+pdf, in fact). I guess this is technically more correct.
Sure, that sounds like another solution, but that may perhaps (?) break text selection (in the pdf) across all such boundaries? (which may be more frequent than latin1/nonlatin1 boundaries)
Activity
QuLogic commentedon Aug 19, 2020
We could also have the single/multibyte splitter only append to the last text item in
singlebyte_chunksif there's no kerning?anntzer commentedon Aug 19, 2020
Sure, that sounds like another solution, but that may perhaps (?) break text selection (in the pdf) across all such boundaries? (which may be more frequent than latin1/nonlatin1 boundaries)