Tag Archives: third parties

Adobe plugins

Why Plugins Matter?

Leave a reply

Plugging Plug-ins – Why Third-Party Software Matters

Any professional racing driver will tell you that there’s no such thing as too much power.  Give them a new, 1000-horsepower engine and after 5 laps, they’ll pull into the pits and say:  “Great, but can you give me 1100bhp?”   It’s just the same with software – especially software that’s as versatile as Adobe Acrobat and CC products such as Adobe InDesign, Adobe Illustrator and Adobe Photoshop.

The Inevitable Limitations of Software Applications

No matter how powerful, flexible or easy-to-use the application, as soon as users get to grips with it, they’ll find it doesn’t quite do exactly what they want it to.  Or they’ll want it to be just that bit easier to do a certain function or perhaps be able to batch functions together. This isn’t greed, or customers being niggly – on the contrary, it’s actually a compliment that the original application is proving useful.  It simply underlines that there’s no such thing as the perfect program.

Bridging User Needs with Third-Party Solutions

Users often don’t express their exact needs initially. Instead, they highlight desired improvements to existing solutions. This scenario opens opportunities for third-party developers and their plugins. These developers typically engage closely with user communities, such as forums, to understand their needs. Questions like “How can I do this?” or “Is there a tool for that?” signal potential market gaps.

For instance, repeated requests to mask sensitive information in PDF documents indicate a demand for new solutions. This was the case for Mapsoft. By aligning closely with the Adobe user community, Mapsoft identified and filled such needs, expanding its range of plugins.

Among its offerings, Impress Pro stands out. This plugin allows adding text stamps to documents, serving as watermarks or headers and footers. Other innovative solutions include MaskIt, for hiding confidential content, and DogEars, a tool that marks pages for easy reference, akin to a physical bookmark. Additionally, TOCBuilder offers the creation of a linked and printable table of contents, enhancing document navigation.

So what should you look for in a third-party developer?

Evaluating a Developer’s Endorsement and Partnerships

Firstly, consider if the developer is endorsed by the main vendor’s partner programme. This is crucial. For instance, Mapsoft, an Adobe Business Partner, boasts over 30 years of experience developing plugins for Adobe products.

Assessing Product Integration with Main Vendor’s Technology

Secondly, evaluate how the developer’s products integrate with the main vendor’s technology. Products should be developed using the main vendor’s core technology to ensure reliability and seamless functionality. Mapsoft exemplifies this by licensing A dobe’s core technology for their plugins and customized products.

Opportunities for Product Evaluation

Thirdly, check if the product can be evaluated before purchase. This is vital to ensure it meets user needs. Developers confident in their solutions typically offer evaluation versions. Mapsoft, for example, provides free evaluation versions of all their plugins on their website.

Developer Support and User References

Finally, consider the developer’s support and the availability of user references. This indicates a long-term commitment to quality and customer satisfaction. With over 30 years in the sector and partnerships with high-profile companies like Network Rail, Xerox, and Hallmark Cards, Mapsoft demonstrates its expertise and dedication. They also offer one year of free support for their software solutions.

Conclusion

By keeping these points in mind, you can ensure you choose effective and reliable plugins that enhance your main application, streamline tasks, and add valuable features and functionality.

Contact info:

mpeters@creativeaddonshub.com

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

https://creativeaddonshub.com

 Related Links:

How Portable is PDF?

Leave a reply

Although PDF is an ISO standard, it also includes various other standards like PDF/A and PDF/X, intended to enhance its portability. Nonetheless, several factors can render it unportable. Adobe deliberately imposes some of these limitations to maintain control over the format and the functionality of their products, such as Adobe Acrobat, that interact with PDFs. Third parties impose additional limitations.

The question is how close PDF is to being truly portable across all devices and whether this portability is improving or worsening over time. Let’s examine the initial definition of PDF.

A definition of PDF

The early PDF specification versions have largely stayed the same in this section for PDF 1.7, PDF 2.0, and the ISO standard, outlining the PDF ‘ideal’.

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

Adobe has made PDF an ISO standard. Yet, some argue Adobe still treats it like a proprietary format. This strategy may aim to keep users within Adobe’s ecosystem, favoring applications like Adobe Acrobat. Adobe employs several methods to achieve this.

  • 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 (a cut down version of Adobe Acrobat)? 

Anybody who wants to produce a plug-in for the Adobe Reader must first receive Adobe’s approval. Essentially, even if a third party seeks broad acceptance for their functionality, Adobe retains the right to reject it. Recently, Adobe restricted access to the Reader (RMSDK) that developers could use to modify the Reader on mobile devices. Starting from Acrobat XI, Adobe removed the ability to save comments on WebDav, forcing companies to use Acrobat.com services instead.

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. Users or systems can embed custom annotations, preference data, and proprietary data formats into the file, apart from the security handlers mentioned above.

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 leave their appearances in the PDF file, allowing the PDF to be viewed even without the Annotation handler. This approach maintains the PDF files’ portability, enabling viewing while removing the ability to modify them.

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. 

A 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. You might think producing a PDF to work seamlessly on iOS or Android is straightforward. However, even Adobe Acrobat Reader for Mobile on these platforms doesn’t guarantee it.

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. Before the 1.7 version of PDF became an ISO standard (ISO 32000), you could align the version of PDF with a specific version of Acrobat by adding the major and minor versions of PDF together. Therefore, we can deduce that the introduction of PDF 1.2 was for Acrobat 3, 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.

I would argue that neither of the above expectations are unreasonable. However, the Adobe Reader for iOS or Android does not support them due to the simple fact that it supports a tiny JavaScript object model. I have yet to find a third-party viewer that actually documents what they support in this area.

ISO Standards

PDF is no longer just a standard format; it has fragmented into multiple standards. One could argue that if Adobe had maintained PDF as a proprietary format, it would have preserved its portability with Adobe solely in charge of the format.

However, Adobe introduced a new version of PDF with every new Acrobat release, from PDF 1.0 to PDF 1.7, corresponding with Acrobat versions 1 through 8. Had it remained proprietary, Adobe likely would have continued this practice.

I vividly recall a period when an early version of InDesign could only generate PDF files that Acrobat’s very specific version reliably viewed. I remember feeling horrified the day I discovered that our Acrobat plug-in (Mapsoft MaskIt) was creating PDF files that appeared as grey areas in Acrobat 7.0. It wasn’t until the release of 7.0.6 that they started working properly.

This revision eliminates passive constructions and makes the narrative more engaging and straightforward.

We also have versions of PDF for specific industries or purposes such as PDF/A and PDF/X.

Summary and Conclusion

PDF is one of the most portable file formats, yet it’s not without flaws. Its flat file nature ensures broad portability, but the upper layer of Annotations often introduces issues. PDFs are ubiquitous across industries and websites, with nearly everyone using a computer familiar with them. We hope for significant improvements in the coming years to enhance its portability. 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

Associated Links: