Author Archives: admin

Camelot Project – the Precursor to PDF and Acrobat

Leave a reply

The Camelot Project

J. Warnock

This document describes the base technology and ideas behind the project named “Camelot.” This project’s goal is to solve a fundamental problem that confronts today’s companies. The problem is concerned with our ability to communicate visual material between different computer applications and systems. The specific problem is that most
programs print to a wide range of printers, but there is no universal way to communicate and view this printed information electronically. The popularity of FAX machines has given us a way to send images around to produce remote paper, but the lack of quality,
the high communication bandwidth and the device specific nature of FAX has made the solution less than desirable. What industries badly need is a universal way to communicate documents across a wide variety of machine configurations, operating systems and communication networks. These documents should be viewable on any display and should be printable on any modern printers. If this problem can be solved, then the fundamental way people work will change.

The invention of the PostScript language has gone a long way to solving this problem. PostScript is a device independent page description language. Adobe’s PostScript interpreter has been implemented on over 100 commercially available printer products.
These printer products include color machines, high resolution
machines, high speed machines and low-cost machines. Over 4000 applications output their printed material to PostScript machines.
This support for PostScript as a standard make the PostScript
solution a candidate for this electronic document interchange.

Within the PostScript and Display PostScript context the “view and print anywhere” problem has been implemented and solved. Since most applications have PostScript print drivers, documents from a wide variety of applications can be viewed from operating systems that use Display PostScript. PostScript files can be shipped around communication networks and printed remotely. “Encapsulated PostScript” is a type of PostScript file that can be used by many applications to include a PostScript image as part of a page the application builds.

The reason the Display PostScript and PostScript solutions are not a total solution in today’s world is that this solution requires powerful desktop machines and PostScript printers. The Display PostScript and PostScript solutions are the correct long-term solution as the power of machines increases over time, but this solution offers little help for the vast majority of today’s users with today’s machines.

The Camelot Project is an attempt to define technologies and
products that will give the value that Display PostScript and
PostScript delivers to the vast number of installed machines that exists today. For the purposes of this discussion these machines include 640K Intel 286/386/486 machines (PC compatibles), Apple Macintosh machines, mainframes, and workstations. The displays must include CGA, EGA, VGA and any other higher resolution or color displays supported by the above machines.

Our vision for Camelot is to provide a collection of utilities,
applications, and system software so that a corporation can
effectively capture documents from any application, send electronic versions of these documents anywhere, and view and print these documents on any machines.

There are at least two technical approaches to the Camelot project. Both solutions depend on the PostScript technology. One approach is to try to make Display PostScript and PostScript implementations smaller and faster so that they can run on the vast majority of today’s machines. This approach has been tried and is extremely difficult.

A second approach is to divide the problem into smaller problems. This approach would allow each piece to run independently on the smaller machines while achieving acceptable performance and a solution for the complete problem. This latter approach requires that the problem be divided in a way that is natural for users, and provides a solution for every user. An approach to the Camelot project will now be described that will divide the problem into smaller pieces. This solution depends on a unique property of the PostScript language.

PostScript, as an interpretive language, has some properties that other interpretive languages do not have. In particular, the semantics of operators is not fixed. Operators can be redefined to have any desired behavior. This property of PostScript allows the execution of a PostScript file to have side effects that are very different from the normal printing of a page. An example might be instructive. Suppose a PostScript file draws 10 sided polygon with the following PostScript procedure:

				
					/poly 

    {1 0 moveto 

        /ang 36 def 

        10 {ang cos ang sin lineto 

         /ang ang 36 add def 

     }repeat 

 }def

This procedure will build a path that is a ten sided polygon. In this procedure the verbs: “moveto” and “lineto” have the standard semantics of building a PostScript path within the PostScript Language.

By redefining “moveto” and “lineto” very different things can
happen. For example, if these operators are defined as follows:

				
					/moveto 

    {exch writenumber writenumber (moveto) writestring}def 

/lineto 

    {exch writenumber writenumber (lineto) writestring}def

then when the “poly” procedure is executed a file is written that has the following contents:

				
					1.0 0.0 moveto 

0.809 0.588 

lineto
0.309 0.951 

lineto
-0.309 0.951 

lineto
-0.809 0.588 

lineto
-1.0 0.0 

lineto
-0.809 -0.588 

lineto
-0.309 -0.951 

lineto
0.309 -0.951 

lineto
0.809 -0.588 

