[
https://issues.apache.org/jira/browse/PDFBOX-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029196#comment-15029196
]
John Hewson edited comment on PDFBOX-3133 at 11/26/15 7:10 PM:
---------------------------------------------------------------
Redirection to an XPS file is known to be slow, as explained in PDFBOX-3046.
This is the fault of Java's Printing API and there's not much we can do about
it. Likewise for printing to physical printers: Java's print drivers are really
slow with the output from PDFBox, for no good reason (it's because we render
our own fonts, but that's no excuse for the level of slowness encountered).
You should run PDFToImage and see how long it takes to generate a PNG file,
that way we eliminate print drivers from the equation. The speed of PDFToImage
represents the speed of PDFBox, if you get slower printing performance then
it's due to Java and we can't do anything.. If PDFToImage is slow then it's a
PDFBox issue which we can fix.
was (Author: jahewson):
Redirection to an XPS file is known to be slow, as explained in PDFBOX-3046.
This is the fault of Java's Printing API and there's not much we can do about
it. Likewise for printing to physical printers: Java's print drivers are really
slow with the output from PDFBox, for no good reason (it's because we render
our own fonts, but that's no excuse for the level of slowness encountered).
You should run PDFToImage and see how long it takes to generate a PNG file,
that way we eliminate print drivers from the equation. The speed of PDFToImage
represents the speed of PDFBox, if you get slower printing performance then
it's due to Java. If PDFToImage is slow then it's a PDFBox issue which we can
fix.
> PDFBox 2.0.0-RC2 and earlier 2.0.0 SNAPSHOT Versions print performance is
> poor with systems having low RAM < 3GB and lower number of fonts.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: PDFBOX-3133
> URL: https://issues.apache.org/jira/browse/PDFBOX-3133
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel
> Affects Versions: 2.0.0
> Environment: MS Windows Systems with low RAM < 3GB and number of
> fonts were less < 592 (or if desired fonts in PDF to be printed are not
> available in local system )
> Reporter: Sridhar
> Assignee: John Hewson
> Labels: performance
> Fix For: 2.0.0
>
>
> PDFBox 2.0.0-RC1, SNAPSHOTS and RC2 versions print takes 15+ seconds.
> Steps to reproduce
> --------------------------
> Use Windows System with < 3 GB RAM
> Use Systems with less number of fonts or without specific fonts in PDF file
> to be printed.
> Printing PDF file
> Took 14 to 20 seconds in system with 3 GB RAM which had 522 foints
> Took 24 to 34 seconds in system with 2 GB RAM which had 90 fonts
> Took only 2.5 seconds in system with 8 GB RAM which had 1025 fonts.
> Doubt
> --------
> Not browsed the code, but following is the doubt as causing performance issue.
> Though the code caches fonts by storing fonts in local .pdfbox.cache file
> first time and caching fonts for subsequent times.
> Not clear whether the code updates the pdfbox fonts cache file if new fonts
> are found in new PDF file to be printed, while printing subsequent times.
> If the fonts in PDF file to be printed is not available in the .pdfbox.cache
> file stored in local system/local system what is the behaviour? Will the
> code download fonts and update cache for subsequent times or is it limited by
> fonts available in local system? Looks like later is the case and
> performance got hit either due to RAM or not constantly updating fonts cache
> or due to un availability of fonts in local system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
