Table 345 references View Params dictionary instead of 3D node dictionary

[bdoubrov]

This issue is somewhat similar to #127

Table 345 defines PDF 2.0 extension of 3D node dictionary (Table 323) adding two new entries to it. In fact, these new entries are already present in Table 323.

But the original text of Section 13.7.2.3.6 and Table 345 speaks about new entries in the View Params dictionary, which actually does not exist in PDF 2.0 (the closest would be 3D view dictionary).

I would suggest to replace "View Params" by "3D node" everywhere in Section 13.7.2.3.6 as well as in Table 323, Data entry description.

There are also other problems in Section 13.7.2.3.6, which might require more rewording:

• 13.7.2.3.6.1 General is confusing, as it speaks about some general purpose mechanism to pass custom Data to the 3D instance. However, further text explains that Data is used solely to store and load opaque data.
• The format how this Data is serialized is not specified, which might cause interoperability issues
• the section uses a boldface term View, which is reserved for predefined names in PDF spec. But in fact it means just a general concept of a 3D view (or just a view) as used in Section 13.6.4.1 3D views - General.

[petervwyatt]

"Adobe Supplement to the ISO 32000 BaseVersion: 1.7 ExtensionLevel: 3" originally defined the RichMedia data structures, but specifically for their implementations and proprietary technologies. I suggest you review that original proposal to see if we accidentally cut any important information when merging into ISO that was platform-independent / generic and non-proprietary.

[bdoubrov]

Indeed, originally in Adobe Supplement spec the View params dictionary was a separate type referenced by the View dictionary, which is defined (ISO 32000-2, Table 344) as an extension of 3D View dictionary. The supplement (Table 9.51f) was adding two new entries to the 3D View dictionary: Snapshot and Params, and the latter one was referencing View params dictionary.

As far as I can see, in ISO 32000-2 all entries of this View params dictionary (Instance and Data) were added to the 3D node dictionary (Table 323), which is not fully correct: one of these newly added entries (Instance) makes sense only for RichMedia annotations, while 3D node dictionary is used both for 3D and for RichMedia annotations.

It is not clear, if the newly added Data entry (Table 323) should make sense for 3D node annotations as well. If this is the goal, then its description should be revised in Table 323 to avoid the term "instance", which is used only for RichMedia annotations. If Data entry is supposed to make sense only for RichMedia annotations, then I would suggest to remove both Instance and Data entries from Table 323 leaving their definition to Table 345 (at the moment they are present in both tables) and then clearly defining Table 345 as an extension of 3D node dictionary used for RichMedia annotations.

The Adobe Supplement also clarifies a bit the definition for the Data value linking it with the data property of the JavaScript StateEvent. Far from being rigorously defined, it at least provides a hint where to find examples for this data format.

[petervwyatt]

@lrosenthol to do some archeology

[lrosenthol]

A RichMediaContent dictionary can contain an array of 3D View Dictionaries as the value of the Views key. The 3D View dictionary has a bunch of standard 3D "things" in it but when used for RM can also contain the new Snapshot and *Params keys, as defined in Table 344. The definitions in 32K-2 match those in the Adobe docs. The value of Params is a View Params dictionary defined in Table 345 with Instance and Data keys. The definitions in 32K-2 match those in the Adobe docs.

All of the above only applies to RM - it has nothing to do with classic 3D.

As described in 32K, the value of the Data key is designed to be specific/private to either the RM asset type (as it was for Flash/SWF), ECMAScript state, or possible viewer private. In other words, it's a RM-specific private area.

[lrosenthol]

I believe everything is correct and no action needs to be taken

[petervwyatt]

Waiting for @bdoubrov to attend for confirmation.

[datalogics-pgallot]

As a side-note: 32k-2 has a section 13.7.2.3.6.3 (Loading state data) that says that "For 3D content, an ECMAScript StateEvent is invoked with the type property set to the value load and the data property set to the value stored for Data.". However, this information is not found in the ISO 21757 (ECMAScript for PDF) specification, where it might also be relevant.

[petervwyatt]

@datalogics-pgallot That probably warrants a separate issue logged against ISO 21757 (ECMAScript for PDF 2.0) since there is a clear disconnect between the 2 ISO standards.

[bdoubrov]

Sorry for confusion, I might have been looking not at the latest version of ISO 32000-2:2020, in which Params entry was not present in Table 344. I see this entry added to Table 344 with a note: "This key was accidently omitted from earlier PDF 2.0 specifications and was reinstated in the 2020 dated revision of this document." Which explains the origin of this confusion.

The only issue left is the compatibility of Data value with ECMAScript, which would indeed make sense to report as a separate issue against ECMAScript.

So, I agree with @lrosenthol that no changes required in Section 13.7.2.3.6 "View params dictionary".

[petervwyatt]

Closing with no changes