> On 26 Jun 2016, at 11:24, Tilman Hausherr <[email protected]> wrote: > > In PDFStreamEngine.showText there is a call to font.toUnicode(). IMHO this > isn't needed. It is passed to > > showGlyph(textRenderingMatrix, font, code, unicode, w); > > This is used in PDFStreamEngine or PDFTextStreamEngine. > > In PDFStreamEngine, showGlyph looks like this: > > protected void showGlyph(Matrix textRenderingMatrix, PDFont font, int > code, String unicode, > Vector displacement) throws IOException > { > if (font instanceof PDType3Font) > { > showType3Glyph(textRenderingMatrix, (PDType3Font)font, code, > unicode, displacement); > } > else > { > showFontGlyph(textRenderingMatrix, font, code, unicode, > displacement); > } > } > > showType3Glyph doesn't use unicode, neither does showFontGlyph. > > In PDFTextStreamEngine.showGlyph(), unicode is overwritten: > > unicode = font.toUnicode(code, glyphList);
But PDFTextStreamEngine is for legacy compatibility only. All “proper” text processing is now in PDFStreamEngine, which is why Unicode is decoded there. > so it isn't used. I don't see a need to get the unicode at this time. Anybody > who overrides one of the methods mentioned above can still get it later, > because the PDFont is also passed. > > > So my intent is to remove the parameter in the trunk (i.e. for 2.1) in the 4 > methods mentioned. This will make processing very slightly faster and remove > the "WARNING: No Unicode mapping for ... in font ..." messages in rendering > when toUnicode is missing. That would break downstream subclasses of PDFTextStreamEngine. > Tilman > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
