[jira] [Updated] (PDFBOX-5727) Font operation takes a long time with 3.0.1
[ https://issues.apache.org/jira/browse/PDFBOX-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-5727: Labels: regression (was: ) > Font operation takes a long time with 3.0.1 > --- > > Key: PDFBOX-5727 > URL: https://issues.apache.org/jira/browse/PDFBOX-5727 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.30, 3.0.1 PDFBox >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: regression > Fix For: 2.0.31, 3.0.2 PDFBox, 4.0.0 > > > Kjetil Ødegaard on the users mailing list reported that the start of PDFBox > takes a long time during font collection and that two .ttc fonts that fail > are tried every time. He produced a stack trace of an exception that is > caught: > {noformat} > java.io.EOFException > at > org.apache.fontbox.ttf.TTFDataStream.readUnsignedShort(TTFDataStream.java:154) > at > org.apache.fontbox.ttf.TTFDataStream.readUnsignedShortArray(TTFDataStream.java:188) > at > org.apache.fontbox.ttf.GlyphSubstitutionTable.readMultipleSubstitutionSubtable(GlyphSubstitutionTable.java:412) > at > org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupSubtable(GlyphSubstitutionTable.java:263) > at > org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupTable(GlyphSubstitutionTable.java:313) > at > org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupList(GlyphSubstitutionTable.java:247) > at > org.apache.fontbox.ttf.GlyphSubstitutionTable.read(GlyphSubstitutionTable.java:102) > at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:365) > at org.apache.fontbox.ttf.TTFParser.parseTables(TTFParser.java:165) > at org.apache.fontbox.ttf.TTFParser.parse(TTFParser.java:144) > at > org.apache.fontbox.ttf.TrueTypeCollection.getFontAtIndex(TrueTypeCollection.java:127) > at > org.apache.fontbox.ttf.TrueTypeCollection.processAllFonts(TrueTypeCollection.java:109) > at > org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeCollection(FileSystemFontProvider.java:665) > at > org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:396) > at > org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:367) > at > org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:139) > at > org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158) > at > org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416) > at > org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:379) > at > org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:353) > at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:127) > {noformat} > I have a theory why it happens, which is that addTrueTypeCollection() does > not add the font as "*skipexception*" to the cache file because it's not done > in the exception handler. > Gili Tzabari suggested to use CRC32 instead of SHA512. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5727) Font operation takes a long time with 3.0.1
[ https://issues.apache.org/jira/browse/PDFBOX-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-5727: Description: Kjetil Ødegaard on the users mailing list reported that the start of PDFBox takes a long time during font collection and that two .ttc fonts that fail are tried every time. He produced a stack trace of an exception that is caught: {noformat} java.io.EOFException at org.apache.fontbox.ttf.TTFDataStream.readUnsignedShort(TTFDataStream.java:154) at org.apache.fontbox.ttf.TTFDataStream.readUnsignedShortArray(TTFDataStream.java:188) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readMultipleSubstitutionSubtable(GlyphSubstitutionTable.java:412) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupSubtable(GlyphSubstitutionTable.java:263) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupTable(GlyphSubstitutionTable.java:313) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupList(GlyphSubstitutionTable.java:247) at org.apache.fontbox.ttf.GlyphSubstitutionTable.read(GlyphSubstitutionTable.java:102) at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:365) at org.apache.fontbox.ttf.TTFParser.parseTables(TTFParser.java:165) at org.apache.fontbox.ttf.TTFParser.parse(TTFParser.java:144) at org.apache.fontbox.ttf.TrueTypeCollection.getFontAtIndex(TrueTypeCollection.java:127) at org.apache.fontbox.ttf.TrueTypeCollection.processAllFonts(TrueTypeCollection.java:109) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeCollection(FileSystemFontProvider.java:665) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:396) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:367) at org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:139) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:379) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:353) at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:127) {noformat} I have a theory why it happens, which is that addTrueTypeCollection() does not add the font as "*skipexception*" to the cache file because it's not done in the exception handler. Gili Tzabari suggested to use CRC32 instead of SHA512. was: Kjetil Ødegaard on the users mailing list reported that the start of PDFBox takes a long time during font collection and that two .ttc fonts that fail are tried every time. He produced a stack trace of an exception that is caught: {noformat} java.io.EOFException at org.apache.fontbox.ttf.TTFDataStream.readUnsignedShort(TTFDataStream.java:154) at org.apache.fontbox.ttf.TTFDataStream.readUnsignedShortArray(TTFDataStream.java:188) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readMultipleSubstitutionSubtable(GlyphSubstitutionTable.java:412) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupSubtable(GlyphSubstitutionTable.java:263) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupTable(GlyphSubstitutionTable.java:313) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupList(GlyphSubstitutionTable.java:247) at org.apache.fontbox.ttf.GlyphSubstitutionTable.read(GlyphSubstitutionTable.java:102) at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:365) at org.apache.fontbox.ttf.TTFParser.parseTables(TTFParser.java:165) at org.apache.fontbox.ttf.TTFParser.parse(TTFParser.java:144) at org.apache.fontbox.ttf.TrueTypeCollection.getFontAtIndex(TrueTypeCollection.java:127) at org.apache.fontbox.ttf.TrueTypeCollection.processAllFonts(TrueTypeCollection.java:109) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeCollection(FileSystemFontProvider.java:665) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:396) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:367) at org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:139) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:379) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:353) at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:127) {noformat} I have a theory why it happens, which is that addTrueTypeCollection() does not add the font as "*skipexception*" to the cache file because it's not done in the exception handler. > Font operation takes a long time with 3.0.1 >
[jira] [Updated] (PDFBOX-5727) Font operation takes a long time with 3.0.1
[ https://issues.apache.org/jira/browse/PDFBOX-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-5727: Description: Kjetil Ødegaard on the users mailing list reported that the start of PDFBox takes a long time during font collection and that two .ttc fonts that fail are tried every time. He produced a stack trace of an exception that is caught: {noformat} java.io.EOFException at org.apache.fontbox.ttf.TTFDataStream.readUnsignedShort(TTFDataStream.java:154) at org.apache.fontbox.ttf.TTFDataStream.readUnsignedShortArray(TTFDataStream.java:188) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readMultipleSubstitutionSubtable(GlyphSubstitutionTable.java:412) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupSubtable(GlyphSubstitutionTable.java:263) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupTable(GlyphSubstitutionTable.java:313) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupList(GlyphSubstitutionTable.java:247) at org.apache.fontbox.ttf.GlyphSubstitutionTable.read(GlyphSubstitutionTable.java:102) at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:365) at org.apache.fontbox.ttf.TTFParser.parseTables(TTFParser.java:165) at org.apache.fontbox.ttf.TTFParser.parse(TTFParser.java:144) at org.apache.fontbox.ttf.TrueTypeCollection.getFontAtIndex(TrueTypeCollection.java:127) at org.apache.fontbox.ttf.TrueTypeCollection.processAllFonts(TrueTypeCollection.java:109) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeCollection(FileSystemFontProvider.java:665) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:396) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:367) at org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:139) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:379) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:353) at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:127) {noformat} I have a theory why it happens, which is that addTrueTypeCollection() does not add the font as "*skipexception*" to the cache file because it's not done in the exception handler. was: Kjetil Ødegaard on the users mailing list reported that the start of PDFBox takes a long time during font collection and that two fonts that fail are tried every time. He produced a stack trace of an exception that is caught: {noformat} java.io.EOFException at org.apache.fontbox.ttf.TTFDataStream.readUnsignedShort(TTFDataStream.java:154) at org.apache.fontbox.ttf.TTFDataStream.readUnsignedShortArray(TTFDataStream.java:188) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readMultipleSubstitutionSubtable(GlyphSubstitutionTable.java:412) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupSubtable(GlyphSubstitutionTable.java:263) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupTable(GlyphSubstitutionTable.java:313) at org.apache.fontbox.ttf.GlyphSubstitutionTable.readLookupList(GlyphSubstitutionTable.java:247) at org.apache.fontbox.ttf.GlyphSubstitutionTable.read(GlyphSubstitutionTable.java:102) at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:365) at org.apache.fontbox.ttf.TTFParser.parseTables(TTFParser.java:165) at org.apache.fontbox.ttf.TTFParser.parse(TTFParser.java:144) at org.apache.fontbox.ttf.TrueTypeCollection.getFontAtIndex(TrueTypeCollection.java:127) at org.apache.fontbox.ttf.TrueTypeCollection.processAllFonts(TrueTypeCollection.java:109) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.addTrueTypeCollection(FileSystemFontProvider.java:665) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.scanFonts(FileSystemFontProvider.java:396) at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.(FileSystemFontProvider.java:367) at org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.(FontMapperImpl.java:139) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:158) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:416) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:379) at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:353) at org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:127) {noformat} I have a theory why it happens, which is that addTrueTypeCollection() does not add the font as "*skipexception*" to the cache file because it's not done in the exception handler. > Font operation takes a long time with 3.0.1 > --- > > Key: PDFBOX-