lineto
1.0 0.0 

lineto

In this example the new redefined “moveto” and “lineto” definitions don’t build a path. Instead they write out the coordinates they have been given and then write out the names of their own operations.
The resulting file that is written by these new definitions draws the same polygon as the original file but only uses the “moveto” and “lineto” operators. Here, the execution of the PostScript file has allowed a derivative file to be generated. In some sense this derivative file is simpler and uses fewer operators than the original PostScript file but has the same net effect. We will call this operation of processing one PostScript file into another form of PostScript file “rebinding.“

The above example illustrates a capability of the PostScript language that is not frequently used. This “rebinding” of the language, however, is extremely valuable. The Camelot project depends on variations on this idea.

The approach we will take with Camelot is to define a new language of operators and conventions. For the purposes of this discussion we will call this language “Interchange PostScript” or IPS. IPS will primarily contain the graphics and imaging operators of PostScript.
The language will be defined so that any IPS file is a valid PostScript file. The file will have the appropriate baggage so that it is a valid EPS file. IPS files will print on PostScript printer and will be able to be used by applications that accept EPS files. IPS will also be structured so that the complete PostScript parser is not necessary to read any file written in IPS. IPS will have an adequate set of operators so that any practical document expressed in PostScript can be represented in IPS. There will be situations in IPS where the IPS file cannot represent visual situations that can be theoretically generated in PostScript. However we believe these situations are extremely rare, and all practical application documents can be represented efficiently in IPS. The right way to think about IPS is as it relates to English. No person in the world knows every English word, but a small subset of the English words, and certain usage patterns enable people to consistently communicate.

Once we have defined IPS, we will build a version of the PostScript interpreter (IPS binder) that will read any PostScript file and rebind that file into an IPS file. The IPS binder can be quite small in that it does not need the graphics, font or device machinery contained in full PostScript interpreter. Another function of the IPS binder will be to include reconstituted fonts into the IPS file. The idea here is to include just the characters of a font that are actually used in the document. A result of including the necessary characters from the fonts used is that an IPS file will be completely self contained. In other words, when I send a file around the country, I don’t have to worry about whether the receiving location has all the fonts required
by the document. The current situation is that complex font
substitution schemes are used to deal with locations not having the appropriate fonts.

Once IPS is defined and the IPS binder implemented, then users can capture any PostScript file emitted by a PostScript driver, and convert that file to a self contained IPS file. This file can be shipped anywhere around the network and printed on any PostScript machine (management utilities will be written to ease this printing process.)

In addition to the IPS binder, a viewer and browser will be written that will read IPS files, and render those files on displays or to dumb raster printers. It is believed that IPS interpreters can be substantially simpler, and smaller than full PostScript interpreters. It is also believed that an IPS interpreter can have acceptable performance on small machines. The real hope is to make the IPS viewer and browser small enough so that it can co-exist with other applications. It is interesting to think about what those applications can be.

One obvious application for the IPS viewer is in its use in electronic mail systems. Imagine being able to send full text and graphics documents (newspapers, magazine articles, technical manuals etc.) over electronic mail distribution networks. These documents could be viewed on any machine and any selected document could be printed locally. This capability would truly change the way information is managed. Large centrally maintained databases of documents could
be accessed remotely and selectively printed remotely. This would save millions of dollars in document inventory costs.

Specific large visual data bases like the value-line stock charts,
encyclopedias, atlases, Military maps, Service Manuals, Time-Life Books etc. could be shipped on CD-ROM’s with a viewer. This would allow full publication (text, graphics, images and all) to be viewed and printed across a very large base of machines.

Imagine if the IPS viewer is also equipped with text searching
capabilities. In this case the user could find all documents that
contain a certain word or phrase, and then view that word or phrase in context within the document.
Entire libraries could be archived in electronic form, and since IPS files are self-contained, would be printable at any location.

One of the central requirements of the Camelot Project is that the IPS file format is device independent. This is essential because it is necessary to be able to print the documents on color or black and white machines — on low or high resolution machines. This requirement is also essential in order to visualize the documents at various magnifications on the screen. For example, it is imperative that the user be able to magnify portions of complex maps, so that subportions of the image are easy to read even on low resolution displays.

To accomplish the above requirement it is necessary that consistent font rendering machinery be available to the viewer. For this reason the viewers will need to contain the full ATM implementations as part of each system.

