When building PDF documents with OpenType fonts in iText, I want to access glyph variants from within the font -- specifically tabular figures. Since OpenType glyph variants do not have Unicode indices, I am not sure how to either specify that I want to use a particular set of variants (tabular figures) or call a specific glyph by its glyph ID. Just looking for the relevant iText class name if one exists.
相关问题
- Delete Messages from a Topic in Apache Kafka
- Jackson Deserialization not calling deserialize on
- How to maintain order of key-value in DataFrame sa
- StackExchange API - Deserialize Date in JSON Respo
- Difference between Types.INTEGER and Types.NULL in
This does not seem to be possible neither in the latest tag 5.5.8, nor in the master branch of iText.
As explained in this article and in the Microsoft's OpenType font file specification, glyph variants are stored in the
Glyph Substitution Table (GSUB)
of a font file. Accessing the glyph variants requires reading this table from the file, which is actually implemented in the classcom.itextpdf.text.pdf.fonts.otf.GlyphSubstitutionTableReader
, though this class is disabled for now.The call
readGsubTable()
in the classcom.itextpdf.text.pdf.TrueTypeFontUnicode
is commented out.It turns out that this line is disabled for a reason, as the code actually does not work if you try to activate it.
So, unfortunately, there is no way to use glyph variants, as the substitution information is never loaded from the font file.
Update
The original answer was about possibility to use
iText API
for accessing glyph variants out of the box, which is not there yet. However, the low level code is in place and can be used after some hacking to access the glyph substitution mapping table.When called
read()
, theGlyphSubstitutionTableReader
reads theGSUB
table and flattens substitutions of all features into one mapMap<Integer, List<Integer>> rawLigatureSubstitutionMap
. The symbolic names of the features are currently discarded byOpenTypeFontTableReader
. TherawLigatureSubstitutionMap
maps aglyphId
variant to a baseglyphId
, or a ligatureglyphId
to a sequence ofglyphIds
like this:This mapping can be reversed to get all variants for a base
glyphId
. So all extended glyphs with unknown unicode values can be figured out through their connection to a base glyph, or a sequence of glyphs.Next, to be able to write a glyph to PDF, we need to know a unicode value for that
glyphId
. A relationshipunicode -> glyphId
is mapped by acmap31
field inTrueTypeFont
. Reversing the map gives unicode by glyphId.Tweaking
rawLigatureSubstitutionMap
cannot be accessed inGlyphSubstitutionTableReader
, as it's aprivate
member and does not have a getter accessor. The simplest hack would be to copy-paste the original class and add a getter for the map:Next problem is that
GlyphSubstitutionTableReader
needs an offset forGSUB
table, information that is stored inprotected HashMap<String, int[]> tables
ofTrueTypeFont
class. A helper class placed into same package will bridge access to the protected members ofTrueTypeFont
.It would be nicer to extend
TrueTypeFont
, but that would not work with factory methodscreateFont()
ofBaseFont
, which relies on hard coded class names when creating a font.