I've created a PDF/A-3 document with attached image files using iText 5.5.4. What I need is to add links in the body of the document to directly open the images.
I tried this to create the links :
PdfAnnotation linktoimg = PdfAnnotation.createFileAttachment
(writer, rectangle, "Open picture", fileSpec);
writer.addAnnotation(linktoimg);
Compilation is OK but at run time I get a PdfAConformanceException :
Annotation type /FileAttachment not allowed
I also tried to add an anchor to open the images but I've found that ISO-32000-1 specification doesn't support it. And the gotoEmbedded functions only works for attached PDF files.
So is there a way to achieve this or am I facing a limitation with PDF/A?
This is not a limitation of PDF/A-3 (or PDF/A-2). In fact, you have uncovered a bug in the iText PDF/A implementation. FileAttachment annotations are disallowed in PDF/A-1, but not in PDF/A-2 and PDF/A-3.
I have pushed a fix. It will be available in the develop branch of iText repository on GitHub soon. Alternatively, if you don't want to build from source, you can download a snapshot build from the iText repository
Related
Is there a method of linking to a heading in the same GFM README.md ("intra-readme" link) that works in both of the following situations?
(a) When formatted as HTML by GitHub
(b) When formatted as PDF by DITA-OT with Apache FOP
That is, I want something like (both of the following methods work in GitHub, but not in DITA-OT-built PDF):
[Link to custom anchor](#custom-anchor)
[Link to auto-generated anchor](#heading)
... intervening content ...
<a name="custom-anchor"></a>
## Heading
...
I think the answer is "No", but I thought I'd ask.
Some issues:
Auto-generated anchors, based on heading text, are incompatible: GitHub replaces spaces with hyphens (heading-text), whereas DITA-OT uses underscores (heading_text). It's occurred to me to write a DITA-OT XSLT override to change this behavior, but I'd prefer to avoid that.
DITA-OT supports Pandoc-style header attributes; GitHub doesn't.
DITA-OT Markdown processing generates a topic for each heading.
Background to this question
For now, I am deliberately and exclusively using README.md files to document a GitHub repo. I am not, for example, using GitHub Pages. Most directories in the repo contain a README.md file. For now, the readme content is enough.
Some users like docs in PDF. For those users, I have created a DITA map that refers to all of the README.md files, and I use the DITA Open Toolkit (DITA-OT) with Apache FOP to format that DITA map to PDF, resulting in a single PDF file that consolidates all of the content from the multiple readmes. I have my own reasons for using DITA-OT rather than, say, Pandoc. While I appreciate there are other ways to generate PDF from Markdown, I'm interested in DITA-OT-specific answers.
I can link from one readme to another ([Link text](subdir/README.md))—such links work in both GitHub-formatted HTML and DITA-OT-built PDF—but I can't figure out how to do "intra-README.md" links, hence this question.
What is the problem?
By using PDFBOX I tried to tag a link which contains annotation. The PDF creating sample code is here. I tagged a nested paragraph link by using PDFBOX. The newly created tagged PDF is passing the Adobe checker.
What I observed?
After tagging pdf I tried to read it using JAWS. But unfortunately the jaws is not reading links in both "entire document mode" and "read currently visible page" mode. Then I jumped to StructTree Root and compared with adobe created tagged PDF vs our tagged PDF. The ParentTree(NUMTree) is not matching with adobe tagged pdf.
Tagged by me
Tagged by Adobe
What I Tried?
I tried to replicate the adobe numtree in my pdf. Almost I am able to create same but except one object.
Above image left side is adobe tagged and right side is created by me. I didn't understand the adobe why it is created entire structtree under this (142 O R) object? I am adding annotation object to TumTree by using this code
private void addWidgetContent(PDObjectReference objectReference, PDStructureElement fieldElem, String type, int pageIndex) {
COSDictionary annotDict = new COSDictionary();
COSArray annotArray = new COSArray();
annotArray.add(COSInteger.get(currentMCID));
annotArray.add(objectReference);
annotDict.setItem(COSName.K, annotArray);
annotDict.setString(COSName.LANG, "EN-US");
annotDict.setItem(COSName.P, currentElem.getCOSObject());
annotDict.setItem(COSName.PG, pages.get(pageIndex).getCOSObject());
annotDict.setName(COSName.S, type);
annotDicts.add(annotDict);
setNextMarkedContentDictionary();
numDictionaries.add(annotDict);
fieldElem.appendKid(objectReference);
currentElem.appendKid(fieldElem);
}
And one more bug I saw in Adobe preflight is
How can I fix these bugs and what is the correct way of tagging link annotation to be read by JAWS? Please help me .......
I got some update to share. Now I crated parent tree root without having any bugs. Here the file tagged pdf file.
Still this tagged pdf not reading links. Why ?????????
I'm going from docbook to fo to pdf and I need to have text that goes to different parts of the document when clicked. I'm using the following format
<link linkend="M1350424Trace">
<emphasis role="bold">Link To Trace</emphasis>
</link>
Where M1350424Trace is the id of a paragraph. It works how I want it to work when I'm linking to something that comes later in the document but not when it's trying to link to something that comes earlier. Why is that?
Here's the .fo
<fo:basic-link internal-destination="M1350424Trace">
<fo:inline>
<fo:inline font-weight="bold">Link To Trace</fo:inline>
</fo:inline>
</fo:basic-link>
I've reproduced your case with the following input data:
Sample DocBook file with link and xref as a linkage mechanism
link and xref both and the target id are on different pages after rendering.
DocBook 5.1 as a source.
DocBook XSL 1.79.1 - as a stylesheets.
FOP 2.3 as a renderer.
The produced PDF file was tested with xpdf 3.04, Acrobat Reader 7.08 on Linux Debian 9.5
Works as should be: pressing the link moves to the page with a required element (para) with a required id number.
So you need to provide the exact file and exact configuration that raised this strange behavior. You can fill it with a dump data in case your document is under NDA or contains sensitive information, BUT it should be the same in matter of structure and elements within as an original one.
I'll try to reproduce your case.
I'am trying to show a pdf in a p:dialog , but i want to open pdf in a spécific destination, there is my code:
<p:commandLink value="test" oncomplete="PF('dlg').show()"/>
<p:dialog header="Dialog" widgetVar="dlg"
resizable="false"
fitViewport="true">
<pe:documentViewer height="500" width="800"
nameddest="nature"
name="helpImmo.pdf"/>
</p:dialog>
So the pdf is opened but in the first page
NB:when i use the page attribute it works
Attribute nameddest of pe:documentViewer can be used to open PDF in specific named destination which is technically different then bookmark.
To test if your code and project libraries work correctly, download this pdf example, include it into your project and in pe:documentViewer and set, for example, nameddest="Chapter3".
I've tested it with PF 6.1 and PF-extensions 6.1. It works OK on my side and opens requested named destination.
So make sure that
your PDF actually has named destination 'nature' created,
your version of PF-extensions does not have some known issue related to opening named destinations.
Also you can programmatically add named destinations to your PDF with iText java library as described in this example.
I am trying to add a custom footer to pdfs created from docx files on my liferay6.2 installation.
Specifically I have linked up open office, and I am successfully converting the documents from docx to pdf to embed them in my portal, but I want to add a 'pdf created on ' message as a footer.
I am open to doing this through liferay/java or through a setting in open office, but I can't find a way to do either at this time.
Thanks,
Joe
You will need to implement your own OpenOfficeDocumentConverter. The current implementation does this:
XComponent document = loadDocument(inputUrl, loadProperties);
refreshDocument(document);
storeDocument(document, outputUrl, storeProperties);
You could overwrite refreshDocument and do what you would like to do with the document (check the UNO API to find out how to change the document to add the footer).
Unfortunately you can't inject your converter with the spring configuration or portal.properties. Either you create an ext-plugin and replace the whole OpenOfficeDocumentConverter with your own implementation. Or you set DocumentConversionUtil._documentConverter using reflection to your extension.