You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (JIRA)" <ji...@apache.org> on 2018/01/05 07:13:00 UTC
[jira] [Commented] (PDFBOX-4051) Different DestOutputProfiles in
OutputIntentArray after PDFMergerUtility.Merge leads to non-conformity
[ https://issues.apache.org/jira/browse/PDFBOX-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16312590#comment-16312590 ]
Tilman Hausherr commented on PDFBOX-4051:
-----------------------------------------
This is by design... you could call setOutputIntents() if you know which one is to be in the list. Here's the current code, that might help:
{code}
// copy outputIntents to destination, but avoid duplicate OutputConditionIdentifier,
// except when it is missing or is named "Custom".
private void mergeOutputIntents(PDFCloneUtility cloner,
PDDocumentCatalog srcCatalog, PDDocumentCatalog destCatalog) throws IOException
{
List<PDOutputIntent> srcOutputIntents = srcCatalog.getOutputIntents();
List<PDOutputIntent> dstOutputIntents = destCatalog.getOutputIntents();
for (PDOutputIntent srcOI : srcOutputIntents)
{
String srcOCI = srcOI.getOutputConditionIdentifier();
if (srcOCI != null && !"Custom".equals(srcOCI))
{
// is that identifier already there?
boolean skip = false;
for (PDOutputIntent dstOI : dstOutputIntents)
{
if (dstOI.getOutputConditionIdentifier().equals(srcOCI))
{
skip = true;
break;
}
}
if (skip)
{
continue;
}
}
destCatalog.addOutputIntent(new PDOutputIntent((COSDictionary) cloner.cloneForNewDocument(srcOI)));
dstOutputIntents.add(srcOI);
}
}
{code}
I don't think a new setter is needed but feel free to suggest something... we can't know which one is the "good" output intent. Maybe your result file looks fine, or maybe there are subtle changes that you and me won't notice, but a person specialized in printing would.
> Different DestOutputProfiles in OutputIntentArray after PDFMergerUtility.Merge leads to non-conformity
> ------------------------------------------------------------------------------------------------------
>
> Key: PDFBOX-4051
> URL: https://issues.apache.org/jira/browse/PDFBOX-4051
> Project: PDFBox
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 2.0.6
> Reporter: Joerg Neumann
> Priority: Minor
> Attachments: 2018-01-05 07_14_30-Validation Report.jpg
>
>
> Hi ... not sure if thats a bug or not, so i just shoot:
> Im merging some pdfs that conform to the pdfa-1b standard with PdfMergerUtility.merge.
> The result has to be pdfa-1b conform as well.
> So my code is like
> {code:java}
> public ByteArrayOutputStream merge(final List<InputStream> sources) throws IOException {
> try (
> ByteArrayOutputStream mergedPDFOutputStream = new ByteArrayOutputStream();
> COSStream cosStream = new COSStream()
> ) {
> PDFMergerUtility pdfMerger = createPDFMergerUtility(sources, mergedPDFOutputStream);
> PDDocumentInformation pdfDocumentInfo = createPDFDocumentInfo(TITLE, CREATOR, SUBJECT);
> PDMetadata xmpMetadata = createXMPMetadata(cosStream, TITLE, CREATOR, SUBJECT);
> pdfMerger.setDestinationDocumentInformation(pdfDocumentInfo);
> pdfMerger.setDestinationMetadata(xmpMetadata);
> pdfMerger.mergeDocuments(MemoryUsageSetting.setupMainMemoryOnly());
> return mergedPDFOutputStream;
> } catch (BadFieldValueException | TransformerException e) {
> throw new IOException("PDF merge problem", e);
> } finally {
> for (InputStream source : sources) {
> try {
> source.close();
> } catch (IOException e) {}
> }
> }
> {code}
> This works fine if the pdfs come from the same source, e.g. have similar OutputIntents described in their catalogs.
> But when i mix documents that have different OutputIntents like
> {code:java}
> /OutputIntents
> [
> <<
> /Type /OutputIntent
> /S /GTS_PDFA1
> /OutputConditionIdentifier (sRGB)
> /RegistryName (http://www.color.org)
> /DestOutputProfile 36 0 R
> >>
> ]
> {code}
> and
> {code:java}
> <</OutputIntents[<</Info(Adobe RGB \(1998\))/S/GTS_PDFA1/Type/OutputIntent/DestOutputProfile 1 0 R/OutputConditionIdentifier(Adobe RGB \(1998\))>>]/Metadata 16 0 R/Type/Catalog/StructTreeRoot 15 0 R/MarkInfo<</Marked true>>/Pages 4 0 R>>
> {code}
> the PdfMergerUtility seems to concat them with different DestOutputProfiles:
> {code:java}
> 4 0 obj
> <<
> /Type /OutputIntent
> /S /GTS_PDFA1
> /OutputConditionIdentifier (sRGB)
> /RegistryName (http://www.color.org)
> /DestOutputProfile 17 0 R
> >>
> endobj
> 5 0 obj
> <<
> /Info (Adobe RGB \(1998\))
> /S /GTS_PDFA1
> /Type /OutputIntent
> /DestOutputProfile 18 0 R
> /OutputConditionIdentifier (Adobe RGB \(1998\))
> >>
> endobj
> {code}
> and therefore its no longer conform thanks to Specification: ISO 19005-1:2005, Clause: 6.2.2
> !2018-01-05 07_14_30-Validation Report.jpg|thumbnail!
> when i manually change the file (with a notepad) from "/DestOutputProfile 18 0 R" to "/DestOutputProfile 17 0 R" the file again gains conformity.
> I might be able to re-parse the merged document as PDDocument and modify the OutputIntent-Array in the Catalog, but i dont think thats how it was intended?
> So am i doing something wrong or should PdfMergerUtility not only get a setter for DocumentInformation and MetaData, but some manual way to influence the Outputintents?
> Thanks already.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org