[
https://issues.apache.org/jira/browse/PDFBOX-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339085#comment-15339085
]
Tilman Hausherr commented on PDFBOX-3382:
-----------------------------------------
It doesn't matter which one you use, at this time the differences are only
related to Acroform and annotations.
Re encode: what is the usual length of the strings you send in showtext() ?
This is the code
{code}
public final byte[] encode(String text) throws IOException
{
ByteArrayOutputStream out = new ByteArrayOutputStream();
for (int offset = 0; offset < text.length(); )
{
int codePoint = text.codePointAt(offset);
// multi-byte encoding with 1 to 4 bytes
byte[] bytes = encode(codePoint);
out.write(bytes);
offset += Character.charCount(codePoint);
}
return out.toByteArray();
}
{code}
The default length for {{new ByteArrayOutputStream()}} is 32.
FlateFilter.encode likely won't be optimized, this is straightforward:
{code}
protected void encode(InputStream input, OutputStream encoded,
COSDictionary parameters)
throws IOException
{
DeflaterOutputStream out = new DeflaterOutputStream(encoded);
int amountRead;
int mayRead = input.available();
if (mayRead > 0)
{
byte[] buffer = new byte[Math.min(mayRead,BUFFER_SIZE)];
while ((amountRead = input.read(buffer, 0,
Math.min(mayRead,BUFFER_SIZE))) != -1)
{
out.write(buffer, 0, amountRead);
}
}
out.close();
encoded.flush();
}
{code}
I'll look for getwidth at a later time.
> pdf creation very slow
> ----------------------
>
> Key: PDFBOX-3382
> URL: https://issues.apache.org/jira/browse/PDFBOX-3382
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox, Writing
> Affects Versions: 2.0.2, 2.0.3, 2.1.0
> Reporter: kazu
> Priority: Minor
> Labels: optimization, performance
>
> compared to older 1.8.x versions, the new 2.0.x branch is awesomely slow.
> benchmarks using a multipage document with few images and many text-lines
> indiciate a performance penalty of about 1:20 compared with the old 1.8.x
> branch.
> profiling via VisualVM indicates that the new font handling causes this
> performance drawback:
> TrueTypeFont.nameToGid() [31%]
> TrueTypeFont.hasGlyph() [23%]
> PDFont.getWidth() [16%]
> PDType1Font.encode() [9%]
> is there any workaround for this? the current setup only creates about 10
> PDFs/second compared to over 200/second for the 1.8.x branch...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