In considering all the requirements of corporations regarding
documents, it is important to structure Camelot components so that they can be sold in ways that are useful to the corporations. Several ideas have come to mind.

Components of Camelot are generally not interesting to single users. The exception to this is in the distribution of large generally useful databases. If someone produced a CD-ROM with “maps of the world” on it, then one can imagine selling a retail package with one viewer and the CD-ROM.

In most other applications, the distribution of information is to many people. In these latter cases a corporation would like a copy of the viewer for every PC. One can imagine viewers integrated into mail systems, or as general stand-alone browsing systems. In any event corporations should be interested in site-licensing arrangements.
(more to come)

Author: John Warnock

Editor for the purposes of this page: Michael Peters

Associated Links:

History of PDF

Leave a reply

A Short History of PDF (Portable Document Format)

Adobe Systems made the PDF specification available free of charge in 1993. In the early years PDF was popular mainly in desktop publishing workflows and the first PDF Export was created for PageMaker 5 by Mapsoft. PDF competed with a variety of formats such as DjVu, Envoy, Common Ground Digital Paper, Farallon Replica and even Adobe’s own PostScript format.

Released as an ISO standard

PDF was a proprietary format controlled by Adobe until it was released as an open standard on July 1, 2008, and published by the International Organization for Standardization as ISO 32000-1:2008,[5][6] at which time control of the specification passed to an ISO Committee of volunteer industry experts. In 2008, Adobe published a Public Patent License to ISO 32000-1 granting royalty-free rights for all patents owned by Adobe that are necessary to make, use, sell, and distribute PDF-compliant implementations.[7]

PDF 1.7, the sixth edition of the PDF specification and the version accompanying Acrobat version 8 became ISO 32000-1, includes some proprietary technologies defined only by Adobe, such as Adobe XML Forms Architecture (XFA) and JavaScript extension for Acrobat, which are referenced by ISO 32000-1 as normative and indispensable for the full implementation of the ISO 32000-1 specification. These proprietary technologies are not standardized and their specification is published only on Adobe’s website, and many of them are also not supported by popular third-party implementations of PDF.

In December, 2020, the second edition of PDF 2.0, ISO 32000-2:2020, was published, including clarifications, corrections and critical updates to normative references.[13] ISO 32000-2 does not include any proprietary technologies as normative references.[14]

Information taken in part from Wikipedia

Author: Michael Peters

Mapsoft is a member of the PDF Association https://pdfa.org/.

Summary of the Structure of PDF files

Leave a reply

Deeper Insight into the Complex Structure of PDF Files and Their Key Components.

PDF file format structure can be looked upon as a combination of different file types presented in a single container. The reason for this is that a PDF file contains Text, vector art, images, fonts and other file format can be embedded – even the native files that were used to create the PDF in the first place.

The complex structure of PDF files consists of objects where items can be connected directly or indirectly to each other. Often the indirection is because an object might is used multiple times as would be the case for a logo, font, color.

The objects within a PDF file can be divided into the following types:

Dictionaries

A group containing direct or references to indirect objects. Dictionaries can be seen as the glue holding together the elements in a PDF files. The example below shows the structure of a typical page dictionary:

The Contents stream has an attributes dictionary that contains a filter name and the length of the stream

The CropBox array contains the coordinates of the rectangle that defines the area that is visible on the page.

The MediaBox array contains the coordinates of the rectangle that defines the media size. This will typically match a standard media size such as Letter or A4 and will allow the PDF page to be reliably printed on a device that contains these standard media sizes.

The Resources dictionary contains references and information for elements that are needed to reliably output the visual elements of the page such as colors, fonts and Images.

Streams

The collection of operators outputting information onto the page. Normally the stream will also require elements of the page resources dictionary such as colors and fonts. Streams are either stored as a single element or in an array.

				
					q
567.48 61.011 -540 720 re
W* n
q
/GS0 gs
0 720 -541.1399536 0 567.4799194 61.0105438 cm
/Im0 Do
Q
Q
/CS0 cs 0.302 0.302 0.302  scn
1 i 
/GS1 gs
56.7 286.911 m
56.7 295.191 56.7 303.471 56.7 311.751 c
59.1 311.751 61.5 311.751 63.9 311.751 c
63.9 306.831 63.9 301.911 63.9 296.991 c
65.88 296.991 67.8 296.991 69.72 296.991 c
69.72 301.191 69.72 305.391 69.72 309.591 c
72 309.591 74.22 309.591 76.5 309.591 c
76.5 305.391 76.5 301.191 76.5 296.991 c
81.06 296.991 85.62 296.991 90.18 296.991 c
90.18 293.631 90.18 290.271 90.18 286.911 c
79.02 286.911 67.86 286.911 56.7 286.911 c
f*

