Search This Blog

Wednesday, 18 December 2019

DiamondTouch Table and Adobe Acrobat Integration



The worlds first multi-user touch table and a plug-in developed by Mapsoft running under Adobe Acrobat.


Contact:

Michael Peters
mpeters@mapsoft.com
https://www.linkedin.com/in/mpmapsoft/
http://www.mapsoft.com

Options for Developing User Interfaces in Adobe Products


Graphical User Interface (GUI) support and 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. If And particularly the variation is in developing graphical user interfaces. Adobe Illustrator for example requires the use of HTML and JavaScript. Adobe Acrobat supports native user interfaces on both Windows and Mac platforms although until recent versions that used to have its own user interface technology called ADM (Adobe Dialog Manager). The same technology was also used in Adobe Illustrator, however over the last few versions of the products this technology has been removed. For Adobe Acrobat there is an example plug-in using wxWidgets (https://www.wxwidgets.org/) an open source library which can be used across both Windows and Mac platforms but unfortunately this just means having to educate developers on yet another user interface technology, Adobe Indesign probably provides most options in supporting its own resource format and also HTML5.

If Extensions for a lot of Adobes Creative Cloud products can also is be supplied as hybrid extensions and plug-ins using HTML JavaScript and also native plug-ins within the same package and product. This array of different technologies is not made any easier by the fact that over the last years Adobe has created technologies and then consigned them to history. At one point the most of  the Creative Suite (precursor to the Creative Cloud) products supported user interfaces based on Flash and then that was discontinued in preference to using HTML 5, CSS 3 and JavaScript and is known as the Adobe common extensibility platform (CEP). Adobe Acrobat, a part of both the Document Cloud and the Creative Cloud follows its own development path in not using this technology.

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.

CEP is advertised as a platform for those not wanting to use C++. For many products this is certainly the case that there are definitely constraints where a decision has to made if enough of the developer interface has been exposed to produce the product that is required. This will vary from product to product. However for interaction, speed, multithreading and extensive task handling using the software developer kits natively is often the only option. An example of this is our integration of SMART boards and Adobe Illustrator where the CEP technology just wasn't sufficient. However CEP does have support for Node.js as this will bring in an extensive number of JavaScript libraries. However most of these applications are client based and so this is generally only useful in a client server type environment and the plug-in interfaces are nearly all C++ for which there is also a very extensive (probably more extensive) set of libraries that can be used.

Contact:

Michael Peters
mpeters@mapsoft.com
https://www.linkedin.com/in/mpmapsoft/
http://www.mapsoft.com

Tuesday, 17 December 2019

SMART integration with Adobe Illustrator using an Adobe Illustrator Plug-in

SMART integration with Adobe Illustrator using an Adobe Illustrator Plug-in


Enhance design & product review meetings by using SMART visual collaboration solutions with the popular vector graphics editor Adobe Illustrator.

Technologies Used

SMART White Board

Adobe Illustrator

Adobe Illustrator SDK

Contact Information

Michael Peters

https://www.linkedin.com/in/mpmapsoft/

mpeters@mapsoft.com

http://www.mapsoft.com



How Portable is PDF?

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

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.

Custom Data

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.
Custom Annotations

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

Unintended Unportability

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.

Mobile Use

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.


Neither of the above I would argue are unreasonable expectations, However neither of these are supported in the Adobe Reader for iOS or Android for the simple fact that the JavaScript object model supported is tiny. I have yet to find a third party viewer that actually documents what they do support in this area.
ISO Standards

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.

Contact information:

Michael Peters