Subject: [IPP] Fwd: Question - IPP Job Ticket for 3D PDF's

From: Ira McDonald via ipp <[email-masked]>
Date: Thu, 8 Apr 2021 16:09:26 -0400

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

  - Opens up the issue of providing alternate encodings for IPP other than
"application/ipp"
    - How does our PJT work dovetail with this?

    - 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?

Cheers,
- Ira

---------- Forwarded message ---------
Date: Sun, Apr 4, 2021 at 8:35 PM
Subject: [SC] Question - IPP Job Ticket for 3D PDF's

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.

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.

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?

Also do you have any opinions about whether this would be a good idea or
not?

Thanks.

Best Regards,

/Paul

*Paul Tykodi*
Principal Consultant

Tykodi Consulting Svcs LLC

Phone:

(603) 343-1820

3 Lowell Ave

Cell:

(603) 866-0712

Dover, NH 03820

Fax:

(603) 343-1820

USA

E-mail:

[email-masked]

www.tykodi.com

Skype:

Tykodiconsultingservices

Co-Chair               - IEEE-ISTO PWG IPP Working Group

This e-mail message and any attachments are confidential and may be
privileged.

If you are not the intended recipient, please notify Tykodi Consulting
Services LLC

immediately by replying to this message and destroying all copies of this
message

_______________________________________________
SC mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/sc
_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet via ipp <[email-masked]>
Date: Fri, 9 Apr 2021 07:02:43 -0400

Ira/All,

> On Apr 8, 2021, at 4:09 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> After discussion at this Monday's PWG Steering Committee call, we recorded the following
>   - 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"

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*

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 <[email-masked]> 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

---

From: wamwagner--- via ipp <[email-masked]>
Date: Fri, 9 Apr 2021 12:55:05 -0400

Mike has addressed the question of encoding in the most reasonable way. However, from the discussion at the IPP workgroup,  it appears that there is a more fundamental question of  whether we (IPP or PWG) should even consider an effort toward stand-alone job tickets or should we just be encouraging the use of the IIPP protocol. (Yes, I recognize the redundancy.) I believe that, in developing IPP, the PWG has provided two significant contributions to computer-based printing. One is that  IPP provides an approach that can be applied to many services whereby a service identifies its available output capabilities  to a potential client;  the client can then request use of the service using  those available capabilities that produce the product the client  wants. This is a very effective approach, and I am surprised that it  is not used by services other than printing (perhaps it is.) However, to allow this approach to work, there must be a concise lexicon that unambiguously identifies all of the aspects of service product that the service is capable of providing and that the client  can request. Besides forming the attribute and attribute values for IPP, this is also an effective vocabulary for a stand-alone job ticket. This lexicon is the second, and perhaps even more significant contribution of IPP to the industry, in that it can be used in circumstances where interactive client/sever exchange is not feasible.  I suggest that it is consistent with the PWG mission that we invest some reasonable effort to identify a sustainable approach to generating a  jobticket lexicon from the IANA IPP registry.
Thanks, 
 Bill Wagner

From: Ira McDonald via ipp
Sent: Thursday, April 8, 2021 4:09 PM
To: [email-masked]; Michael Sweet; Ira McDonald
Subject: [IPP] Fwd: Question - IPP Job Ticket for 3D PDF's

Hi,

Comments?

Cheers,
- Ira

---------- Forwarded message ---------
Date: Sun, Apr 4, 2021 at 8:35 PM
Subject: [SC] Question - IPP Job Ticket for 3D PDF's

Hi Mike,

 

Thanks.
 
Best Regards,
 
/Paul

Paul Tykodi
Principal Consultant

3 Lowell Ave
Cell:
(603) 866-0712
 
Dover, NH 03820
Fax:
(603) 343-1820
 
USA
E-mail: 
[email-masked]
 
www.tykodi.com
Skype:
Tykodiconsultingservices

 
This e-mail message and any attachments are confidential and may be privileged.
If you are not the intended recipient, please notify Tykodi Consulting Services LLC 
immediately by replying to this message and destroying all copies of this message