[jira] [Commented] (PDFBOX-4184) [PATCH]: Support simple lossless compression of 16 bit RGB images
[ https://issues.apache.org/jira/browse/PDFBOX-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472619#comment-16472619 ] Tilman Hausherr commented on PDFBOX-4184: - The tool is attached here, it's the file [^LoadGovdocs.java]. Test dependencies are fine regardless of the license. > [PATCH]: Support simple lossless compression of 16 bit RGB images > - > > Key: PDFBOX-4184 > URL: https://issues.apache.org/jira/browse/PDFBOX-4184 > Project: PDFBox > Issue Type: Improvement > Components: Writing >Affects Versions: 2.0.9 >Reporter: Emmeran Seehuber >Priority: Minor > Fix For: 2.0.10, 3.0.0 PDFBox > > Attachments: LoadGovdocs.java, > lossless_predictor_based_imageencoding.patch, > pdfbox_support_16bit_image_write.patch, png16-arrow-bad-no-smask.pdf, > png16-arrow-bad.pdf, png16-arrow-good-no-mask.pdf, png16-arrow-good.pdf > > > The attached patch add support to write 16 bit per component images > correctly. I've integrated a test for this here: > [https://github.com/rototor/pdfbox-graphics2d/commit/8bf089cb74945bd4f0f15054754f51dd5b361fe9] > It only supports 16-Bit TYPE_CUSTOM with DataType == USHORT images - but this > is what you usually get when you read a 16 bit PNG file. > This would also fix [https://github.com/danfickle/openhtmltopdf/issues/173]. > The patch is against 2.0.9, but should apply to 3.0.0 too. > There is still some room for improvements when writing lossless images, as > the images are currently not efficiently encoded. I.e. you could use PNG > encodings to get a better compression. (By adding a COSName.DECODE_PARMS with > a COSName.PREDICTOR == 15 and encoding the images as PNG). But this is > something for a later patch. It would also need another API, as there is a > tradeoff speed vs compression ratio. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4184) [PATCH]: Support simple lossless compression of 16 bit RGB images
[ https://issues.apache.org/jira/browse/PDFBOX-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472615#comment-16472615 ] Emmeran Seehuber commented on PDFBOX-4184: -- No hurry, I won't have much time before Sunday to look into it. I also want to do some benchmarking/performance tuning first, to get exact numbers what this changes does in terms of performance/output size. Is jmh ok as test dependency for pdfbox? I'm using the Github mirror and git to track my changes. I suspect that the mirror takes a little to catch up with Subversion? At least at the moment your tool has not yet landed on Github. > [PATCH]: Support simple lossless compression of 16 bit RGB images > - > > Key: PDFBOX-4184 > URL: https://issues.apache.org/jira/browse/PDFBOX-4184 > Project: PDFBox > Issue Type: Improvement > Components: Writing >Affects Versions: 2.0.9 >Reporter: Emmeran Seehuber >Priority: Minor > Fix For: 2.0.10, 3.0.0 PDFBox > > Attachments: LoadGovdocs.java, > lossless_predictor_based_imageencoding.patch, > pdfbox_support_16bit_image_write.patch, png16-arrow-bad-no-smask.pdf, > png16-arrow-bad.pdf, png16-arrow-good-no-mask.pdf, png16-arrow-good.pdf > > > The attached patch add support to write 16 bit per component images > correctly. I've integrated a test for this here: > [https://github.com/rototor/pdfbox-graphics2d/commit/8bf089cb74945bd4f0f15054754f51dd5b361fe9] > It only supports 16-Bit TYPE_CUSTOM with DataType == USHORT images - but this > is what you usually get when you read a 16 bit PNG file. > This would also fix [https://github.com/danfickle/openhtmltopdf/issues/173]. > The patch is against 2.0.9, but should apply to 3.0.0 too. > There is still some room for improvements when writing lossless images, as > the images are currently not efficiently encoded. I.e. you could use PNG > encodings to get a better compression. (By adding a COSName.DECODE_PARMS with > a COSName.PREDICTOR == 15 and encoding the images as PNG). But this is > something for a later patch. It would also need another API, as there is a > tradeoff speed vs compression ratio. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472562#comment-16472562
]
John Hewson commented on PDFBOX-4219:
-
Hmm, looks like this is to support nested reading of tables, such as the
HorizontalMetricsTable.read which starts by calling getHorizontalHeader
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png,
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png,
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf,
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png,
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png,
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times in a test program I created. That one renders 2
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table, and both change the stream position. I tried several things
> in the last months to avoid it, all were unsuccessful and I lost my notes
> about it last winter due to a static discharge on a usb stick. (Thank you
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
> at
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
>
[jira] [Comment Edited] (PDFBOX-4184) [PATCH]: Support simple lossless compression of 16 bit RGB images
[ https://issues.apache.org/jira/browse/PDFBOX-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472558#comment-16472558 ] Tilman Hausherr edited comment on PDFBOX-4184 at 5/11/18 7:50 PM: -- I forgot to mention, we're planning a release soon, I prefer to wait until after the release before deciding to commit to 2.0. was (Author: tilman): I forgot to mention, we're planning a release soon, I prefer to wait until after the release. > [PATCH]: Support simple lossless compression of 16 bit RGB images > - > > Key: PDFBOX-4184 > URL: https://issues.apache.org/jira/browse/PDFBOX-4184 > Project: PDFBox > Issue Type: Improvement > Components: Writing >Affects Versions: 2.0.9 >Reporter: Emmeran Seehuber >Priority: Minor > Fix For: 2.0.10, 3.0.0 PDFBox > > Attachments: LoadGovdocs.java, > lossless_predictor_based_imageencoding.patch, > pdfbox_support_16bit_image_write.patch, png16-arrow-bad-no-smask.pdf, > png16-arrow-bad.pdf, png16-arrow-good-no-mask.pdf, png16-arrow-good.pdf > > > The attached patch add support to write 16 bit per component images > correctly. I've integrated a test for this here: > [https://github.com/rototor/pdfbox-graphics2d/commit/8bf089cb74945bd4f0f15054754f51dd5b361fe9] > It only supports 16-Bit TYPE_CUSTOM with DataType == USHORT images - but this > is what you usually get when you read a 16 bit PNG file. > This would also fix [https://github.com/danfickle/openhtmltopdf/issues/173]. > The patch is against 2.0.9, but should apply to 3.0.0 too. > There is still some room for improvements when writing lossless images, as > the images are currently not efficiently encoded. I.e. you could use PNG > encodings to get a better compression. (By adding a COSName.DECODE_PARMS with > a COSName.PREDICTOR == 15 and encoding the images as PNG). But this is > something for a later patch. It would also need another API, as there is a > tradeoff speed vs compression ratio. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4184) [PATCH]: Support simple lossless compression of 16 bit RGB images
[ https://issues.apache.org/jira/browse/PDFBOX-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472558#comment-16472558 ] Tilman Hausherr commented on PDFBOX-4184: - I forgot to mention, we're planning a release soon, I prefer to wait until after the release. > [PATCH]: Support simple lossless compression of 16 bit RGB images > - > > Key: PDFBOX-4184 > URL: https://issues.apache.org/jira/browse/PDFBOX-4184 > Project: PDFBox > Issue Type: Improvement > Components: Writing >Affects Versions: 2.0.9 >Reporter: Emmeran Seehuber >Priority: Minor > Fix For: 2.0.10, 3.0.0 PDFBox > > Attachments: LoadGovdocs.java, > lossless_predictor_based_imageencoding.patch, > pdfbox_support_16bit_image_write.patch, png16-arrow-bad-no-smask.pdf, > png16-arrow-bad.pdf, png16-arrow-good-no-mask.pdf, png16-arrow-good.pdf > > > The attached patch add support to write 16 bit per component images > correctly. I've integrated a test for this here: > [https://github.com/rototor/pdfbox-graphics2d/commit/8bf089cb74945bd4f0f15054754f51dd5b361fe9] > It only supports 16-Bit TYPE_CUSTOM with DataType == USHORT images - but this > is what you usually get when you read a 16 bit PNG file. > This would also fix [https://github.com/danfickle/openhtmltopdf/issues/173]. > The patch is against 2.0.9, but should apply to 3.0.0 too. > There is still some room for improvements when writing lossless images, as > the images are currently not efficiently encoded. I.e. you could use PNG > encodings to get a better compression. (By adding a COSName.DECODE_PARMS with > a COSName.PREDICTOR == 15 and encoding the images as PNG). But this is > something for a later patch. It would also need another API, as there is a > tradeoff speed vs compression ratio. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4184) [PATCH]: Support simple lossless compression of 16 bit RGB images
[ https://issues.apache.org/jira/browse/PDFBOX-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472478#comment-16472478 ] Tilman Hausherr edited comment on PDFBOX-4184 at 5/11/18 6:55 PM: -- Please run the tool I just uploaded... If a test fails, something is written to System.err and the two files are saved in the local directory. I get a few "hits": 001/001229.png: images not equal 001/001230.png: images not equal and also some jpg images. Without the change, this doesn't happen. I suspect that the differences are minor, but IMHO there shouldn't be any at all... was (Author: tilman): Please run the tool I just uploaded... I get a few "hits": 001/001229.png: images not equal 001/001230.png: images not equal and also some jpg images. Without the change, this doesn't happen. I suspect that the differences are minor, but IMHO there shouldn't be any at all... > [PATCH]: Support simple lossless compression of 16 bit RGB images > - > > Key: PDFBOX-4184 > URL: https://issues.apache.org/jira/browse/PDFBOX-4184 > Project: PDFBox > Issue Type: Improvement > Components: Writing >Affects Versions: 2.0.9 >Reporter: Emmeran Seehuber >Priority: Minor > Fix For: 2.0.10, 3.0.0 PDFBox > > Attachments: LoadGovdocs.java, > lossless_predictor_based_imageencoding.patch, > pdfbox_support_16bit_image_write.patch, png16-arrow-bad-no-smask.pdf, > png16-arrow-bad.pdf, png16-arrow-good-no-mask.pdf, png16-arrow-good.pdf > > > The attached patch add support to write 16 bit per component images > correctly. I've integrated a test for this here: > [https://github.com/rototor/pdfbox-graphics2d/commit/8bf089cb74945bd4f0f15054754f51dd5b361fe9] > It only supports 16-Bit TYPE_CUSTOM with DataType == USHORT images - but this > is what you usually get when you read a 16 bit PNG file. > This would also fix [https://github.com/danfickle/openhtmltopdf/issues/173]. > The patch is against 2.0.9, but should apply to 3.0.0 too. > There is still some room for improvements when writing lossless images, as > the images are currently not efficiently encoded. I.e. you could use PNG > encodings to get a better compression. (By adding a COSName.DECODE_PARMS with > a COSName.PREDICTOR == 15 and encoding the images as PNG). But this is > something for a later patch. It would also need another API, as there is a > tradeoff speed vs compression ratio. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4184) [PATCH]: Support simple lossless compression of 16 bit RGB images
[ https://issues.apache.org/jira/browse/PDFBOX-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472478#comment-16472478 ] Tilman Hausherr commented on PDFBOX-4184: - Please run the tool I just uploaded... I get a few "hits": 001/001229.png: images not equal 001/001230.png: images not equal and also some jpg images. Without the change, this doesn't happen. I suspect that the differences are minor, but IMHO there shouldn't be any at all... > [PATCH]: Support simple lossless compression of 16 bit RGB images > - > > Key: PDFBOX-4184 > URL: https://issues.apache.org/jira/browse/PDFBOX-4184 > Project: PDFBox > Issue Type: Improvement > Components: Writing >Affects Versions: 2.0.9 >Reporter: Emmeran Seehuber >Priority: Minor > Fix For: 2.0.10, 3.0.0 PDFBox > > Attachments: LoadGovdocs.java, > lossless_predictor_based_imageencoding.patch, > pdfbox_support_16bit_image_write.patch, png16-arrow-bad-no-smask.pdf, > png16-arrow-bad.pdf, png16-arrow-good-no-mask.pdf, png16-arrow-good.pdf > > > The attached patch add support to write 16 bit per component images > correctly. I've integrated a test for this here: > [https://github.com/rototor/pdfbox-graphics2d/commit/8bf089cb74945bd4f0f15054754f51dd5b361fe9] > It only supports 16-Bit TYPE_CUSTOM with DataType == USHORT images - but this > is what you usually get when you read a 16 bit PNG file. > This would also fix [https://github.com/danfickle/openhtmltopdf/issues/173]. > The patch is against 2.0.9, but should apply to 3.0.0 too. > There is still some room for improvements when writing lossless images, as > the images are currently not efficiently encoded. I.e. you could use PNG > encodings to get a better compression. (By adding a COSName.DECODE_PARMS with > a COSName.PREDICTOR == 15 and encoding the images as PNG). But this is > something for a later patch. It would also need another API, as there is a > tradeoff speed vs compression ratio. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4184) [PATCH]: Support simple lossless compression of 16 bit RGB images
[ https://issues.apache.org/jira/browse/PDFBOX-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilman Hausherr updated PDFBOX-4184: Attachment: LoadGovdocs.java > [PATCH]: Support simple lossless compression of 16 bit RGB images > - > > Key: PDFBOX-4184 > URL: https://issues.apache.org/jira/browse/PDFBOX-4184 > Project: PDFBox > Issue Type: Improvement > Components: Writing >Affects Versions: 2.0.9 >Reporter: Emmeran Seehuber >Priority: Minor > Fix For: 2.0.10, 3.0.0 PDFBox > > Attachments: LoadGovdocs.java, > lossless_predictor_based_imageencoding.patch, > pdfbox_support_16bit_image_write.patch, png16-arrow-bad-no-smask.pdf, > png16-arrow-bad.pdf, png16-arrow-good-no-mask.pdf, png16-arrow-good.pdf > > > The attached patch add support to write 16 bit per component images > correctly. I've integrated a test for this here: > [https://github.com/rototor/pdfbox-graphics2d/commit/8bf089cb74945bd4f0f15054754f51dd5b361fe9] > It only supports 16-Bit TYPE_CUSTOM with DataType == USHORT images - but this > is what you usually get when you read a 16 bit PNG file. > This would also fix [https://github.com/danfickle/openhtmltopdf/issues/173]. > The patch is against 2.0.9, but should apply to 3.0.0 too. > There is still some room for improvements when writing lossless images, as > the images are currently not efficiently encoded. I.e. you could use PNG > encodings to get a better compression. (By adding a COSName.DECODE_PARMS with > a COSName.PREDICTOR == 15 and encoding the images as PNG). But this is > something for a later patch. It would also need another API, as there is a > tradeoff speed vs compression ratio. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472451#comment-16472451
]
John Hewson commented on PDFBOX-4219:
-
{quote}
My theory is that one thread accesses the naming table and another accesses the
glyf table, and both change the stream position.
{quote}
Access to read these tables is via getTable which is synchronized, so that
shouldn't be happening. But readTable looks very strange to me:
{code}
void readTable(TTFTable table) throws IOException
{
// save current position
long currentPosition = data.getCurrentPosition();
data.seek(table.getOffset());
table.read(this, data);
// restore current position
data.seek(currentPosition);
}
{code}
Why would the current position need saving? No subsequent calls to readTable
should rely on this!?
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png,
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png,
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf,
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png,
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png,
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times in a test program I created. That one renders 2
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table, and both change the stream position. I tried several things
> in the last months to avoid it, all were unsuccessful and I lost my notes
> about it last winter due to a static discharge on a usb stick. (Thank you
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.
[jira] [Comment Edited] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472366#comment-16472366
]
John Hewson edited comment on PDFBOX-4219 at 5/11/18 5:58 PM:
--
I can't reproduce this on my Mac which uses {{Times-Roman}} as the fallback
font instead.
was (Author: jahewson):
I can't reproduce this on my Mac which uses {{Times-Roman}} as the substitute
font instead.
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png,
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png,
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf,
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png,
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png,
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times in a test program I created. That one renders 2
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table, and both change the stream position. I tried several things
> in the last months to avoid it, all were unsuccessful and I lost my notes
> about it last winter due to a static discharge on a usb stick. (Thank you
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
> at
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
>
[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472366#comment-16472366
]
John Hewson commented on PDFBOX-4219:
-
I can't reproduce this on my Mac which uses {{Times-Roman}} as the substitute
font instead.
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png,
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png,
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf,
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png,
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png,
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times in a test program I created. That one renders 2
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table, and both change the stream position. I tried several things
> in the last months to avoid it, all were unsuccessful and I lost my notes
> about it last winter due to a static discharge on a usb stick. (Thank you
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
> at
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine
[jira] [Issue Comment Deleted] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson updated PDFBOX-4219:
Comment: was deleted
(was: Do you have the Galliard font on your system? I get:
{code}
WARNING: Using fallback font Times-Bold for Galliard-Bold
WARNING: Using fallback font Times-Roman for Galliard-Roman
WARNING: Using fallback font Times-Italic for Galliard-Italic
{code})
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png,
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png,
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf,
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png,
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png,
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times in a test program I created. That one renders 2
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table, and both change the stream position. I tried several things
> in the last months to avoid it, all were unsuccessful and I lost my notes
> about it last winter due to a static discharge on a usb stick. (Thank you
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
> at
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstr
[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472305#comment-16472305
]
John Hewson commented on PDFBOX-4219:
-
Do you have the Galliard font on your system? I get:
{code}
WARNING: Using fallback font Times-Bold for Galliard-Bold
WARNING: Using fallback font Times-Roman for Galliard-Roman
WARNING: Using fallback font Times-Italic for Galliard-Italic
{code}
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png,
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png,
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf,
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png,
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png,
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times in a test program I created. That one renders 2
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table, and both change the stream position. I tried several things
> in the last months to avoid it, all were unsuccessful and I lost my notes
> about it last winter due to a static discharge on a usb stick. (Thank you
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
> at
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org
[jira] [Comment Edited] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472256#comment-16472256
]
John Hewson edited comment on PDFBOX-4220 at 5/11/18 4:56 PM:
--
[~tilman] Thread safety is only part of the problem, the overall problem is
actually that fonts are shared objects. In other words the following situations
cause problems: 1) reuse of a font within just one document (e.g. imagine using
Arial Unicode MS to write some Arabic with those features enabled, then turning
them off and writing some English - the subsetter now has an inconsistent view
of the font). 2) Reuse of a font between documents (e.g. if I'm writing with
the same TTF font file to two PDF files even with just one thread, fonts are
shared between them). 3) Reuse of a font across threads - this is just a more
general version of (2).
The fix will be to move the enabled/disabled feature state out of the font.
This actually works out nicely because features don't belong at the font-level
but at the text-level. One expects to have an API such as showText(string,
List) which allows features to be changed many times while working
with a single font (an example would be the "dlig" feature which enables
discretionary stylistic ligatures to add some visual decoration, perhaps for a
title or heading).
was (Author: jahewson):
[~tilman] Thread safety is only part of the problem, the overall problem is
actually that fonts are shared objects. In other words the following situations
cause problems: 1) reuse of a font within just one document (e.g. imagine using
Arial Unicode MS to write some Arabic with those features enabled, then turning
them off and writing some English - the subsetter now has an inconsistent view
of the font). 2) Reuse of a font between documents (e.g. if I'm writing two PDF
files using just one thread, then fonts will be shared between them). 3) Reuse
of a font across threads - this is just a more general version of (2).
The fix will be to move the enabled/disabled feature state out of the font.
This actually works out nicely because features don't belong at the font-level
but at the text-level. One expects to have an API such as showText(string,
List) which allows features to be changed many times while working
with a single font (an example would be the "dlig" feature which enables
discretionary stylistic ligatures to add some visual decoration, perhaps for a
title or heading).
> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for
> PDFBOX-4189 I've encountered some significant issues related to this feature.
> Given that this was shipped in 2.0.9, we're likely going to face some hard
> choices.
> Most of the handling of vertical text in this patch is fine. It generally
> does a good job of handling the intricacies of both PDF and OpenType and
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in
> FontBox must be thread safe - they are cached and shared globally between all
> PDDocument instances. For this reason a FontBoxFont must not contain any
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
> {{enableGsubFeature(String)}}
> {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
> {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will
> clobber the corresponding state for all other threads. This problem can even
> occur if the user is manipulating more than one document within a single
> thread. *There's no way around this and no way to fix these methods* -
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very
> obscure methods which have only been around for a few weeks. It's unlikely
> that _any_ users would be affected by their removal. Obviously the m
[jira] [Commented] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table
[ https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472265#comment-16472265 ] John Hewson commented on PDFBOX-4189: - See PDFBOX-4220 for work on those problems. > Enable PDF creation with Indian languages, by reading and utilizing the GSUB > table > -- > > Key: PDFBOX-4189 > URL: https://issues.apache.org/jira/browse/PDFBOX-4189 > Project: PDFBox > Issue Type: New Feature > Components: FontBox, PDModel >Reporter: Palash Ray >Priority: Major > Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, > BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, > bengali-example2.pdf, bengali-example3.pdf, committed.patch, screenshot.png > > Original Estimate: 336h > Remaining Estimate: 336h > > Implemented proper rendering of Indian languages, which need extensive Glyph > substitution. The GSUB table has been read and used effectively to replace > some compound words with their respective Glyphs. All tests are passing. I > have tested this for the Bengali font. Please review these changes and let me > know if it makes sense to incorporate these. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472260#comment-16472260
]
John Hewson edited comment on PDFBOX-4220 at 5/11/18 4:51 PM:
--
Comment from PDFBOX-4106:
{quote}
Aaron Madlon-Kay added a comment - Yesterday
Hi John. Thanks for raising these concerns, and sorry for having gotten us into
this mess.
I am fine with any API changes deemed necessary. As for functionality, the only
non-obvious thing that I want to mention is that it's important to be able to
selectively enable/disable vrt2. The reason is that the substitutions performed
by vrt2 are not always more desirable than vert, and it is common to want to
use only vert substitutions with a font that supports both.
{quote}
was (Author: jahewson):
Comment from PDFBOX-4106:
{quote}
amake Aaron Madlon-Kay added a comment - Yesterday
Hi John. Thanks for raising these concerns, and sorry for having gotten us into
this mess.
I am fine with any API changes deemed necessary. As for functionality, the only
non-obvious thing that I want to mention is that it's important to be able to
selectively enable/disable vrt2. The reason is that the substitutions performed
by vrt2 are not always more desirable than vert, and it is common to want to
use only vert substitutions with a font that supports both.
{quote}
> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for
> PDFBOX-4189 I've encountered some significant issues related to this feature.
> Given that this was shipped in 2.0.9, we're likely going to face some hard
> choices.
> Most of the handling of vertical text in this patch is fine. It generally
> does a good job of handling the intricacies of both PDF and OpenType and
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in
> FontBox must be thread safe - they are cached and shared globally between all
> PDDocument instances. For this reason a FontBoxFont must not contain any
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
> {{enableGsubFeature(String)}}
> {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
> {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will
> clobber the corresponding state for all other threads. This problem can even
> occur if the user is manipulating more than one document within a single
> thread. *There's no way around this and no way to fix these methods* -
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very
> obscure methods which have only been around for a few weeks. It's unlikely
> that _any_ users would be affected by their removal. Obviously the missing
> functionality will be implemented in the appropriate location*, so vertical
> text will still work in 2.0 and the existing PDType0Font.loadVertical API -
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it
> stands we have just shipped a breaking functionality change to 2.0 and broken
> existing functionality in an irreparable manner, and that seems worse.
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472260#comment-16472260
]
John Hewson commented on PDFBOX-4220:
-
Comment from PDFBOX-4106:
{quote}
amake Aaron Madlon-Kay added a comment - Yesterday
Hi John. Thanks for raising these concerns, and sorry for having gotten us into
this mess.
I am fine with any API changes deemed necessary. As for functionality, the only
non-obvious thing that I want to mention is that it's important to be able to
selectively enable/disable vrt2. The reason is that the substitutions performed
by vrt2 are not always more desirable than vert, and it is common to want to
use only vert substitutions with a font that supports both.
{quote}
> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for
> PDFBOX-4189 I've encountered some significant issues related to this feature.
> Given that this was shipped in 2.0.9, we're likely going to face some hard
> choices.
> Most of the handling of vertical text in this patch is fine. It generally
> does a good job of handling the intricacies of both PDF and OpenType and
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in
> FontBox must be thread safe - they are cached and shared globally between all
> PDDocument instances. For this reason a FontBoxFont must not contain any
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
> {{enableGsubFeature(String)}}
> {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
> {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will
> clobber the corresponding state for all other threads. This problem can even
> occur if the user is manipulating more than one document within a single
> thread. *There's no way around this and no way to fix these methods* -
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very
> obscure methods which have only been around for a few weeks. It's unlikely
> that _any_ users would be affected by their removal. Obviously the missing
> functionality will be implemented in the appropriate location*, so vertical
> text will still work in 2.0 and the existing PDType0Font.loadVertical API -
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it
> stands we have just shipped a breaking functionality change to 2.0 and broken
> existing functionality in an irreparable manner, and that seems worse.
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472256#comment-16472256
]
John Hewson commented on PDFBOX-4220:
-
[~tilman] Thread safety is only part of the problem, the overall problem is
actually that fonts are shared objects. In other words the following situations
cause problems: 1) reuse of a font within just one document (e.g. imagine using
Arial Unicode MS to write some Arabic with those features enabled, then turning
them off and writing some English - the subsetter now has an inconsistent view
of the font). 2) Reuse of a font between documents (e.g. if I'm writing two PDF
files using just one thread, then fonts will be shared between them). 3) Reuse
of a font across threads - this is just a more general version of (2).
The fix will be to move the enabled/disabled feature state out of the font.
This actually works out nicely because features don't belong at the font-level
but at the text-level. One expects to have an API such as showText(string,
List) which allows features to be changed many times while working
with a single font (an example would be the "dlig" feature which enables
discretionary stylistic ligatures to add some visual decoration, perhaps for a
title or heading).
> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for
> PDFBOX-4189 I've encountered some significant issues related to this feature.
> Given that this was shipped in 2.0.9, we're likely going to face some hard
> choices.
> Most of the handling of vertical text in this patch is fine. It generally
> does a good job of handling the intricacies of both PDF and OpenType and
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in
> FontBox must be thread safe - they are cached and shared globally between all
> PDDocument instances. For this reason a FontBoxFont must not contain any
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
> {{enableGsubFeature(String)}}
> {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
> {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will
> clobber the corresponding state for all other threads. This problem can even
> occur if the user is manipulating more than one document within a single
> thread. *There's no way around this and no way to fix these methods* -
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very
> obscure methods which have only been around for a few weeks. It's unlikely
> that _any_ users would be affected by their removal. Obviously the missing
> functionality will be implemented in the appropriate location*, so vertical
> text will still work in 2.0 and the existing PDType0Font.loadVertical API -
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it
> stands we have just shipped a breaking functionality change to 2.0 and broken
> existing functionality in an irreparable manner, and that seems worse.
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472255#comment-16472255
]
John Hewson commented on PDFBOX-4220:
-
Just to re-cap:
{quote}
Tilman Hausherr added a comment
So the problem is that a TrueTypeFont object could be reused by several
threads, and the gsub feature vrt2 may be enabled in one and disabled in
another?
{quote}
> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for
> PDFBOX-4189 I've encountered some significant issues related to this feature.
> Given that this was shipped in 2.0.9, we're likely going to face some hard
> choices.
> Most of the handling of vertical text in this patch is fine. It generally
> does a good job of handling the intricacies of both PDF and OpenType and
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in
> FontBox must be thread safe - they are cached and shared globally between all
> PDDocument instances. For this reason a FontBoxFont must not contain any
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
> {{enableGsubFeature(String)}}
> {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
> {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will
> clobber the corresponding state for all other threads. This problem can even
> occur if the user is manipulating more than one document within a single
> thread. *There's no way around this and no way to fix these methods* -
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very
> obscure methods which have only been around for a few weeks. It's unlikely
> that _any_ users would be affected by their removal. Obviously the missing
> functionality will be implemented in the appropriate location*, so vertical
> text will still work in 2.0 and the existing PDType0Font.loadVertical API -
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it
> stands we have just shipped a breaking functionality change to 2.0 and broken
> existing functionality in an irreparable manner, and that seems worse.
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Closed] (PDFBOX-4106) Vertical text creation
[
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson closed PDFBOX-4106.
---
Resolution: Fixed
I've migrated the new bug to PDFBOX-4220.
> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
> Labels: embed, gsub, parsing, vertical
> Fix For: 3.0.0 PDFBox, 2.0.9
>
> Attachments:
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch,
> 0002-Optimize-Unicode-script-storage-and-lookup.patch,
> 0003-Parse-GSUB-table.patch,
> 0004-Abstract-cmap-lookup-into-an-interface.patch,
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch,
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch,
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch,
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch,
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch,
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch,
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch,
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch,
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch,
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch,
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch,
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch,
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch,
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch,
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but
> not used at all)
> I have attached a series of patches that implement the above features.
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups
> only; this is sufficient for many features including 'vert'/'vrt2' vertical
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if
> desired.
> Also attached is some sample code that exercises these patches and
> illustrates the effect of vertical glyph positioning. The sample output PDF
> is also attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts
John Hewson created PDFBOX-4220:
---
Summary: FontBox sets GSUB features globally across shared fonts
Key: PDFBOX-4220
URL: https://issues.apache.org/jira/browse/PDFBOX-4220
Project: PDFBox
Issue Type: Bug
Components: FontBox, Parsing, Writing
Affects Versions: 2.0.9, 3.0.0 PDFBox
Reporter: John Hewson
Assignee: John Hewson
Migrating the following issue from PDFBOX-4106:
{quote}
(!) So we have a problem. While looking at building a proper ToUnicodeMap for
PDFBOX-4189 I've encountered some significant issues related to this feature.
Given that this was shipped in 2.0.9, we're likely going to face some hard
choices.
Most of the handling of vertical text in this patch is fine. It generally does
a good job of handling the intricacies of both PDF and OpenType and juggling
the sometimes competing concerns.
The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be
thread safe - they are cached and shared globally between all PDDocument
instances. For this reason a FontBoxFont must not contain any document-specific
state.
The following fields added to TrueTypeFont contain document-specific state:
{{List enabledGsubFeatures}}
The following methods added to TrueTypeFont write document-specific state:
{{enableVerticalSubstitutions()}}
{{enableGsubFeature(String)}}
{{disableGsubFeature(String)}}
The following methods added to TrueTypeFont read document-specific state:
{{getUnicodeCmapLookup()}}
{{getUnicodeCmapLookup(boolean)}}
None of the additions are thread safe, anyone who calls these methods will
clobber the corresponding state for all other threads. This problem can even
occur if the user is manipulating more than one document within a single
thread. *There's no way around this and no way to fix these methods* -
document-specific state can't live in shared global fonts :(
(flag) Tough choices: Given that these are all just auxiliary methods limited
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very
obscure methods which have only been around for a few weeks. It's unlikely that
_any_ users would be affected by their removal. Obviously the missing
functionality will be implemented in the appropriate location*, so vertical
text will still work in 2.0 and the existing PDType0Font.loadVertical API -
which is the only thing that matters - will remain unchanged! :)
Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it
stands we have just shipped a breaking functionality change to 2.0 and broken
existing functionality in an irreparable manner, and that seems worse. Thoughts?
\* And I have some ideas how to achieve this and am happy to do it
{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4106) Vertical text creation
[
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472237#comment-16472237
]
John Hewson commented on PDFBOX-4106:
-
[~amake], that's ok, don't worry about it. We should have been more
conservative about what gets pushed to the stable branch. Thank you for all
your hard work.
[~lehmi] Will do.
[~tilman] Thread safety is only part of the problem, the overall problem is
actually that fonts are shared objects. In other words the following situations
cause problems: 1) reuse of a font within just one document (e.g. imagine using
Arial Unicode MS to write some Arabic with those features enabled, then turning
them off and writing some English - the subsetter now has an inconsistent view
of the font). 2) Reuse of a font between documents (e.g. if I'm writing two PDF
files using just one thread, then fonts will be shared between them). 3) Reuse
of a font across threads - this is just a more general version of (2).
> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
> Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments:
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch,
> 0002-Optimize-Unicode-script-storage-and-lookup.patch,
> 0003-Parse-GSUB-table.patch,
> 0004-Abstract-cmap-lookup-into-an-interface.patch,
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch,
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch,
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch,
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch,
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch,
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch,
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch,
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch,
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch,
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch,
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch,
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch,
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch,
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch,
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but
> not used at all)
> I have attached a series of patches that implement the above features.
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups
> only; this is sufficient for many features including 'vert'/'vrt2' vertical
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if
> desired.
> Also attached is some sample code that exercises these patches and
> illustrates the effect of vertical glyph positioning. The sample output PDF
> is also attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4106) Vertical text creation
[
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hewson updated PDFBOX-4106:
Issue Type: New Feature (was: Bug)
> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
> Issue Type: New Feature
> Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
> Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments:
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch,
> 0002-Optimize-Unicode-script-storage-and-lookup.patch,
> 0003-Parse-GSUB-table.patch,
> 0004-Abstract-cmap-lookup-into-an-interface.patch,
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch,
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch,
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch,
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch,
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch,
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch,
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch,
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch,
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch,
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch,
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch,
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch,
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch,
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch,
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but
> not used at all)
> I have attached a series of patches that implement the above features.
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups
> only; this is sufficient for many features including 'vert'/'vrt2' vertical
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if
> desired.
> Also attached is some sample code that exercises these patches and
> illustrates the effect of vertical glyph positioning. The sample output PDF
> is also attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472181#comment-16472181
]
Jim Halpert commented on PDFBOX-4216:
-
[~tilman] Thanks for the explanation. I will try that and update here.
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: .pdfbox.cache, Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
> if (m.get(field.getFullyQualifiedName()) != null) // set value of
> map when map key and pdf key is matched
> {
>
> field.setValue(m.get(field.getFullyQualifiedName()).toString());
> }
> }
>
> pdfDoc.save(new File("pdfbox_linux_issue-saved.pdf"));
> {code}
> Works in Windows, Linux Mint, Ubuntu as expected. Issue is only with Red Hat
> Enterprise 7.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472149#comment-16472149
]
Tilman Hausherr commented on PDFBOX-4216:
-
The .pdfbox.cache file is to remember what fonts are on your system, to speed
things up. Many PDF files do not have embedded fonts, so we have to choose one
that is similar. The problem is that LiberationSans is the "last resort
fallback" font, it is proportional and looks completely different than Courier.
If you install Courier, PDFBox will notice at the next start that new fonts
have been installed and then make a better choice and get the correct width.
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: .pdfbox.cache, Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
> if (m.get(field.getFullyQualifiedName()) != null) // set value of
> map when map key and pdf key is matched
> {
>
> field.setValue(m.get(field.getFullyQualifiedName()).toString());
> }
> }
>
> pdfDoc.save(new File("pdfbox_linux_issue-saved.pdf"));
> {code}
> Works in Windows, Linux Mint, Ubuntu as expected. Issue is only with Red Hat
> Enterprise 7.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472128#comment-16472128
]
Jim Halpert commented on PDFBOX-4216:
-
Now that you have mentioned, here's the log message. Now, it's making some
sense.
{code:java}
May 11, 2018 10:13:01 AM org.apache.pdfbox.pdmodel.font.PDType1Font
WARNING: Using fallback font LiberationSans for base font Times-Roman May 11,
2018 10:13:01 AM org.apache.pdfbox.pdmodel.font.PDType1Font WARNING:
Using fallback font LiberationSans for base font Times-Bold May 11, 2018
10:13:01 AM org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using
fallback font LiberationSans for base font Times-Italic May 11, 2018 10:13:01
AM org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback
font LiberationSans for base font Times-BoldItalic May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Helvetica May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Helvetica-Bold May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Helvetica-Oblique May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Helvetica-BoldOblique May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Courier May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Courier-Bold May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Courier-Oblique May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Courier-BoldOblique May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font Symbol May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for base font ZapfDingbats May 11, 2018 10:13:01 AM
org.apache.pdfbox.pdmodel.font.PDType1Font WARNING: Using fallback font
LiberationSans for Courier
{code}
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: .pdfbox.cache, Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
>
[jira] [Comment Edited] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472125#comment-16472125
]
Jim Halpert edited comment on PDFBOX-4216 at 5/11/18 3:39 PM:
--
[~tilman] Let me understand the solution here. How installing standard 14 fonts
solve the issue when pdf box is picking LiberationSans? Can you explain a bit
on what is .pdfbox.cache and how it is being used?
was (Author: anealkeshi):
[~tilman] Let me understand the soution here. How installing standard 14 fonts
solve the issue when pdf box is picking LiberationSans? Can you explain a bit
on what is .pdfbox.cache and how it is being used?
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: .pdfbox.cache, Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
> if (m.get(field.getFullyQualifiedName()) != null) // set value of
> map when map key and pdf key is matched
> {
>
> field.setValue(m.get(field.getFullyQualifiedName()).toString());
> }
> }
>
> pdfDoc.save(new File("pdfbox_linux_issue-saved.pdf"));
> {code}
> Works in Windows, Linux Mint, Ubuntu as expected. Issue is only with Red Hat
> Enterprise 7.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472125#comment-16472125
]
Jim Halpert commented on PDFBOX-4216:
-
[~tilman] Let me understand the soution here. How installing standard 14 fonts
solve the issue when pdf box is picking LiberationSans? Can you explain a bit
on what is .pdfbox.cache and how it is being used?
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: .pdfbox.cache, Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
> if (m.get(field.getFullyQualifiedName()) != null) // set value of
> map when map key and pdf key is matched
> {
>
> field.setValue(m.get(field.getFullyQualifiedName()).toString());
> }
> }
>
> pdfDoc.save(new File("pdfbox_linux_issue-saved.pdf"));
> {code}
> Works in Windows, Linux Mint, Ubuntu as expected. Issue is only with Red Hat
> Enterprise 7.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472118#comment-16472118
]
Tilman Hausherr commented on PDFBOX-4216:
-
So PDFBox uses the fallback font that is included. I suspect that there was a
log message. The easiest solution for you would be to install the standard 14
fonts, i.e. courier, times, helvetica/arial, zapf dingbats and symbol.
I suspect that the problem in PDFBox is that we take the glyph sizes of the
actual font (LiberationSans) instead of the built-in sizes from the AFM files.
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: .pdfbox.cache, Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
> if (m.get(field.getFullyQualifiedName()) != null) // set value of
> map when map key and pdf key is matched
> {
>
> field.setValue(m.get(field.getFullyQualifiedName()).toString());
> }
> }
>
> pdfDoc.save(new File("pdfbox_linux_issue-saved.pdf"));
> {code}
> Works in Windows, Linux Mint, Ubuntu as expected. Issue is only with Red Hat
> Enterprise 7.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472103#comment-16472103
]
Jim Halpert commented on PDFBOX-4216:
-
The output to
{code:java}
System.out.println(((PDType1Font)appearanceStyle.getFont()).getFontBoxFont());{code}
For Red Hat, it's *_LiberationSans_* and for WIndows, it's _*CourierNewPSMT.*_
Here's the content of Red Hat *.pdfbox.cache* file
{code:java}
STIX-Bold|OTF||2bc|0|a1ff|dfff|1|0800|/usr/share/fonts/stix/STIX-Bold.otf
STIX-BoldItalic|OTF||2bc|0|a1ff|dfff|3||/usr/share/fonts/stix/STIX-BoldItalic.otf
STIX-Italic|OTF||190|0|a1ff|dfff|2||/usr/share/fonts/stix/STIX-Italic.otf
STIX-Regular|OTF||190|0|a1ff|dfff|0||/usr/share/fonts/stix/STIX-Regular.otf
{code}
Here's same file from my windows machine.
[^.pdfbox.cache]
Clearly, there's a font issue.
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: .pdfbox.cache, Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
> if (m.get(field.getFullyQualifiedName()) != null) // set value of
> map when map key and pdf key is matched
> {
>
> field.setValue(m.get(field.getFullyQualifiedName()).toString());
> }
> }
>
> pdfDoc.save(new File("pdfbox_linux_issue-saved.pdf"));
> {code}
> Works in Windows, Linux Mint, Ubuntu as expected. Issue is only with Red Hat
> Enterprise 7.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Halpert updated PDFBOX-4216:
Attachment: .pdfbox.cache
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: .pdfbox.cache, Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
> if (m.get(field.getFullyQualifiedName()) != null) // set value of
> map when map key and pdf key is matched
> {
>
> field.setValue(m.get(field.getFullyQualifiedName()).toString());
> }
> }
>
> pdfDoc.save(new File("pdfbox_linux_issue-saved.pdf"));
> {code}
> Works in Windows, Linux Mint, Ubuntu as expected. Issue is only with Red Hat
> Enterprise 7.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[
https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472021#comment-16472021
]
Tilman Hausherr commented on PDFBOX-4216:
-
Thank you. So it's the width of the text that is different.
Please try to output this on both:
{code:java}
System.out.println(((PDType1Font)appearanceStyle.getFont()).getFontBoxFont());{code}
On my system, this shows "CourierNewPSMT". The reason is that the standard 14
fonts can be assigned to different fonts depending the system.
Or look into the .pdfbox.cache file as mentioned earlier...
> PDFBox decimal value cutting off in Red Hat Enterprise 7.4
> --
>
> Key: PDFBOX-4216
> URL: https://issues.apache.org/jira/browse/PDFBOX-4216
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.9
> Environment: LINUX
>Reporter: Jim Halpert
>Priority: Major
> Attachments: Capture.PNG, pdfbox_issue.PNG,
> pdfbox_linux_issue-saved-AR.pdf, pdfbox_linux_issue-saved.pdf,
> pdfbox_linux_issue.pdf, test.pdf
>
>
> Facing issue with Pdf decimal value mapping in the pdffiled in LINUX
> environment, right side decimal values are cutting off, appreciate quick help
> on this.
> {code:java}
> PDDocument pdfDoc = PDDocument.load(new File("pdfbox_linux_issue.pdf"));
> PDDocumentCatalog docCatalog = pdfDoc.getDocumentCatalog();
> PDAcroForm acroForm = docCatalog.getAcroForm();
> Map m = new HashMap();
> m.put("amtPaidForUnit", "15,999.23");
> m.put("amtPubFreightFees", "22.55");
> m.put("amtPaidTotAccessories", "45612.12");
> m.put("dealerDocPrepFees", "55.22");
> m.put("amtDownTradeTotal", "56.89");
> m.put("amtPaidSalesTax", "99.55");
> m.put("amtSerContractTo", "895.66");
> m.put("amtSerContractAmt", "965.36");
> m.put("amtGapProtTo", "798.56");
> m.put("amtGapProtAmt", "64654.33");
> m.put("amtTireGuardTo", "45465.22");
> m.put("amtTireGuardAmt", "455.66");
> m.put("amtPaidOptExtWarr", "88.56");
> m.put("amtPaidOptExtWarrAmt", "663.44");
> m.put("amtPubTitleFees", "54.25");
> m.put("amtPubLicFees", "4654.56");
> m.put("amtPubRegFees", "545.13");
> m.put("amtPubLienFees", "89.22");
> m.put("amtPubFilingFees", "564.65");
> m.put("amtPubStampFees", "56.65");
> m.put("amtPubToAmt", "789.45");
> m.put("amtPubTo2Amt", "15.645");
> m.put("subtotalOfSectionsABC", "13.456");
> m.put("amtLenderOrigFeesAmt", "64.454");
> m.put("amtLender1FeesAmt", "63.56");
> m.put("subtotalOfSection2", "89.12");
> m.put("subtotalOfSection3", "63.45");
> m.put("subtotalOfSection4", "89.15");
> m.put("discAmtFinanced", "63.25");
> for (Object fieldObj : acroForm.getFields())
> {
> PDField field = (PDField) fieldObj;
> if (m.get(field.getFullyQualifiedName()) != null) // set value of
> map when map key and pdf key is matched
> {
>
> field.setValue(m.get(field.getFullyQualifiedName()).toString());
> }
> }
>
> pdfDoc.save(new File("pdfbox_linux_issue-saved.pdf"));
> {code}
> Works in Windows, Linux Mint, Ubuntu as expected. Issue is only with Red Hat
> Enterprise 7.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4216) PDFBox decimal value cutting off in Red Hat Enterprise 7.4
[ https://issues.apache.org/jira/browse/PDFBOX-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471886#comment-16471886 ] Jim Halpert commented on PDFBOX-4216: - I put bunch of logs and ran the same code in Windows and Red Hat. Left side is Red Hat and Right is Windows output. The only difference is *linewidth* and *startOffset* in PlainTextFormatter#format() method. |+[n|#difference_1]+ |1|bbox = [0.0,0.0,68.34,9.360016]|+[n|#difference_1]+ |1|bbox = [0.0,0.0,68.34,9.360016]| | |2|clipRect = [1.0,1.0,67.34,8.360016]| |2|clipRect = [1.0,1.0,67.34,8.360016]| | |3|contentRect = [2.0,2.0,66.34,7.360016]| |3|contentRect = [2.0,2.0,66.34,7.360016]| | |4|clipRect.getLowerLeftX() = 1.0| |4|clipRect.getLowerLeftX() = 1.0| | |5|clipRect.getLowerLeftY() = 1.0| |5|clipRect.getLowerLeftY() = 1.0| | |6|clipRect.getWidth() = 66.34| |6|clipRect.getWidth() = 66.34| | |7|clipRect.getHeight() = 7.360016| |7|clipRect.getHeight() = 7.360016| |+[n|#difference_2]+ |8|Field = amtGapProtAmt formatter PlainTextFormatter [appearanceStyle=AppearanceStyle [font=PDType1Font Courier, fontSize=10.0, leading=10.55], wrapLines=false, width=64.34, contents=PDPageContentStream [document=org.apache.pdfbox.pdmodel.PDDocument@31fa7bbf, output=/Tx BMC|+[n|#difference_2]+ |8|Field = amtGapProtAmt formatter PlainTextFormatter [appearanceStyle=AppearanceStyle [font=PDType1Font Courier, fontSize=10.0, leading=10.55], wrapLines=false, width=64.34, contents=PDPageContentStream [document=org.apache.pdfbox.pdmodel.PDDocument@2957fcb0, output=/Tx BMC| | |9| | |9| | | |10|q| |10|q| | |11|1 1 66.4 7.36 re| |11|1 1 66.4 7.36 re| | |12|W| |12|W| | |13|n| |13|n| | |14|BT| |14|BT| | |15|/Cour 10 Tf| |15|/Cour 10 Tf| | |16|/DeviceGray cs| |16|/DeviceGray cs| | |17|0 sc| |17|0 sc| |+[n|#difference_3]+ |18|, [resources=org.apache.pdfbox.pdmodel.PDResources@33d2523b|mailto:resources=org.apache.pdfbox.pdmodel.PDResources@33d2523b], inTextMode=true, fontStack=[PDType1Font Courier], nonStrokingColorSpaceStack=[DeviceGray], strokingColorSpaceStack=[], [formatDecimal=java.text.DecimalFormat@674dc|mailto:formatDecimal=java.text.DecimalFormat@674dc], formatBuffer=[48, 48, 51, 54, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]], textContent=PlainText [paragraphs=[org.apache.pdfbox.pdmodel.interactive.form.PlainText$Paragraph@3514ba11]], textAlignment=RIGHT, horizontalOffset=2.0, verticalOffset=1.870008]|+[n|#difference_3]+ |18|, [resources=org.apache.pdfbox.pdmodel.PDResources@1376c05c|mailto:resources=org.apache.pdfbox.pdmodel.PDResources@1376c05c], inTextMode=true, fontStack=[PDType1Font Courier], nonStrokingColorSpaceStack=[DeviceGray], strokingColorSpaceStack=[], [formatDecimal=java.text.DecimalFormat@674dc|mailto:formatDecimal=java.text.DecimalFormat@674dc], formatBuffer=[48, 48, 51, 54, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]], textContent=PlainText [paragraphs=[org.apache.pdfbox.pdmodel.interactive.form.PlainText$Paragraph@51521cc1]], textAlignment=RIGHT, horizontalOffset=2.0, verticalOffset=1.870008]| | |19|lineWidth = 41.708984| |19|lineWidth = 48.007812| | |20|horizontalOffset = 2.0| |20|horizontalOffset = 2.0| |+[n|#difference_4]+ |21|startOffset = 22.69101|+[n|#difference_4]+ |21|startOffset = 16.392181| | |22|=| |22|=| | |23|bbox = [0.0,0.0,64.07999,9.360001]| |23|bbox = [0.0,0.0,64.07999,9.360001]| | |24|clipRect = [1.0,1.0,63.079987,8.360001]| |24|clipRect = [1.0,1.0,63.079987,8.360001]| | |25|contentRect = [2.0,2.0,62.079987,7.366]| |25|contentRect = [2.0,2.0,62.079987,7.366]| | |26|clipRect.getLowerLeftX() = 1.0| |26|clipRect.getLowerLeftX() = 1.0| | |27|clipRect.getLowerLeftY() = 1.0| |27|clipRect.getLowerLeftY() = 1.0| | |28|clipRect.getWidth() = 62.079987| |28|clipRect.getWidth() = 62.079987| | |29|clipRect.getHeight() = 7.366| |29|clipRect.getHeight() = 7.366| |+[n|#difference_5]+ |30|Field = discAmtFinanced formatter PlainTextFormatter [appearanceStyle=AppearanceStyle [font=PDType1Font Courier, fontSize=10.0, leading=10.55], wrapLines=false, width=60.079987, contents=PDPageContentStream [document=org.apache.pdfbox.pdmodel.PDDocument@31fa7bbf, output=/Tx BMC|+[n|#difference_5]+ |30|Field = discAmtFinanced formatter PlainTextFormatter [appearanceStyle=AppearanceStyle [font=PDType1Font Courier, fontSize=10.0, leading=10.55], wrapLines=false, width=60.079987, contents=PDPageContentStream [document=org.apache.pdfbox.pdmodel.PDDocument@2957fcb0, output=/Tx BMC| | |31| | |31| | | |32|q| |32|q| | |33|1 1 62.08 7.36 re| |33|1 1 62.08 7.36 re| | |34|W| |34|W| | |35|n| |35|n| | |36|BT| |36|BT| | |37|/Cour 10 Tf| |37|/Cour 10 Tf| | |38|/DeviceGray cs| |38|
REMINDER: Apache EU Roadshow 2018 schedule announced!
Hello Apache Supporters and Enthusiasts This is a reminder that the schedule for the Apache EU Roadshow 2018 in Berlin has been announced. http://apachecon.com/euroadshow18/schedule.html Please note that we will not be running an ApacheCon in Europe this year which means that this Apache EU Roadshow will be the main Apache event in Europe for 2018. The Apache EU Roadshow tracks take place on the 13th and 14th June 2018, and will feature 28 sessions across the following themes; Apache Tomcat, IoT , Cloud Technologies, Microservices and Apache Httpd Server. Please note that the Apache EU Roadshow is co-located with FOSS Backstage and their schedule (https://foss-backstage.de/sessions) includes many Apache related sessions such as Incubator, Apache Way, Open Source Governance, Legal, Trademarks as well as a full range community related presentations and panel discussions. One single registration gives you access to both events - the Apache EU Roadshow and FOSS Backstage. Registration includes catering (breakfast & lunch both days) and also an attendee evening event. And if you want to have a project meet-up, hack or simply spend time and relax in our on-site Apache Lounge between sessions, then you are more than welcome. We look forward to seeing you in Berlin! Thanks Sharan Foga, VP Apache Community Development PLEASE NOTE: You are receiving this message because you are subscribed to a user@ or dev@ list of one or more Apache Software Foundation projects.
[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation
[
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471604#comment-16471604
]
Tilman Hausherr edited comment on PDFBOX-4106 at 5/11/18 9:57 AM:
--
So the problem is that a TrueTypeFont object could be reused by several
threads, and the gsub feature vrt2 may be enabled in one and disabled in
another?
Re "fonts in FontBox must be thread safe" - this is not yet perfect. I have
been having trouble on some of my systems with Standard 14 fonts being used by
several threads (PDFBOX-4219). It happens only every 10 times, and recently
even less because one AIOOBE is avoided. (PDFBOX-4140)
was (Author: tilman):
So the problem is that a TrueTypeFont object could be reused by several
threads, and the gsub feature vrt2 may be enabled in one and disabled in
another?
Re "fonts in FontBox must be thread safe" - this is not yet perfect. I have
been having trouble on some of my systems with Standard 14 fonts being used by
several threads. It happens only every 10 times, and recently even less because
one AIOOBE is avoided. (PDFBOX-4140)
> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
> Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments:
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch,
> 0002-Optimize-Unicode-script-storage-and-lookup.patch,
> 0003-Parse-GSUB-table.patch,
> 0004-Abstract-cmap-lookup-into-an-interface.patch,
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch,
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch,
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch,
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch,
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch,
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch,
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch,
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch,
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch,
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch,
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch,
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch,
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch,
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch,
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but
> not used at all)
> I have attached a series of patches that implement the above features.
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups
> only; this is sufficient for many features including 'vert'/'vrt2' vertical
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if
> desired.
> Also attached is some sample code that exercises these patches and
> illustrates the effect of vertical glyph positioning. The sample output PDF
> is also attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4219:
Description:
I get rendering errors and sometimes exceptions in my regression tests. It is
somehow related to several threads initializing standard 14 fonts. It happens
only about every 25 times in a test program I created. That one renders 2 files
in 4 threads and compares the result with the existing result.
My theory is that one thread accesses the naming table and another accesses the
glyf table, and both change the stream position. I tried several things in the
last months to avoid it, all were unsuccessful and I lost my notes about it
last winter due to a static discharge on a usb stick. (Thank you KINGSTON!)
Here's the output when it doesn't go well:
{noformat}
11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-BoldMT for Galliard-Bold
11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-BoldMT for Galliard-Bold
11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPSMT for Galliard-Roman
11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPSMT for Galliard-Roman
11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-ItalicMT for Galliard-Italic
11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-ItalicMT for Galliard-Italic
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
oh oh
done
{noformat}
Sometimes in the past I got exceptions:
{noformat}
Exception in thread "Thread-2" java.lang.RuntimeException: java.io.IOException:
Unexpected end of TTF stream reached
at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
Caused by: java.io.IOException: Unexpected end of TTF stream reached
at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
at
org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
at
org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
at
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:478)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:156)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:258)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:225)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:164)
{noformat}
Sometimes I get an AIOOBE:
{noformat}
Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException
at
org.apache.fontbox.ttf.BufferedRandomAccessFile.read(BufferedRandomAccessFile.java:158)
at org.apache.fontbox.ttf.RAFDataStream.read(RAFDataStream.java:167)
at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:264)
at
org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
at org.a
[jira] [Updated] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4219:
Description:
I get rendering errors and sometimes exceptions in my regression tests. It is
somehow related to several threads initializing standard 14 fonts. It happens
only about every 25 times in a test program I created. That one renders 2 files
in 4 threads and compares the result with the existing result.
My theory is that one thread accesses the naming table and another accesses the
glyf table, and both change the stream position. I tried several things in the
last months to avoid it, all were unsuccessful and I lost my notes about it
last winter due to a static discharge on a KINGSTON usb stick.
Here's the output when it doesn't go well:
{noformat}
11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-BoldMT for Galliard-Bold
11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-BoldMT for Galliard-Bold
11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPSMT for Galliard-Roman
11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPSMT for Galliard-Roman
11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-ItalicMT for Galliard-Italic
11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-ItalicMT for Galliard-Italic
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
oh oh
done
{noformat}
Sometimes in the past I got exceptions:
{noformat}
Exception in thread "Thread-2" java.lang.RuntimeException: java.io.IOException:
Unexpected end of TTF stream reached
at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
Caused by: java.io.IOException: Unexpected end of TTF stream reached
at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
at
org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
at
org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
at
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:478)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:156)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:258)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:225)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:164)
{noformat}
Sometimes I get an AIOOBE:
{noformat}
Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException
at
org.apache.fontbox.ttf.BufferedRandomAccessFile.read(BufferedRandomAccessFile.java:158)
at org.apache.fontbox.ttf.RAFDataStream.read(RAFDataStream.java:167)
at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:264)
at
org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
at org.apache.fontbox
[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471692#comment-16471692
]
Tilman Hausherr commented on PDFBOX-4219:
-
I added examples of bad renderings. The third ("bad3") is the worst, in all
cases the glyph shapes get messed up.
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png,
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png,
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf,
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png,
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png,
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table. I did try several things in the last months to avoid it, all
> were unsuccessful and I lost my notes about it last winter due to a static
> discharge on a KINGSTON usb stick.
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
> at
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:478)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:156)
[jira] [Updated] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4219:
Attachment: 166292-fi-ligature.pdf-1-bad1.png
014261-p3-ccitt.pdf-1-bad1.png
014261-p3-ccitt.pdf-1-bad3.png
166292-fi-ligature.pdf-1-bad3.png
014261-p3-ccitt.pdf-1-bad2.png
166292-fi-ligature.pdf-1-bad2.png
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png,
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png,
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf,
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png,
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png,
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table. I did try several things in the last months to avoid it, all
> were unsuccessful and I lost my notes about it last winter due to a static
> discharge on a KINGSTON usb stick.
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
> at
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStre
[jira] [Updated] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4219:
Description:
I get rendering errors and sometimes exceptions in my regression tests. It is
somehow related to several threads initializing standard 14 fonts. It happens
only about every 25 times.
My theory is that one thread accesses the naming table and another accesses the
glyf table. I did try several things in the last months to avoid it, all were
unsuccessful and I lost my notes about it last winter due to a static discharge
on a KINGSTON usb stick.
Here's the output when it doesn't go well:
{noformat}
11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-BoldMT for Galliard-Bold
11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-BoldMT for Galliard-Bold
11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPSMT for Galliard-Roman
11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPSMT for Galliard-Roman
11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-ItalicMT for Galliard-Italic
11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-ItalicMT for Galliard-Italic
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
oh oh
done
{noformat}
Sometimes in the past I got exceptions:
{noformat}
Exception in thread "Thread-2" java.lang.RuntimeException: java.io.IOException:
Unexpected end of TTF stream reached
at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
Caused by: java.io.IOException: Unexpected end of TTF stream reached
at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
at
org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
at
org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
at
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:478)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:156)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:258)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:225)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:164)
{noformat}
Sometimes I get an AIOOBE:
{noformat}
Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException
at
org.apache.fontbox.ttf.BufferedRandomAccessFile.read(BufferedRandomAccessFile.java:158)
at org.apache.fontbox.ttf.RAFDataStream.read(RAFDataStream.java:167)
at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:264)
at
org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
at
org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
at
org.apache.pd
[jira] [Updated] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated PDFBOX-4219:
Labels: multi-threading multithreading (was: )
> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
> Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1.png,
> 166292-fi-ligature.pdf, 166292-fi-ligature.pdf-1.png, MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is
> somehow related to several threads initializing standard 14 fonts. It happens
> only about every 25 times.
> My theory is that one thread accesses the naming table and another accesses
> the glyf table. I did try several things in the last months to avoid it, all
> were unsuccessful and I lost my notes about it due to a static discharge last
> winter on a KINGSTON usb stick.
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException:
> java.io.IOException: Unexpected end of TTF stream reached
> at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
> at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
> at
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
> at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
> at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
> at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
> at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
> at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
> at
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
> at
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:478)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:156)
> at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:258)
> at
> org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:225)
> at
> org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:164)
> {noformat}
> Sometimes I get an AIOOBE:
> {noformat}
> Exception in
[jira] [Created] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
Tilman Hausherr created PDFBOX-4219:
---
Summary: Multithreading problem when rendering several documents
with Standard 14 fonts
Key: PDFBOX-4219
URL: https://issues.apache.org/jira/browse/PDFBOX-4219
Project: PDFBox
Issue Type: Bug
Components: FontBox, Rendering
Affects Versions: 2.0.9, 3.0.0 PDFBox
Environment: Windows 7
jdk1.8.0_172
Reporter: Tilman Hausherr
Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1.png,
166292-fi-ligature.pdf, 166292-fi-ligature.pdf-1.png, MulithreadTest.java
I get rendering errors and sometimes exceptions in my regression tests. It is
somehow related to several threads initializing standard 14 fonts. It happens
only about every 25 times.
My theory is that one thread accesses the naming table and another accesses the
glyf table. I did try several things in the last months to avoid it, all were
unsuccessful and I lost my notes about it due to a static discharge last winter
on a KINGSTON usb stick.
Here's the output when it doesn't go well:
{noformat}
11.05.2018 10:54:26.322 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-BoldMT for Galliard-Bold
11.05.2018 10:54:26.323 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-BoldMT for Galliard-Bold
11.05.2018 10:54:26.386 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPSMT for Galliard-Roman
11.05.2018 10:54:26.421 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPSMT for Galliard-Roman
11.05.2018 10:54:26.697 WARN [pool-1-thread-2]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-ItalicMT for Galliard-Italic
11.05.2018 10:54:26.818 WARN [pool-1-thread-4]
org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font
TimesNewRomanPS-ItalicMT for Galliard-Italic
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
oh oh
C:\Users\XXX\Documents\Java\PDFBox
reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
oh oh
done
{noformat}
Sometimes in the past I got exceptions:
{noformat}
Exception in thread "Thread-2" java.lang.RuntimeException: java.io.IOException:
Unexpected end of TTF stream reached
at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
Caused by: java.io.IOException: Unexpected end of TTF stream reached
at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
at
org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
at
org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
at
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
at
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:478)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:156)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:258)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:225)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:164)
{noformat}
Sometimes I get an AIOOBE:
{noformat}
Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException
at
org.apache.fontbox.ttf.BufferedRandomAccessFile.read(BufferedRandomAccessFile.java:158)
at org.apache.fontbox.ttf.RAFDataStream.read(RAFDataStream.java:167)
at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:264)
at
org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
at org.apache.fontbox.ttf.NamingTable.read(NamingTabl
[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation
[
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471604#comment-16471604
]
Tilman Hausherr edited comment on PDFBOX-4106 at 5/11/18 7:48 AM:
--
So the problem is that a TrueTypeFont object could be reused by several
threads, and the gsub feature vrt2 may be enabled in one and disabled in
another?
Re "fonts in FontBox must be thread safe" - this is not yet perfect. I have
been having trouble on some of my systems with Standard 14 fonts being used by
several threads. It happens only every 10 times, and recently even less because
one AIOOBE is avoided. (PDFBOX-4140)
was (Author: tilman):
So the problem is that a TrueTypeFont object could be reused by several
threads, and the gsub feature vrt2 may be enabled in one and disabled in
another?
Re "fonts in FontBox must be thread safe" - this is not yet perfect. I have
been having trouble on some of my systems with Standard 14 fonts being used by
several threads. It happens only every 10 times, and recently even less because
one AIOOBE is avoided.
> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
> Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments:
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch,
> 0002-Optimize-Unicode-script-storage-and-lookup.patch,
> 0003-Parse-GSUB-table.patch,
> 0004-Abstract-cmap-lookup-into-an-interface.patch,
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch,
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch,
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch,
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch,
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch,
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch,
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch,
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch,
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch,
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch,
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch,
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch,
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch,
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch,
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but
> not used at all)
> I have attached a series of patches that implement the above features.
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups
> only; this is sufficient for many features including 'vert'/'vrt2' vertical
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if
> desired.
> Also attached is some sample code that exercises these patches and
> illustrates the effect of vertical glyph positioning. The sample output PDF
> is also attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4106) Vertical text creation
[
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471604#comment-16471604
]
Tilman Hausherr commented on PDFBOX-4106:
-
So the problem is that a TrueTypeFont object could be reused by several
threads, and the gsub feature vrt2 may be enabled in one and disabled in
another?
Re "fonts in FontBox must be thread safe" - this is not yet perfect. I have
been having trouble on some of my systems with Standard 14 fonts being used by
several threads. It happens only every 10 times, and recently even less because
one AIOOBE is avoided.
> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
> Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments:
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch,
> 0002-Optimize-Unicode-script-storage-and-lookup.patch,
> 0003-Parse-GSUB-table.patch,
> 0004-Abstract-cmap-lookup-into-an-interface.patch,
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch,
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch,
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch,
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch,
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch,
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch,
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch,
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch,
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch,
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch,
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch,
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch,
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch,
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch,
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but
> not used at all)
> I have attached a series of patches that implement the above features.
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups
> only; this is sufficient for many features including 'vert'/'vrt2' vertical
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if
> desired.
> Also attached is some sample code that exercises these patches and
> illustrates the effect of vertical glyph positioning. The sample output PDF
> is also attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
