Gregor Müller created FOP-3338:
----------------------------------
Summary: ZUGFeRD/Factur-X compliance: media type (/Subtype) of
embedded files cannot be specified, always /application#2Foctet-stream
Key: FOP-3338
URL: https://issues.apache.org/jira/browse/FOP-3338
Project: FOP
Issue Type: Improvement
Reporter: Gregor Müller
## Description
org.apache.fop.pdf.PDFEmbeddedFile hard-codes
put("Subtype", new PDFName("application/octet-stream"));
in its constructor, and there is no setter. The pdf:embedded-file extension
element (org.apache.fop.render.pdf.extensions.PDFEmbeddedFileAttachment) only
supports the attributes filename, src and description.
Note that the type information is in many cases already available: a data:
URI in src (e.g. src="data:text/xml;base64,...") declares a mediatype, but
the resource resolver only uses the URI to obtain the content and the
declared mediatype is discarded.
As a result every embedded file in a FOP-generated PDF carries
/Subtype /application#2Foctet-stream.
Factur-X/ZUGFeRD — the use case for which FOP-2625 enabled PDF/A-3
attachments — requires the embedded factur-x.xml to carry
/Subtype /text#2Fxml. Invoice validators therefore reject FOP-generated
ZUGFeRD invoices, e.g.:
[VD-Valitool-H-007] Die eingebettete Datei hat den Medientyp
>application/octet-stream<, aber der Medientyp >text/xml< ist erforderlich.
## Proposal
Add an optional mime-type attribute to pdf:embedded-file and/or honor the
mediatype of data: URIs in src, and write it as the /Subtype of the embedded
file stream dictionary. application/octet-stream would remain the fallback
when no type information is available.
For full Factur-X compliance it would additionally be useful to support an
AFRelationship attribute written as /AFRelationship on the file specification
dictionary (and the /AF array in the document catalog), but the mime type is
the immediately blocking issue.
## Workaround
Post-process the generated PDF and replace
/Subtype /application#2Foctet-stream
with
/Subtype /text#2Fxml
padded with trailing spaces to the same byte length, so that the xref byte
offsets stay valid.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