You can see that there are several references to items in the page resources dictionary:

GS0 is a reference to a graphics state and gs is the operator that sets it.

Im0 is an XObject image and the Do operator draws the image.

CS0 is a reference to a color dictionary and the scn operator assigns it to strokes.

You can also see usage of several path operators re – rectangle, m – moveto, c – curve f* – fill.

Text strings

These can either be ANSI (single byte characters) or Unicode (multi-byte). The example here is the representation of the last date modified in the catalog dictionary.These can either be ANSI (single byte characters) or Unicode (multi-byte). The example here is the representation of the last date modified in the catalog dictionary.

Images

Images are normally held within the page resources and the stream will also have an associated Attributes dictionary that will describe the attributes of the data within the stream. BitsPerComponent size of the data that is used to define a single pixel (dot) within the image. The ColorSpace dictionary describes the colour model that is used to define the colors within the image.

Names

Used normally to provide a name that can be used to refer to a dictionary or dictionary item. For example, the pages dictionary has a name “Type” with the value “Pages” and a single page has a name of “Type” with a value of “Page”.

Arrays

Fixed length data holding types and/or references to other elements. For an example see the Real Numbers example below.

Real numbers

Decimal numbers. In this example they are being used to define the rectangle of the page media box:

Integers

Whole numbers. For example to show the total number of pages in the PDF file.

For further details on pdf file format structure see the PDF Specification at https://www.adobe.com/devnet/pdf/pdf_reference.html

Contact:

Michael Peters

Associated Links:

Understanding of Color and Color models

Leave a reply

Understanding Color Models: A Beginner's Guide to Color Theory

I am only going to cover 2 of the many color models here because they are the most often used.

RGB

This color model is primarily used to describe light. It is used mainly in cameras and scanners. It has 3 color elements that when added together at 100% represent white or pure light. The 3 different colors are Red, Green and Blue. The color model is almost infinite in its range and this in itself is ok until printing is required and that printing is being done through the CMYK color model. The model uses 3 values with each being in a range between 0 and 255 as in the Windows and applications such as Photoshop or as a decimal number up to a maximum of 1 in PDF for example.

RGB is an additive color model. Adding all of the colors in equal amounts will result in white.

In the web world RGB colours are represented by hex number combinations (the numbering system is ). So for example Red would be #FF0000, Green would be #00FF00 and Blue would be #0000FF. Black is #000000 and White is #FFFFFF.

CMYK

What color model is used in printed designs? This is usually Cyan/Magenta/Yellow/Black (CMYK) color model and is mainly used in color printing.

Printing the colors on top of each other creates the colors necessary to achieve the required shades. Overlaps may be necessary at the edges (trapping) to prevent visibility of spaces as different paper types can expand and shrink when applying ink/toner. Compared to RGB, the CMYK color model offers a much more limited range, necessitating careful conversion from RGB to CMYK. Color management systems, the addition of extra colors to the print run (such as Hexachrome), or the use of pre-mixed Spot colors like Pantone can accomplish this. The resolution of the input and output and the paper stock used in printing, including the surface quality and base color of the media type as well as the ink attributes, affect printing. Moreover, varnishes such as UV and foils can modify and enhance output effects and colors to provide metallic effects.

The CMYK color model assigns 4 values, each representing a percentage of the four colors: cyan, magenta, yellow, and black.

CMYK operates as a subtractive color model, where adding all colors in equal amounts theoretically results in black. However, CMYK typically produces a dirty color, so incorporating the K (black) achieves a true black for printing.

This is a simple look at color and I will expand on this in a future blog.

Contact info:

Michael Peters

Associated Links:

Recommended Book

Victor Perez’s “The Color Management Handbook for Visual Effects Artists” is a vital resource aimed at demystifying color management for VFX professionals. This guide, grounded in research from leading color scientists, navigates through the nuances of high dynamic range (HDR) and Academy Color Encoding System (ACES) workflows. It’s designed to educate artists at all levels, ensuring a solid grasp of color management principles to enhance the quality of visual effects globally. This comprehensive book covers from basic color theory to sophisticated digital imaging techniques, promoting a unified approach from camera to screen.

