Use glyph indices for font tracking in vector formats #30335
Conversation
4ca7af0 to
e684f7b
Compare
3d5e48c to
a2db55c
Compare
a2db55c to
2118966
Compare
|
I've decided to restore the character code in the return values from mathtext, because I've found some use for it in PDF output. |
| @@ -2274,7 +2268,7 @@ def draw_tex(self, gc, x, y, s, prop, angle, *, mtext=None): | |||
| seq += [['font', pdfname, dvifont.size]] | |||
| oldfont = dvifont | |||
| seq += [['text', x1, y1, [bytes([glyph])], x1+width]] | |||
| self.file._character_tracker.track(dvifont, chr(glyph)) | |||
| self.file._character_tracker.track_glyph(dvifont, glyph) | |||
There was a problem hiding this comment.
I think you need to use text.index here? (with for text in page.text: x1, y1 dvifont, glyph, width = text; ...) (#29868)
I would even stop unpacking and just use text.x, text.y, etc.
There was a problem hiding this comment.
I think you might mean #29829 here?
There was a problem hiding this comment.
Hmm, it looks like switching to text.index would require a bit more work, as the T1 font subsetter is working with characters too. I guess dbd689f would be the best place for that.
There was a problem hiding this comment.
Indeed, you are correct. However this makes things a bit tricky to follow because this means that track_glyph effectively takes a glyph index as second argument if the font is a non-DVI font, but a charcode if the font is a DVI font, or more specifically, a type 1 font (because the type1 subsetter works with characters, as you mention). Is that correct? I guess that's OK as a temporary state because as you mention dbd689f will resolve that discrepancy, but this probably warrants a comment (that can later be dropped in dbd689f) to avoid puzzling the reader?
(Also, keeping this discrepancy would be problematic in the long term as lua/xelatex support will mean that this loop will also sometimes emit glyphs from TTF fonts, but I believe this will again be made clearer by dbd689f.)
41a5b7d to
df7fa98
Compare
With libraqm, string layout produces glyph indices, not character codes, and font features may even produce different glyphs for the same character code (e.g., by picking a different Stylistic Set). Thus we cannot rely on character codes as unique items within a font, and must move toward glyph indices everywhere.
df7fa98 to
8de7f4e
Compare
PR summary
With libraqm, string layout produces glyph indices, not character codes, and font features may even produce different glyphs for the same character code (e.g., by picking a different Stylistic Set). Thus we cannot rely on character codes as unique items within a font, and must move toward glyph indices everywhere.
The only thing I don't quite like is that PDF uses character codes for its lookup, and I have to map glyph indices back through an inverse charmap. I think I may have to send everything throughBetter stuff for this is done in #30512.CharacterTrackerand produce my own limited charmap, but still need to test out what's required.This is based on #30143.PR checklist