Ira/All,
> On Apr 8, 2021, at 4:09 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi,
>> Please first look at Paul Tykodi's note and attachment below.
>> After discussion at this Monday's PWG Steering Committee call, we recorded the following
> resolution in the minutes:
>> PWG and Embeddable Job Tickets
> - Discussion
> - Plan discussed was to create a "reference embeddable job ticket" and put it on the FTP site, in
> some encoding
The embeddable Job Ticket format we came up with almost 4 years ago is the XML-based PJT3D whose schema is generated from the IANA IPP registry. And given the current (limited) capabilities of PDF, I *do* think that XML (which allows for embedding of its own) is probably the way to go.
But I don't think that is the question we need to answer (see below).
> - Opens up the issue of providing alternate encodings for IPP other than "application/ipp"
> - How does our PJT work dovetail with this?
Where we left it 4 years ago was that we proved we can programmatically generate an XML schema for any IPP service from the IANA IPP registry, and that any future development of the Semantic Model schema should be based on *that* to ensure 100% fidelity between the IPP and XML encodings.
Given that CBOR now has CDDL and JSON has JSON Schema [1], I suspect that we'd be able to do the same for those encodings fairly easily.
[1]: https://json-schema.org
> - Figuring this out is a task for the IPP WG - Ira and Mike to consider this
>> I do NOT propose to add this as a work item in the revised IPP WG Charter. However, I *do*
> encourage discussion in the IPP WG.
>> Comments?
Here is a copy of my original response to Paul's question. For the TL;DR crowd, the issue is that PDF metadata only allows a single blob of metadata per file and per object, and recording the job receipt will require rewriting the PDF file which can be problematic. The job ticket is only a small part of the metadata that manufacturers need to track, and much more detail is needed on where to place the job ticket and how to mix it with other metadata to achieve interoperability.
> Paul,
>>> On Apr 4, 2021, at 8:35 PM, Paul Tykodi <ptykodi at tykodi.com> wrote:
>>>> Hi Mike,
>>>> The PDF Association recently published the attached release note covering metadata stored within a PDF file. I participated in a short meeting with Duff Johnson (PDF Association Executive Director) and Phil Spreier (Technical Director 3D PDF Consortium – PDES) a few weeks ago and Duff represented to me that he felt the attached document could provide PWG with information it would need to insert a job ticket into a 3D PDF file.
>> This isn't, by itself, sufficient to specify how to embed a 3D job ticket into a PDF file.
>> First, a PWG Job Ticket applies to the whole document, but I don't see us replacing the document catalog metadata.
>> Second, if we assume they think a separate Job Ticket object should be present for each 3D artwork object (so multiple embedded Job Tickets per document...) then we need to either a) provide all of the metadata others need or b) embed the PWG schema in the larger 3D metadata schema, with a corresponding specification to standardize where our embedded job ticket goes in the larger XML.
>> Third, because there can only be a single Metadata object referenced, and because the Job Ticket is not a passive object (it also contains the Job Receipt), we'll need a specification that explains how to amend the PDF file so that the various PDF implementers (*not* just Adobe) get it right.
>> Incidentally, this is why I don't like bypassing IPP and embedding the data in the documents... Too much chance that something will get broken along the way. What we really need is something like blockchain (hey, a valid use for it! :) that records/logs the events of a Job's or Document's lifecycle so that the original document is not modified along the way.
>>> The use case is that we imagine a future where Adobe possibly extends the Adobe PDF Print Engine and creates a new APPE-3D version. The purpose is to provide 3D printer manufacturers with a software component they can add into their product so that their equipment can consume a 3D PDF and print the 3D content without needing to transform the 3D content into an alternative file format for internal processing.
>> That's great for Adobe, but that's *not* a focus for the PWG.
>>> If the use case was to then reliably deliver a 3D PDF file to a 3D printer, using IPP semantics for job ticket but not necessarily the IPP protocol for delivery, would the attached document actually help describe how to place the job ticket semantics into the 3D PDF file itself?
>> No.
>>> Also do you have any opinions about whether this would be a good idea or not?
>> For Adobe to sell their PDF engine to 3D printer manufacturers? I really don't care, and as someone that has implemented both sides of the stack I don't know how useful that would be. While Adobe historically has included poorly defined "features" in PDF in order to make life harder for their competitors (linearization and the various "security handlers" are easy examples), once you get past reading the document catalog and xref table you just need to extract the 3D content to process with your own slicer - it's not rocket science.
>> As for using this application note as an example of how to embed a 3D job ticket into a PDF, I think there is a use for it but this document is insufficient.
________________________
Michael Sweet