You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Alistair Oldfield (Jira)" <ji...@apache.org> on 2021/08/26 17:01:00 UTC

[jira] [Created] (PDFBOX-5267) LegacyPDFStreamEngine.glyphList loaded from disk on each instantiation rather than static final?

Alistair Oldfield created PDFBOX-5267:
-----------------------------------------

             Summary: LegacyPDFStreamEngine.glyphList loaded from disk on each instantiation rather than static final?
                 Key: PDFBOX-5267
                 URL: https://issues.apache.org/jira/browse/PDFBOX-5267
             Project: PDFBox
          Issue Type: Improvement
          Components: Text extraction
    Affects Versions: 2.0.24
            Reporter: Alistair Oldfield


I might be wrong on this one, but I can't seem to see how the private final GlyphList glyphList member of LegacyPDFStreamEngine is ever modified, however each instance of LegacyPDFStreamEngine has its own instance of glyphList .

It is loaded from resources in the constructor on every instantiation, however, is only ever used (passed as an argument) to:

 
{code:java}
String unicodeMapping = font.toUnicode(code, glyphList);
 
{code}
which in turn, I can't seem to see that it is modified.

An application using many instances of LegacyPDFStreamEngine (which may be a common use-case) would load this disk resource each time it is instantiated. Perhaps it can be made a static final?

 

Apologies if I was unable to catch the reason for each instance of this list. If there is a reason to have a separate instance, maybe then its worth considering copying from a static final List in memory rather than reloading the same file over and over?...

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org