What is an Acrobat Plugin?

Leave a reply

What is an Acrobat Plugin?

An Adobe Acrobat plugin is a software component that can extend the functionality of the Adobe Acrobat reader/viewer application, a popular program for viewing, creating, and editing PDF documents. Plugins can add new features to Acrobat, such as the ability to create interactive forms, add watermarks, or perform advanced document processing tasks. Some plugins are developed by Adobe, while others are created by third parties. These plugins can be installed within the Acrobat application such as our TOCBuilder plugin are typically activated when a particular action or task is performed within the software.

Adobe Acrobat Reader plugin

Why do we need plugins?

To make Adobe Acrobat more flexible and applicable to a broader range of industries and organizations, the number of built-in features must be restricted to the wider community. This is because adding features that serve only a small portion of Acrobat’s user base would unnecessarily increase the application’s size. Consequently, plugins are required to add functionality as required by the user.

Can Acrobat plugins be used in the Adobe Reader?

Special support needs to be added to the plugin so that it can run under Adobe Reader. However the Reader plugin will require a special license and needs to go through an approval process with Adobe Systems Inc. – https://www.adobe.com/devnet/reader/ikla.html.

Are plugins specific to a particular version of Adobe Acrobat?

We have plug-ins that we developed for Acrobat 6 that still run without modification in Acrobat DC. However, if new features are used that are specific to a later version then it won’t work under later versions. If earlier versions used the Adobe Dialog Manager (ADM) then they won’t now work in current versions of Acrobat.

Update:

Probably the biggest change in this last year was the introduction of the 64bit version of Acrobat which has also meant the rebuilding of our Acrobat Plugins to support it.. This has basically meant a rebuild of all plug-ins so that they will run on both platforms. In this process we decided to remove a number of our products that are now decades old and concentrate on maintaining and improving a subset of the products.

Examples of Plugins

New security handlers that might be specific to a particular organisation. For example, we have developed security handlers that do not allow PDF files to be viewed outside a particular organisations offices.
New annotations types. For example, we created a plugin that supported all of the British Standard Markups.
Flattening annotations and form fields into the main document. This ensured that they could not be changed or modified and that they would print as part of the document even if the printing of annotations was switched off.
Adding text and images to PDF files.
Creating a table of Contents for PDF files
Automating the creation of bookmarks based on the styles in a pdf file.
Adding fields for variable data printing
Hardware integration of Adobe Acrobat into whiteboards and interactive tables

Contact Info:

Michael Peters

http://mapsoft.com

Associated Links:

DiamondTouch Table and Adobe Acrobat Integration

Leave a reply

DiamondTouch Table and Adobe Acrobat Integration

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

Transcript

(00:00) hello my name is adam bogue and this is the diamond touch table

(00:04) it’s the first instill only multi-user touch

(00:07) technology capable of supporting multiple simultaneous users

(00:12) and it knows who’s who here let me show you how diamond touch is different than

(00:16) other multi-touch displays that you might have seen before (00:22) so obviously this is a touch screen but the thing that makes it different

(00:26) is that diamond touch is multi-user and i have a little demo that illustrates

(00:30) what i mean by that so when i touch it’s blue and

(00:35) when these guys touch do you see how each of us is a different color (00:40) no matter where you touch diamond touch knows who’s who (00:43) and the point here is we wanted to create a new type of computer interface (00:47) to support small group face-to-face collaboration

(00:51) laptops tablets smartphones those were all designed for individual users

(00:57) of course you can use these devices to connect to other individuals

(01:01) but if you’re in the same place with other people and you’re trying to work

(01:04) together you know these devices get in the way

(01:07) that’s why people often print things out when they’re going to meet

(01:11) the best a traditional computer can do is to let one person drive while

(01:15) everybody else kind of looks over that person’s shoulders

(01:18) and that’s no good with diamond touch everybody can be face to face

(01:22) and everyone can drive at once so here’s my desktop my finger’s a mouse

(01:30) here’s another big difference between diamond touch and other touch screens

(01:33) you know how windows only has one cursor well right now i have it

(01:38) and if someone tries to take it from me they can’t have it until i let go and

(01:44) then they can have it this is a subtle point but other touch

(01:48) screens can’t do that other touch screens kind of freak out

(01:51) when multiple people touch the cursor jumps around and you’d never

(01:55) get anything done that’s why most tabletop touch screens

