[
https://issues.apache.org/jira/browse/PDFBOX-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18004596#comment-18004596
]
Ilgoo Kim edited comment on PDFBOX-6032 at 7/11/25 3:26 AM:
------------------------------------------------------------
{quote}So if I get it correct, your source bytes are a PNG, but it is not
possible to convert this into a PDImage, as it uses some encoding not supported
by the PNGConverter? And the issue is, that it than falls back to the normal
lossless PNG encoder which is of course not the fastest in the world, as it
uses ZIP compression etc.
{quote}
Yes, that's correct. Our editor users upload various types of images. Some of
them are PNG images that aren't supported by the {{{}PNGConverter{}}}, so they
fall back to the default lossless encoder.
{quote}In this case I would personally prefer to just make an overloaded
createFromByteArray() method which takes a FileType for the fallback encoding.
And let the one without the FileType argument just pass FileType.PNG as the
fallback encoding.
{quote}
If there's an overloaded {{createFromByteArray()}} that takes a
{{{}FallbackEncodingType{}}}, I'm concerned it would require creating a
{{BufferedImage}} every time, which could degrade performance. In our
customized codebase, we defer the check until the final fallback step, after
the {{BufferedImage}} has been created.
Alternatively, would it be possible to provide an overloaded version of
{{createFromByteArray()}} that accepts a functional interface to customize the
final fallback behavior?, which is inside the following condition:
if (fileType == FileType.BMP || fileType == FileType.GIF || fileType ==
FileType.PNG)
{ fallbackStrategy.create(document, byteArray, name); }
, where fallbackStrategy is defined as follows:
{code:java}
@FunctionalInterface
public interface FallbackImageStrategy {
PDImageXObject create(PDDocument document, byte[] byteArray, String name)
throws IOException;
}{code}
was (Author: JIRAUSER310139):
{quote}So if I get it correct, your source bytes are a PNG, but it is not
possible to convert this into a PDImage, as it uses some encoding not supported
by the PNGConverter? And the issue is, that it than falls back to the normal
lossless PNG encoder which is of course not the fastest in the world, as it
uses ZIP compression etc.
{quote}
Yes, that's correct. Our editor users upload various types of images. Some of
them are PNG images that aren't supported by the {{{}PNGConverter{}}}, so they
fall back to the default lossless encoder.
{quote}In this case I would personally prefer to just make an overloaded
createFromByteArray() method which takes a FileType for the fallback encoding.
And let the one without the FileType argument just pass FileType.PNG as the
fallback encoding.
{quote}
If there's an overloaded {{createFromByteArray()}} that takes a
{{{}FallbackEncodingType{}}}, I'm concerned it would require creating a
{{BufferedImage}} every time, which could degrade performance. In our
customized codebase, we defer the check until the final fallback step, after
the {{BufferedImage}} has been created.
Alternatively, would it be possible to provide an overloaded version of
{{createFromByteArray()}} that accepts a functional interface to customize the
final fallback behavior?, which is inside the following condition:
if (fileType == FileType.BMP || fileType == FileType.GIF || fileType ==
FileType.PNG)
{ fallbackStrategy.create(document, byteArray, name); }
, where fallbackStrategy is defined as follows:
{code:java}
@FunctionalInterface
public interface FallbackImageStrategy {
PDImageXObject create(PDDocument document, byte[] byteArray, String name)
throws IOException;
}{code}
> Issues encountered while customizing "PDImageXObject"
> ------------------------------------------------------
>
> Key: PDFBOX-6032
> URL: https://issues.apache.org/jira/browse/PDFBOX-6032
> Project: PDFBox
> Issue Type: Wish
> Components: PDModel
> Affects Versions: 3.0.5 PDFBox
> Reporter: Ilgoo Kim
> Priority: Major
>
> In my team, we are using PDFBox to add an PDF-export feature to our editor
> service.
> Unfortunately the performance does not meet our expectations, especially
> when LosslessFactory is invoked within the "createFromByteArray" function of
> PDImageXObject.
> Therefore we customized the "createFromByteArray" function to favor
> JPEGFactory over LosslessFactory in order to improve performance, even at the
> cost of some image quality loss. (based on the criteria through a
> pixel-by-pixel alpha check)
> However, bringing the "createFromByteArray" function into our project
> introduces a problem: since "PNGConverter" is not public, we are forced to
> copy the entire "PNGConverter" class into our codebase as well.
> I was wondering if it would be possible to make the "PNGConverter" class
> public, or alternatively, if there is a recommended way to better customize
> the "createFromByteArray" function.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
