Third Light Developer Exchange

mtaylor

Member

Registered: 2021-04-26

Posts: 4

PDF PICTURE vs DOCUMENT File Type

From version 3.3 (possibly before), it seems that PDFs can either have a file type PICTURE or DOCUMENT.
Creating derivatives in Chorus seems to change this setting, but what exactly in Chorus determines whether the API lists PDFs as one or the other?

To give more context, we are trying to identify if a PDF has a single page or many pages. Is the IMAGE type a reliable indicator that a PDF is only one page, as this is a requirement for image type PDFs in our system?

Thanks for any clarification.

dominic

Third Light Staff

Registered: 2013-06-06

Posts: 119

Re: PDF PICTURE vs DOCUMENT File Type

Hi,

There is currently an inconsistency for derivatives vs original files as to the reported type for PDF/AI files. This relates to two competing semantics: the usability of the type for image-based operations, and the typical end-user purpose (and hence, how it is displayed).

Type IMAGE is not a good way of determining single vs multi-page PDFs - at present, page data are not exposed in the REST API, but the JSON API Files.GetDetails method does include extra information (including `pages` and `pageDetails`), which would satisfy your requirement.

Dominic

mtaylor

Member

Registered: 2021-04-26

Posts: 4

Re: PDF PICTURE vs DOCUMENT File Type

Thanks for the information. Based on your response, does this mean the PICTURE type for derivatives is likely to revert in future versions?

Our solution so far has been written with the REST API, is the page count ever likely to be available in future through the REST API, or is the JSON API the recommended interface going forward?

https://roi.chorus.thirdlight.com/apido … ileDetails is this were we should be looking?

dominic

Third Light Staff

Registered: 2013-06-06

Posts: 119

Re: PDF PICTURE vs DOCUMENT File Type

Hi,

The REST API is recommended for use wherever possible, and we are expanding its capabilities with each release - however the JSON API (as used by the Chorus web app) is much larger, and sometimes is the only way to achieve a particular goal. The key downside of the JSON API - and the reason we recommend the REST API - is that it is maintained for internal use, and thus method signature or response compatibility between Chorus versions is not guaranteed.

I see you have linked to the GRPC docs - that has the same methods and data signatures as REST, but benefits from wide language support for generating client bindings. It also benefits from an InternalAPI.Do method, which allows the use of arbitrary JSON API methods, to make it easier to build an integration that needs to make occasional use of such features.

It is likely that some level of page information will be included in the REST API in future, however there is no current schedule for such an addition.

Dominic