(01:59) avoid the frustration by making it only work with special

(02:03) applications specifically designed for their hardware

(02:06) whereas diamond touch works with anything

(02:14) that’s a double click my fist is a scroll wheel (02:19) yeah you got it now because most business software is

(02:24) single user what we’ve been doing is to make other people’s software

(02:28) multi-user aware and here’s an example diamond touch can be used by engineers

(02:32) and architects for design review meetings

(02:35) of course a long time ago these design review meetings

(02:38) took place about a large piece of paper a blueprint or a schematic

(02:43) and people were face to face now with everything done in cad

(02:48) people are making their design review comments in the computer

(02:51) one person at a time and it’s a lot less efficient

(02:55) people don’t have the opportunity to be face to face

(03:02) so this is a drawing of a building it’s a pdf

(03:06) what we did is we made a plug-in tool for adobe acrobat that lets you

(03:10) do some new things it makes it diamond touch or multi-user aware

(03:14) first of all you can do the two-finger zoom this is a pan gesture

(03:18) now if we’re doing commenting for design review

(03:21) we can do it multi-user style so we have these tools here this is mine

(03:26) and that’s yours when i draw here you can see that shows

(03:31) up here in the comment pane with my name on it

(03:34) now when you guys draw right so we can all be working at the same

(03:39) time here i can highlight this text i can open up a tool like this

(03:50) and automatically a keyboard pops up if you’re meeting with a client you can

(04:02) capture the customer approval right here in the document with these

(04:05) stamps and again because we know who’s who

(04:07) we know who it was that approved the document and when

(04:11) and when this is another example of something that you can only do

(04:16) on the diamond touch table because it knows who’s who

(04:19) not just multi-touch multi-user touch

Video Summary

The video features Adam Bogue introducing the Diamond Touch table, a unique multi-user touch technology that supports multiple simultaneous users and distinguishes between them.

Unlike other multi-touch displays, Diamond Touch allows each user to interact with the screen in a distinct color, enabling a collaborative environment where multiple people can work together face-to-face without the barriers typically introduced by personal devices like laptops, tablets, and smartphones.

The technology is designed to enhance group collaboration, making it ideal for settings where face-to-face interaction and simultaneous input from multiple users are beneficial, such as in design review meetings or collaborative projects.

Diamond Touch also integrates with existing software, making it versatile and adaptable to various applications. The demonstration highlights features like multi-user commenting on a PDF document, showcasing how Diamond Touch can make software multi-user aware and facilitate more efficient and interactive meetings.

Contact:

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

Developing User Interfaces for Adobe Products

Leave a reply

Adobe Creative Cloud And Document Cloud User Interface Choices when developing extensions and plugins

Adobe Systems either merged with other companies to acquire most of its products or has been developing them for a significant period of time. As a result the interfaces and software interface vary considerably. However, Adobe has attempted to try and standardize across the Creative Cloud range of products with its CEP interface for user interface.

There are multiple methods for producing extensions and plugins for most of Adobe’s products, including various approaches for developing graphical user interfaces.

Let’s take a brief look at products that offer interfaces for Adobe Creative Cloud Extensions and Adobe Document Cloud Extensions.

Adobe Illustrator User Interfaces

For example, Adobe Illustrator requires HTML and JavaScript for its user interfaces. Adobe Acrobat supports native user interfaces on both Windows and Mac platforms, though it used its own user interface technology called ADM (Adobe Dialog Manager) until recent versions. Adobe Illustrator also used the same technology, but it has been phased out in the last few versions of the products (although surprisingly still available in its developer interfaces and documentation with the interface name “sweatpea”) but is basically defunct and should not be used.

Adobe Acrobat available User Interfaces

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. Mapsoft used it in its Engage Designer product as we needed a user interface that would be available across Windows and Mac platforms. Most of our work for Adobe Acrobat is for the Windows platform so for decades we have used the Microsoft MFC C++ classes which is a thin C++ layer over the top of the standard Windows interface. MFC is fast with very little baggage and is ideal for the types of interface that are required in plug-ins.

Adobe InDesign choice of User Interface

Adobe InDesign probably provides most options in supporting its own resource format that is compatible across Mac and Windows platforms and also HTML5/JavaScript in the form of CEP and more recently UXP.

Adobe Creative Cloud

