Choices when developing extensions and plug-ins for Adobe Creative Cloud and Document Cloud products
Most of Adobes Products has either come from other companies that have merged with Adobe Systems or have been in development for a considerable length of time. There is more than one way of creating extensions for most of Adobes products and especially the variation in developing graphical user interfaces.
Location of Adobe's current software developer kits and and CEP
Adobes SDKs (software development kits) are available from various links, but the most up-to-date set are available from Adobe.io for the latest iterations of Adobe products.
Beyond the GUI
Of course is a lot more to a plug-in or extension product then the user interface but generally this is the main element aiding or constraining cross-platform software development and of course the main part of a product that the user interacts with. The Adobe CEP interface is a big move to try and remove these constraints and to try and provide a consistent GUI across multiple products. Unfortunately one of our main development platforms is still Adobe Acrobat and this technology has not yet been adapted for this product.
Although PDF is an ISO standard and there are various other standards such as PDF/A and PDF/X that is supposed to improve its portability it can be made into a completely unportable format in a number of ways. Some of this unportability is imposed by Adobe themselves deliberately to keep some control over the format and the functionality of their products that work with the PDF format and some by 3rd parties. The question is how close is PDF to being truly portable across all devices and is this portability becoming better or worse over time.
A definition of PDF
This paragraph in the PDF 1.7 and ISO standard document is largely unchanged from early versions of the PDF specification and summarises the "ideal" for PDF:
The goal of PDF is to enable users to exchange and view electronic documents easily and reliably, independent of the environment in which they were created or the environment in which they are viewed or printed. At the core of PDF is an advanced imaging model derived from the PostScript® page description language. This PDF Imaging Model enables the description of text and graphics in a device-independent and resolution-independent manner. To improve performance for interactive viewing, PDF defines a more structured format than that used by most PostScript language programs. Unlike Postscript, which is a programming language, PDF is based on a structured binary file format that is optimised for high performance in interactive viewing. PDF also includes objects, such as annotations and hypertext links, that are not part of the page content itself but are useful for interactive viewing and document interchange.
So the big question is how close is PDF today in reaching this "goal" envisioned by its designers?
Adobe Imposed Unportability
Although Adobe allowed the PDF format to become an ISO standard it can be argued that it has continued along its path of treating PDF as its own proprietary format in a number of ways maybe in a bid to try and keep PDF users using their applications and technology rather than the third party products that this has spawned. This has been done in a number of ways:
Rights management and charging large fees to those companies that want to create there own DRM systems that allow files to be open in the free Adobe Reader. To most organisations these fees are often unaffordable.
Keeping XFA forms proprietary.
Introducing their own proprietary signing service.
Reader extensions to enable commenting on PDF files although with later versions of the Reader this has steadily become more relaxed.
Licensing and moving the goal posts. Does anyone remember Business Tools or Acrobat Exchange? If anybody wants to produce a plug-in for the Adobe Reader it has to be approved by Adobe first. So basically if a third party wants broad acceptance of their functionality Adobe still has the ability to say no. Recently Adobe has also tied down the Reader (RMSDK) that could be used by developers to modify the Reader on mobile devices. From Acrobat XI the ability to save comments on WebDav was removed forcing companies to start using the services on Acrobat.com.
There many other examples.
Opportunities for third parties to introduce Unportability
Although many third party developers will want to try and keep their PDF files as portable as possible, especially if they are creating tools to create PDF files, there will be others attempting to turn the PDF files into a proprietary format again.
Security handlers such as that produced by FileOpen Systems change the encryption in the PDF file according to encryption Algorithms known only to FileOpen. How many other security handlers are utilised is an unknown because this is information that is not published. For example, Mapsoft has created customised security handlers for several of our clients. These files are rendered useless outside the client environments and this is a deliberate action to ensure that these PDF file are not portable.
Data saved in PDF files from third party plugins and applications. Plugins often save information that is specific to them in the PDF file. Apart from the security handlers mentioned above there may be custom annotations, preference data and proprietary data formats that can be embedded into the file.
On numerous occasions my company has created custom annotations that become embedded in the PDF file. It is largely because the existing annotations don't provide the functionality required by the customer. This functionality is normally provided by a custom plug-in for Adobe Acrobat. Custom annotations normally have their appearances left in the PDF file so that the PDF can still be viewed without the Annotation handler present. This maintains the portability of the PDF files so that they can be viewed, but the ability to modify them is lost. See http://paperlessproofs.foxweb.com/default.htm for a great example
On many occasions we have received files from customers that appear to be sound only to find some glaring errors in the structure of the PDF file that is rendering it useless to any further processing or even viewing. The issue of corrupt fonts or incomplete font information is often a cause of problems. Rendering the file may be possible. We have seen instances where a PDF file will render on screen, but it can't be printed. The PDF file may be ok to render and then when further processing takes place such as the editing of images or text there is a failure inside Acrobat. On some files the extraction of text outputs gibberish because there wasn't enough information in the PDF file to translate the font encoding. Some font information it purely graphical and there is no way of reliably creating text from this information.
One of the most problematic areas of portability is on mobile devices. It would be nice to think that you could produce a PDF file in its entirety and expect it to work on iOS or Android devices, but even in the Adobe Acrobat Reader for Mobile on these devices this is not necessarily the case. An example I have come across recently is in the use of PDF forms. Now I am not talking about XFA forms which I believe is still a proprietary format but the standard forms that have been available for PDF since the 1.2 version of the standard. Up until the point where the 1.7 version of PDF became an ISO standard (ISO 32000), the version of PDF could be aligned with a specific version of Acrobat by adding the major and minor versions of PDF together. So we can deduce that PDF 1.2 was introduced for Acrobat 3 which was released in 1996. In any PDF form it should be possible to provide some level of interactivity for users and it is in this area where forms viewed on mobiles are severely lacking in their support. In recent work for a client we needed to introduce some functionality into the form for the following:
Showing hiding fields based on responses to previous questions on the form.
Showing form outlines in red when an entry is required and removing this when the field has been filled.
So PDF is no longer just PDF, but a series of fragmented standards. It could be argued that maintaining PDF as a proprietary format would have maintained its portability with one company (Adobe) being in charge of the format. However, a new version of PDF was being introduced by Adobe for every new version of Acrobat from PDF 1.0 to PDF 1.7 correlating with Acrobat versions 1 to version 8 and if it had continued as a proprietary format it is likely that this would have continued. I can clearly remember a time when one of the earlier versions of InDesign was generating PDF files that could only be viewed reliably in a very specific version of Acrobat. I can remember the day that I was horrified to find that one of our plug-ins for Acrobat (Mapsoft MaskIt) was masking PDF files that were showing as grey areas in Acrobat 7.0 and it wasn't until 7.0.6 was released that they were working properly.
Summary and Conclusion
So while PDF is one of the most portable file formats on the planet, it isn't perfect, but then what in life is? As a flat file format without the extra layer of Annotations PDF it is largely portable, but it is mainly in that upper layer that the portability problems creep in. As PDF is used in just about every industry, can be found of the majority of websites and there is hardly a person in the world with a computer that hasn't been exposed to it, lets hope that big strides are taken over the next few years to make this format truly portable. Now that PDF is an ISO standard it is the responsibility of the developer community to ensure that this happens. However, there will always be the commercial pressures to personalise PDF to create yet another sub-standard, but perhaps that is the beauty of the format.