Adobe’s Creative Cloud products can also receive supply as hybrid extensions and plug-ins, incorporating HTML, JavaScript, and native plug-ins within the same package and product. The presence of various technologies has not been simplified by Adobe’s history of introducing technologies only to phase them out later. For instance, most Creative Suite products (the precursor to the Creative Cloud) once supported user interfaces based on Flash before Adobe discontinued this approach in favor of HTML 5, CSS 3, and JavaScript, known as the Adobe Common Extensibility Platform (CEP). Adobe Acrobat, belonging to both the Document Cloud and the Creative Cloud, follows a distinct development path by not adopting this technology.

Location of Adobe's current software developer kits 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.

CEP

CEP in conjunction with ExtendScript to provide the application specific functionality 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.

C++ SDK Interfaces

For interaction, speed, multi-threading and extensive task handling using the software developer kits natively is often the only option (i.e. using the C++ interface). 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.

UXP

The new entrant on the block. Adobe UXP is the modern JavaScript Framework that claims to be able to replace all of the other interfaces and the connections between core code (c++, ExtendScript) and the existing user interfaces discussed above. It is gradually being introduced to various applications. Unfortunately the first was Adobe XD which is about to be discontinued after the failed Adobe/Figma merger. Adobe concentrated on getting UXP matured for Adobe Photoshop plugin development and has more recently been introduced to the latest version of Adobe InDesign. Apart from Spectrum, Adobes native interface, UXP is able to support a number of HTML/JavaScript user interface libraries such as React and Vue. React JS is actually used by Adobe in a number of its developments using UXP. Unlike CEP, UXP is not a fully fledged web browser and can not be guaranteed to be compatible with all JavaScript libraries.

Contact info:

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

Associated Links:

What next?

If you are interested in discussing our consultancy and software development services further then please send an email to info@mapsoft.com by clicking the button below:

Click Here

SMART integration Plug-in for Adobe Illustrator

Leave a reply

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

Welcome to this whiteboard illustration video software with Adobe Illustrator and the SMART whiteboard. Welcome to this Enhance design & product review meetings by using SMART visual collaboration solutions with the popular vector graphics editor Adobe Illustrator.

The Video Transcript for using Illustrator with a whiteboard

(00:00) Hi. My name is Andy. I’m the head of market development at SMART Technologies, and today I’d like to show you how you can use SMART’s visual collaboration solutions
(00:08) with Adobe Illustrator to enhance your product evaluation and design meetings. We understand that one of the challenges you face is bringing together the many
(00:18) stakeholders involved in the product and design process, and synthesizing and capturing the key information that’s necessary as you move from
(00:25) one stage to another through your process. To ensure this, SMART’s solution enables full collaboration, engagement, and inspiration among all your stakeholders.
(00:39) Here’s how it works. I have Adobe Illustrator running on my computer, which is connected to a SMART interactive display
(00:46) and I’m also running SMART Meeting Pro software. You’ll be able to see that I have a layer here, which we call the SMART Board edits.
(00:53) This is to ensure that I can protect my original artwork, so I don’t make any unintended changes to the design from my SMART Board.
(01:01) Because my SMART Board detects multi-touch gestures, I have a very simple mechanism to manipulate my image with my product design team.
(01:09) I can also select multiple objects and group them together. And if I want to clone an object, I have a simple touch gesture.
(01:21) Once you have the image that you’d like to evaluate with your team, you can write comments on top of the model by simply taking the SMART Board pen, which automatically
(01:29) starts the pencil function in Adobe Illustrator. This allows me to write comments directly in the Illustrator file.
(01:37) And I can also change the ink color by simply pressing a different key on the SMART Board. With Bridgit conference software running on both the SMART Board and my iPad, remote
(01:50) users can see in real-time all the comments that the design team has written. And because these comments are part of the Illustrator file, they stay with
(02:00) the file when I move it and manipulate the size. But let’s say I want to add some ad hoc comments without creating these
(02:08) comments directly in Illustrator. I can simply press my screen capture icon and jump to my whiteboard, resize the image, and add additional notes.
(02:30) When we’re done taking notes on all these images, I can send them out, either as a PDF or a PowerPoint to team members after the meeting.
(02:38) You can find more information about SMART Technologies and our business solution offerings on our website at www.smarttech.com.

Technologies Used

Adobe Illustrator
SMART Whiteboard
Adobe Illustrator SDK

Contact Information

Michael Peters

Mapsoft Software Development Services

Associated Links:

Questions Relating To Software Development Services

Illustrator Software Developer Kit SDK

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

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