The Many Faces of Acrobat & PDF
Thomas Merz: PDF on the Web and on the fly
An Electronic Publishing Specialist Group meeting report
(Thomas compared the Job Options dialogue box to 
a Boeing 747 flight deck – with 36 alternatives, many 
casual users are daunted and confused.)
Enabling streaming:
We don’t want wait until 
a whole 300-page manual has been downloaded, just 
so we can read the first page. This problem has been 
addressed by enhancements in the Acrobat software 
(version 3 and above), in PDF file structure (version 
1.2 and above), and in HTTP, the Hypertext Transfer 
Protocol, which in version 1.1 was amended to allow 
an HTTP client to request a byterange 
a file, 
rather than the whole file. Popular Web browsers can 
issue byterange requests (Navigator 2.0 and above, 
and Microsoft Internet Explorer 3.0 and above); 
and several common Web servers support byterange 
serving (e.g. Apache 1.2 and above, Microsoft Inter-
net Information Server 3.0 and above, and Netscape 
Enterprise Server 2.0 and above).
If a PDF file has been optimised for byterange 
serving, it is possible for a browser to send an HTTP 
request which results in the server sending 
of the PDF file – say, the directory data at the 
end of the file, plus the sections necessary to display 
just the first page. Indeed, it’s possible to follow links 
within this document, each jump to a new page 
resulting in a similar byterange request and partial 
download of PDF data.
Link management:
This is currently a hot topic for 
publishers, and Web site management software is 
now available which adequately supports manage-
ment of link networks within and between HTML 
pages. Some of these products are beginning to deal 
with the links in PDF files on the site too, but there’s 
still scope for much more progress to be made here.
Dynamic generation:
Thomas remarked that 
making dynamically-generated PDF is his special 
interest; he was to address it in detail later in his talk.
PDF on the Web: advanced topics
Search engines:
If you have a large Intranet with 
a substantial amount of information stored in PDF 
form, you would certainly want your users to be able 
to find relevant documents through a search engine. 
The good news is that many vendors of search engine 
technology (e.g. Fulcrum, Muscat, Verity, to name 
but a few) have extended support to PDF: as docu-
ments are added to the Intranet, the text in the PDFs 
is extracted and indexed to support full-text search-
ing. This works well, and is a good in-house solution. 
However, it seems that indexing of PDF content is 
not supported by any of the public search engines on 
which millions of Web users rely every day.
Adobe has prepared technical resources which 
would allow a PDF page which had been retrieved 
via such a search to have highlighting added so that 
searched-for words would stand out. This works in 
certain software combinations, but not all, so this 
feature too may be one that can be implemented only 
in the controlled environment of an Intranet.
Forms features:
Thomas considers that the forms 
capabilities of PDF 1.2/Acrobat 3.0 and above are 
underestimated, and as yet underused. They can 
transfer forms data using the same method as HTML 
forms (as specified in Internet RFC 1866), which 
means that implementing them can be done without 
changing a single CGI script on the server. As an 
alternative, Adobe’s Forms Data Format (FDF) can 
be used both to send forms data to the server – and 
to receive additional content in response, based on 
entries made in form fields, which will update the 
layout of the form. (In his book 
Web Publishing with 
, Thomas goes into greater detail about 
uses of FDF and also the JavaScript programmability 
of Acrobat forms.)
Adobe Document Server:
This recent innovation 
is software which resides on a Web server, and which 
rasterises PDF data so that page content can be trans-
ferred to the browser as an image, for instance as a 
GIF file. This may seem strange for Adobe to do, 
given that Acrobat is available for most computers 
and now even in Java form, but there will always be 
some users who can’t be bothered to install extra 
software, and some environments such as Web-TV 
boxes where installation of software is impossible.
Dynamic PDF: the problems
The strong trend on the Web is towards sites which 
generate HTML pages ‘on the fly’ on the basis of 
content stored in a database. Generating content 
from databases offers all sorts of possibilities, such 
as creating custom presentations of data for a client, 
and also makes it easier to manage the updating of 
certain kinds of content. Can this model of Web 
publishing be extended to PDF?
Database-driven HTML is not hard to do: the 
mark-up is simple, and HTML tags can be stored in 
the database fields, or a script may add them as the 
data is extracted and concatenated. In contrast, to 
understand PDF you should have some background 
in PostScript, and the PDF specification is over 500 
pages long. The file structure has a big and complex 
Pdf image extractor c# - Select, copy, paste PDF images in, ASP.NET, MVC, Ajax, WinForms, WPF
Support PDF Image Extraction from a Page, a Region on a Page, and PDF Document
extract jpeg from pdf; some pdf image extractor
Pdf image extractor c# - VB.NET PDF Image Extract Library: Select, copy, paste PDF images in, ASP.NET, MVC, Ajax, WinForms, WPF
Support PDF Image Extraction from a Page, a Region on a Page, and PDF Document
extract images from pdf; pdf image extractor online
The Many Faces of Acrobat & PDF
Thomas Merz: PDF on the Web and on the fly
An Electronic Publishing Specialist Group meeting report
overhead, and the role played in a PDF file by the 
directory is also problematic (because if the offsets 
specified by pointers in the directory point to the 
wrong place in the file, the file just won’t work).
Of course, one way round this is to use a database 
publishing system to generate a PostScript file, then 
feed that to Distiller to create PDF. (One example 
of this is the 
system from Datazone, which 
translates database content into Maker Interchange 
Format, then uses FrameMaker to format it and 
generate the PostScript). However, the convoluted, 
computationally-intensive nature of the process is 
too slow for real-time delivery, and would soon bring 
a Web server to its knees. Another barrier is that 
Distiller is not available for the Linux platform, 
which is such a popular choice for Web servers.
In any case, Thomas noted, full-blown Distiller 
with all its prepress-supporting capabilities is an 
‘overkill’ solution for the kind of PDFs which one 
would typically require in this scenario; for the Web, 
one could get by with 5% of Distiller’s functionality.
A solution for Dynamic PDF
Thomas then described his own programming work 
in this area. This started in 1997, as he decided to 
learn about PDF in a greater than usual level of detail 
– by creating PDFs himself.
One can write simple PDF files with a text editor, 
just as one can do with PostScript. However, it is hard 
to produce usable and significant PDFs this way. The 
internal directories and object flagging structures 
which make PDF such a useful format are a particular 
barrier to hand-crafting PDFs – it is so easy to make 
mistakes, and the mistakes are disastrous.
Initially, writing his own PDF-generating software 
was for Thomas a way of learning how PDF works, 
and it let him experiment with some features of PDF 
that are documented in the PDF specification, but 
not yet implemented by any Acrobat software. (As 
examples, he cited placing PDF bookmarks and 
annotations in Eastern European languages, encoded 
as Unicode; attachment of non-PDF files to PDFs; 
and the use of custom icons for Sticky Notes.)
Thomas’ software, now at version 2.0, is called 
PDFlib, and is implemented as a C software library. 
It automates the production of much of the basic 
typographical and layout features of PDF, with 
vector graphics and images, forms and hyperlinks – 
the sort of thing that would be needed for generating 
Web-oriented PDF – while ignoring prepress issues 
such as colour management. The result is a fast, 
multi-threaded system that can generate PDFs very 
quickly – with a simple interface and a short manual!
In preparing the second release, Thomas took into 
consideration that many people who are uncomfort-
able programming in C are happy to work with 
simpler scripting languages such as AppleScript, 
Visual Basic or Perl. Therefore he generated a second 
‘layer’ of PDFlib that acts as an interface to these 
scripting environments; the Perl interface, for 
example, would allow a Webmaster to write a 20-line 
Perl script which would direct PDFlib to generate a 
PDF file. The Visual Basic interface opens the door to 
the use of Microsoft’s Active Server Pages, Active-X 
controls and other techniques.
PDFlib may be found at
, in 
Open Source format, and may be freely downloaded. 
Thomas expects no payment for personal use of 
PDFlib, but charges a license fee to developers who 
integrate it into into commercial solutions.
Who uses PDFlib? Downloads have been in the 
region of 1,000 a month, so it’s quite a large user base; 
and though the number of commercial users is small, 
it includes some big customers, including a number 
of insurance companies and banks; database software 
companies who have integrated PDFlib into their 
report generators; an e-commerce site which sells 
customised mailing lists; and various print-on-
demand applications.
Looking ahead to the future of PDFlib, Thomas 
hopes to introduce more rule-based layout capabili-
ties to the library, a kind of page formatting machine 
onto which could be dumped some structured data 
and some formatting rules. He wants to give priority 
to linearising and optimising PDFs for byterange 
serving, and looks forward to adding structure to 
PDF and further font-handling capabilities.
Thomas Merz is the author of two authoritative and 
readable books about Acrobat, published by Springer in 
both German and English. The ISBN of Web Publishing 
with Acrobat/PDF is 3–540–63762–1.
VB.NET TIFF: TIFF Text Extractor SDK; Extract Text Content from
Please get the latest XDoc.Tiff C# Developer Guide here. Standalone VB.NET TIFF text extractor SDK that extracts control SDK into VB.NET image application by
extract image from pdf java; pdf image extractor
VB.NET PowerPoint: Extract & Collect PPT Slide(s) Using VB Sample
demo code using RasterEdge VB.NET PowerPoint extractor library toolkit. provide powerful & profession imaging controls, PDF document, image to pdf files and
extract images from pdf online; extract jpg pdf
The Many Faces of Acrobat & PDF
Aandi Inston: Print-oriented Acrobat plug-ins
An Electronic Publishing Specialist Group meeting report
Augmenting Acrobat with print-oriented plug-ins
Aandi Inston – Quite Software
Aandi is a software developer who produces utilities 
for the printing industry – for instance, a PostScript 
editing tool called PSalter. In recent years, he has 
been developing plug-ins for Acrobat.
Aandi made it clear that he would not discuss 
plug-ins for Acrobat Reader; Adobe have set the rules 
for developing plug-ins so that if you want to do 
somehing really useful, the customer will have to 
have a copy of what he referred to as “the application 
formerly known as Acrobat Exchange”.
From a user’s perspective, plug-ins are things 
that allow Acrobat to do more more things. For the 
programmer, the view is usually the other way round: 
Acrobat is no more than the necessary framework so 
that plug-ins can do useful things to PDF. The plug-
in architecture is useful for programmers, because it 
frees the programmer to concentrate on just what the 
plug-in is supposed to achieve.
But why write plug-ins? To express it differently, 
What’s missing from Acrobat? Aandi explained that 
it isn’t that Adobe created Acrobat as an incomplete 
or inadequate product; it’s just that there are things 
one would want to do with (or to) PDF that aren’t 
what Adobe have defined Acrobat as being for – 
though ‘what Acrobat is for’ is something that Adobe 
has changed several times over the years.
From the perspective of the printing industry, 
said Aandi, what’s missing in Acrobat is: production 
tools, production tools, and production tools.
The pain of separation
Pre-press, the business of preparing electronic files 
and imaging them to film or plates for the printing 
industry, is like a horror movie, said Aandi. It’s full of 
dead things that refuse to lie down, especially when it 
comes to making colour separations into process 
colour and spot colour.
In the late 1980s, Adobe got together with other 
companies and put together an interim solution for 
handling spot colour and process colour separations, 
by defining ‘Color Extensions’ to the PostScript 
language to patch what had originally been conceived 
of as a black-and-white printing solution. This solu-
tion requires a separate page description to be sent 
to the Raster Image Processor (RIP) of the imaging 
device, for each colour separation to be generated. 
As a method, it worked, and was widely adopted by 
companies writing DTP applications.
But Adobe went back to the drawing board, and in 
1990 came up with a new colour separation solution 
in PostScript Level 2. In this method, a composite 
colour PostScript file is transferred to the RIP, and 
the separation is done inside the RIP. This method is 
better, it’s more robust – and to this day it is still not 
much used! We are, therefore, stuck with the heritage 
of a lashed-together solution from the late 1980s, 
mixed in with some bits of the old system. Acrobat 
works only with the new system, but can understand 
parts of the old system. “There’s sticking-plaster 
everywhere,” Aandi declared.
The work-flows which have the greatest difficulty 
in making a transition to the Level 2 model are those 
that use Desktop Color Separation (DCS) files, as 
invented and promoted by Quark, Inc. In this kind 
of imaging workflow, colour separation software 
preseparates an image, typically a photograph, into 
one greyscale representation per component colour, 
so that each CMYK image is represented in the file-
store by four files, plus a low-resolution ‘preview’ file 
with embedded PostScript comments for import into 
the DTP application. As XPress prints a CMYK page 
to an imagesetter, the PostScript comments found 
in the preview file prompts the system to retrieve the 
high-resolution greyscale data from the appropriate 
DCS component file and merge it into the PostScript 
for each separation.
This method has the virtue (from Quark’s point of 
view) of making it easy to manage colour separations, 
but as an approach it is incompatible with the Level 2 
composite way of doing things. However, despite 
drawbacks in the DCS way of handling colour, it has 
become so deeply entrenched in the print industry 
that Adobe has had to continue to support it in their 
applications, and indeed DCS support was even 
further extended in Photoshop 5.0.
Some publishers use Acrobat within this older 
model by printing preseparated PostScript to disk, 
then converting this to PDF. When viewed within 
Acrobat, this results in one greyscale page for each 
separation (e.g. cyan, magenta, yellow, black, pink, 
spot varnish...). Such files can be used for imaging 
film, but people not used to printing will have diffi-
culty visualising what the result will be. Combining 
these to obtain a preview requires expensive equip-
ment and materials (e.g. printing film positives, and 
using these to image a Cromalin proof).
VB.NET Word: Extract Word Pages, DOCX Page Extraction SDK
on also owns high compatibility with Visual C# .NET code. feature, this VB.NET Word page extractor add-on page, sort Word page order or insert image into Word
pdf image text extractor; pdf image extractor c#
VB.NET TIFF: TIFF to Text (TXT) Converter SDK; Convert TIFF to
NET developers to interpret and decode TIFF image file. But different from TIFF text extractor add-on powerful & profession imaging controls, PDF document, tiff
online pdf image extractor; extract pictures pdf
The Many Faces of Acrobat & PDF
Aandi Inston: Print-oriented Acrobat plug-ins
An Electronic Publishing Specialist Group meeting report
Plug-ins for outputting separations
Lantana’s plug-in Crackerjack is the best-known 
colour separation plug-in for Acrobat. Essentially, 
it provides Acrobat with a super print dialogue box 
where separations, colour management, crop mark 
placement, PPD selection, and so on can be request-
ed. Crackerjack totally embraces Level 2 colour, and 
the PostScript that it generates is separated in the 
imagesetter RIP and sent to separate films or plates. 
This method is good, it’s fast, and it’s predictable; 
it even works with RGB image data.
However, this Level 2 approach to separation has 
its drawbacks:
In-RIP separation works only on printing devices 
equipped with RIPs that are PostScript Level 2 
compliant; and there are still older imagesetters 
out there which aren’t.
Furthermore, in-RIP separation is usually not a 
feature that has been included in laser-printer 
RIPs, which makes it difficult to proof your 
separations at low cost in the design studio.
In the older model, it was easier for an application 
to specify overprinting, for instance to ensure that 
black elements would always overprint. In the 
Level 2 model, black type on a coloured back-
ground would result in negative type-shaped 
knockouts being produced in the colour plates, 
which causes an unpleasant halo effect when 
printing is even slightly out of register.
Level 2 conversion of RGB to CMYK is rather 
crude, being based on the assumption that cyan is 
the inverse of red; whereas in the real world, the 
pigment available to represent cyan is not truly 
diametrically opposite to red. (In principle, the 
recently introduced PostScript Level 3 supports 
more sophisticated colour management, though 
there is little evidence that this is being exploited.)
An alternative colour separation plug-in is PDF 
Output Pro from Callas Software on Germany. This 
takes a different approach from Crackerjack, and 
generates Level 1 PostScript. This is ideal if your 
workflow is oriented towards output devices which 
cannot handle Level 2 PostScript, and it also has the 
benefit of allowing you to make colour separation 
proofs on a desktop laser printer.
However, this is slower: whereas Crackerjack 
sends data for a page once, PDF Output Pro must 
send data four times (or more if extra spot colours 
are involved). Also, it is impossible to separate RGB 
image data this way: images must be pre-converted to 
CMYK colour space.
In the publishing industry, the term ‘preflighting’ or 
‘preflight checking’ has come to mean doing all you 
can to make sure that files are good before you out-
put them to expensive film – or even more expensive 
plates. The aim is to eliminate human errors and 
system deficiencies. This is just as important for PDF 
files as for PostScript, because a PDF will contain 
what the user has put into it, mediated perhaps by 
Distiller settings when the PDF was being produced.
Callas’ PDF Inspector is an example of an Acrobat 
plug-in for preflighting, and Aandi showed a screen 
shot. “At first sight this dialogue looks horrendous – 
can there really be so many problems with a file? But 
it makes sense if you think of it as an auditing tool.” 
For example, you could set up PDF Inspector to alert 
you if colour or greyscale images have a resolution of 
less than 100 dpi (in which case they will not print 
well) or more than 300 dpi (in which case the 
resolution is excessive and the file will take too long 
to print, and may even exceed virtual memory limits 
in the RIP). You might also ask to be alerted to the 
presence of spot colours in a CMYK job, which 
would output unwanted film separations. (Callas 
also market PDF Batch, which can batch-process 
PDF Inspector jobs.)
To use a utility like this effectively, and to know 
how to set up the parameters for each kind of print 
job, you need to understand the printing process, 
and most preflighting products are for use by output 
bureaux and service printers receiving jobs as PDF 
from their customers.
Late editing
Aandi characterised late editing of PDF as ‘the Devil’s 
work’, because PDF was never conceived of as being 
late-editable. It is almost always better to revise a job 
in the original authoring application, which under-
stands such things as kerning and hyphenation and 
justification and text flows, and regenerate fresh 
PDF. Nevertheless, Aandi admitted that he himself 
has found it convenient to do things like move page 
numbers at the last minute.
Acrobat itself offers primitive editing of existing 
text strings, but the Enfocus plug-in, Pitstop, adds 
graphical editing. One can drag and drop elements, 
but Pitstop is limited in aspects such as adding new 
photos, and colour management.
That’s where Quite Software comes in. Quite A 
Box Of Tricks contains a number of things: images 
can be converted from RGB to CMYK, either using 
fixed inks or ICC profiles. Images can be converted 
C# Word: How to Extract Text from C# Word in .NET Project
you can rest assured because this Word text extractor preserves both to provide powerful & profession imaging controls, PDF document, image to pdf files and
extract image from pdf file; extract pdf images
The Many Faces of Acrobat & PDF
Aandi Inston: Print-oriented Acrobat plug-ins
An Electronic Publishing Specialist Group meeting report
to greyscale or have their resolutions changed (e.g. 
downsampling for proofing or for the Web), and 
hairlines can be thickened.
Imposition is the process of combining images of 
individual pages so that large multi-page sheets of 
imagesetter film or plates can be printed in a single 
pass. As far as Aandi knows, Quite Software has the 
only Acrobat plug-in to do this: Quite Imposing.
He explained that one beauty of doing imposition 
in Exchange is that the end result is a PDF, and so can 
be previewed and checked. Also, the job can be done 
incrementally, instead of having a huge array of set-
up dialogues and a ‘Go’ button.
For example, one little feature that is needed in 
large saddle-stitch impositions is ‘creep’, a procedure 
which shuffles the pages slightly to one side on the 
sheets to compensate for the displacement that 
occurs in binding. In Quite Imposing, this can be 
done as a discrete step.
In imposition, it is important to define bleeds 
(where images extend off the page boundaries). To 
handle this, Quite had to invent a little extension to 
PDF for version 3.0. Adobe have since established a 
standard in Acrobat 4.0, similar to Quite’s, and so 
they have now adopted Adobe’s standard.
There is an important point here, said Aandi. PDF 
can be seen as opening up the workflow, so that one 
can choose any tool that one prefers to get the job 
done. This only works so long as everyone sticks to 
agreed standards, rather than inventing proprietary 
solutions. The corollary of this is that it is important 
for Adobe, as the ‘guardians’ of the standard, to track 
and anticipate needs as they develop it – which can’t 
be an easy job.
What plug-ins can and can’t do
Plug-ins must do their work within the framework 
of Acrobat software. That means you can only do 
what Adobe have allowed you to do.
Some things are very easy to do: adding links, 
for example. Some things are harder: editing page 
contents is possible, but it’s hard work because of 
PDF’s data model. Other tasks might be impossible.
What Acrobat lets you do also changes over time. 
In Acrobat 4.0, Adobe added the ability to edit the 
API, and they allowed plug-ins to control things like 
device set-up on each page, which previously had 
been impossible.
Future plug-ins?
Aandi said that his list of possible tricks for plug-ins 
is long – and he’s sure the best ones are those he 
hasn’t thought of yet.
It would be good to provide more output control, 
probably device specific plug-ins for e.g. selecting 
different media bins or collation/binding features 
on a Docutech printer.
More late editing ability is required; it has to 
come. More colour control is needed too, e.g. 
tagging images with a colour profile.
What about colour separations? It may be an old 
fashioned idea altogether, but it won’t go away. 
How about a plug-in to make a separated PDF 
from a colour one? That’s already on Quite 
Software’s hot-list.
Or, how about the other way, making composite 
PDFs from from separated ones? This would have 
some utility in making previews and proof copies. 
Technically, it’s almost impossible to combine 
preseparated vector data into a composite vector 
image, but one could combine vector data into 
fixed resolution raster images so one could at least 
preview the results.
Are plug-ins’ days numbered?
But are plug-ins days numbered? Two things say they 
might be. First, Adobe might incorporate the best 
ideas into the base Acrobat product. That may 
inconvenience (or even bankrupt) some developers, 
but the user benefits, and plug-ins continue.
Second, the whole idea of using plug-ins inter-
actively conflicts with the grandiose workflows that 
Adobe, Agfa and others are promoting, such as 
Extreme and Apogee. These are closed, batch systems, 
predefined, designed to be highly reliable, using in-
RIP separation and trapping, and including colour 
management and imposition. This is based on the 
premise that we will be able to predefine our work-
flows in advance and walk away, making the idea of 
using interactive tools rather quaint, like handicrafts.
However, these grand schemes are at odds with 
common trends in print publishing: short print runs, 
different requirements for each job, and less skilled 
preparation of the files. The best way to sort out the 
problems this brings printing businesses on a daily 
basis is upstream from the imagesetting process – 
which means that print-oriented Acrobat plug-ins 
are probably here to stay.
Find Quite Software at
The Many Faces of Acrobat & PDF
David Brailsford: Moving Web & Print closer together
An Electronic Publishing Specialist Group meeting report
Moving Web and Print closer together:
the role of SVG and structured PDF
David Brailsford – School of Computer Science and IT,
University of Nottingham
Professor David Brailsford is no stranger to EPSG, 
being one of its founders in the mid eighties. He had 
chosen to speak last, after some speakers had consid-
ered primarily print publishing and others the Web, 
to consider how these two worlds might be brought 
closer through XML, SVG and ‘structured PDF’. 
Work on these has been conducted at the University 
of Nottingham, in close liaison with Adobe Systems.
These two worlds cannot converge totally because 
they have quite different technical requirements, and 
come from quite different traditions. Obviously, the 
world of 72 dpi landscape computer displays, with 
transparent layers, animated graphics and inter-
activity, is miles away from the world of CMYK high 
resolution printing on paper with a Heidelberg press. 
However, SVG and PDF offer hope of convergence, 
and structured PDF offers possibilities for extracting 
text from a PDF in a form better suited to editing, re-
flowing, and repurposing to other formats.
Between two cultures
David presented his favourite presentation graphic 
of all time, which we’ve reconstructed in Fig. 3. “All 
human life is here, as far as I’m concerned,” he said. 
“This encapsulates where I’ve been for fifteen years: 
not sitting on the fence, but in the middle of a 
At the top of his diagram is the world of document 
processing software: Quark XPress, PageMaker, 
X, PageMill, WebObjects, you name it. From 
this point of origination one can either go down 
left field, towards encoding and transmitting the 
structure of a document, perhaps with Web publish-
ing in mind; or down the right of the field, where 
structure tends to get lost, and what gets encoded and 
transmitted instead is the exact appearance of the 
document, generally for print publishing.
Some tools at the top are more suited to one 
direction than another: PageMill leans towards the 
Web and QuarkXPress to print. But more and more, 
document preparation systems are getting to the 
point where they could go either way.
At the bottom of the diagram, worlds are very 
much apart. Far to the left lie SGML and XML, fully 
capable of defining document structure, method-
ically extensible, and beloved of publishers in the 
scientific, technical and medical (STM) fields. HTML 
also lies on this side of the field, even though it has 
been arbitrarily extended by commercial interests, 
mostly in ways that show concern with controlling 
appearance rather than defining structure.
On the right side of the field is the well established 
world of print publishing, within which PostScript 
now plays a near universal role in controlling the 
Fig 3: David Brailsford standing on the battlefied between two cultures: Web and Print
The Many Faces of Acrobat & PDF
David Brailsford: Moving Web & Print closer together
An Electronic Publishing Specialist Group meeting report
output of imagesetters, platesetters and high-end 
laser printers. That PostScript can be converted into 
PDF, which has a better structure, with an explicit 
tree-like index of the objects within the file. This 
improves access to pages, and enables other features 
such as annotations and hyperlinks.
Each of these worlds is inhabited by denizens 
steeped in its culture. On the left, we are likely to find 
people who express a lack of concern for document 
appearance; what matters to them is being able to 
define and extract structure (for example where 
headings, paragraphs and citations begin and end), 
so documents can be stored in a database, or edited 
and repurposed for different media. Much of the 
formative input to this culture has come from the 
world of computer programming languages. 
On the right side, where appearance is deemed 
critical, formative input comes from hundreds of 
years of graphic design and typesetting traditions; 
plus, more recently, a huge input from computer 
graphics, a field in which John Warnock of Adobe 
Systems has been a very distinguished practitioner.
So far apart are these cultures at times that David 
has met publishers who say that though they now 
handle both Web and print publishing, the people 
who do these activities sit in separate rooms, think 
and work differently, and won’t talk to each other 
or go to the same pub!
Conversion woes
On the PDF listserver (for details of joining this, 
), people often ask, How can 
I convert my HTML into PDF? The answer is often 
given that this is moderately easy to do. Indeed, 
the Web Capture facility that is part of Acrobat 4.0, 
earlier mentioned by Thomas Merz, will do just this: 
you point it at a Web site and it will take a snapshot 
of that site as a PDF file. You can configure this 
process in various ways, for instance defining the 
page size to which the site will be formatted. You can 
also control how far along the link structures Web 
Capture will extend its pursuit of data, e.g. following 
links within the site but not those which go off-site; 
or visiting links off-site but only to a defined number 
of subsequent links. It’s a very impressive utility.
However, the question which is more commonly 
asked is, How can I go back the other way, from a 
PDF file to HTML? In general this is astonishingly 
difficult, and often impossible, for a wide variety of 
reasons. For one thing, the rich graphic language of 
PDF is not supported in the markup-based environ-
ment of HTML; for another, with no explicit refer-
encing of structure, structure can be inferred only 
from such subtle cues as the positioning of elements 
on a page, the size of type and so on. Moving in this 
direction would be much easier with Structured 
PDF, as David was later to describe. At least it would 
then be easier to convert to ‘vanilla HTML’, and if 
one could assume fully XML-enabled browsers one 
could convey structure in greater detail.
So, what is ‘structure’?
In his next three slides, David reviewed the essential 
features  of SGML, HTML and XML. For much of 
our audience this was old news, but many present 
were drawn from the graphics world, for whom these 
initals represent something novel, so we report it 
here. This also gave us an opportunity to review 
what people mean by ‘structure’ in the context of 
electronic publishing.
SGML: the Standard Generalized Markup Language 
is a metalanguage: it does not define a set of markup 
tags, but it sets the rules for how you can construct 
your own tagsets so that they (a) define the kinds of 
document structure and content appropriate for 
your application, yet (b) work in a comfortable way 
with SGML-aware software such as editors, databases 
and so on. These tagsets and their syntax must be 
formally defined in structured text files called DTDs 
(Document Type Definitions).
Since its inception some 15 years ago, SGML has 
attracted a core of dedicated followers; it is used by a 
number of large publishers in the STM community, 
and by technical documentation groups. SGML 
applications tend to work best when the tagsets 
express pure document structure and eschew any 
attempt to bind elements to a particular form of 
appearance. The sensible way control the appearance 
of structured documents is via external stylesheets 
that define how each kind of tag should be formatted 
and displayed for a particular kind of output.
David considers that the committee that devised 
SGML made one critical mistake: they permitted tag 
minimisation – for instance, the omission of closing 
tags under conditions where it might be possible to 
infer them. This has made it difficult to write soft-
ware that handles SGML, because complex inference 
strategies have to be built into the parser element of 
these programs; and without access to the DTD, little 
sense can be made of document structure.
The Many Faces of Acrobat & PDF
David Brailsford: Moving Web & Print closer together
An Electronic Publishing Specialist Group meeting report
HTML: the Hypertext Markup Language was based 
on the use of SGML notation, with tags designed for 
showing documents in Web browsers and establish-
ing links between them. Development of the tagset 
has been at the mercy of vendors such as Netscape 
and Microsoft, who sought to extend it in private 
ways. Despite the efforts of W3C, there are still tags 
that work differently in different browsers, or not at 
all in some (e.g. Inline Frames work in MS Internet 
Explorer but not at all in Netscape Navigator).
Although HTML has evolved as a compromise 
between defining structure and controlling appear-
ance, the graphics model is quite limited. Elements 
are positioned rather crudely within the browser 
window; images are limited to embedded GIF or 
JPEG files; and one has had to look beyond standards 
to private plug-in technologies such as Macromedia’s 
Flash for support for vector graphics.
XML: the Extensible Markup Language has been 
recently and rather quickly adoped as a simplified 
version of SGML, rebuilt to serve multiformat 
publishing including hypermedia such as the Web. 
Some technical problems with SGML have been 
overcome: for instance, by rejecting tag minimis-
ation, which makes it easier for software to check 
that an XML document is ‘well formed’ even in 
the absence of a reference DTD file.
Because XML is extensible yet rigorous, it has 
gained wide approval as a base syntax for expressing 
the features of ‘next generation’ browsers and new 
capabilities for the Web; and its notation has proved 
equal to the task of expressing style-sheet and link-
net definitions (in XSL and XLink), metadata (in the 
Resource Description Framework or RDF), and even 
interactive object-based graphics (in SVG).
Why PDF needs more structure
What SGML, HTML and XML share in common, 
and what makes them ‘structured’, is their ability 
through mark-up to declare the functions of parts 
of a document (e.g. this is a section, this is the main 
heading in that section, this is a citation etc.), and to 
make explicit the logical hierarchy between them.
To bring the ‘left field’ and ‘right field’ of David’s 
diagram closer together, PDF needs more of this kind 
of structure. (That’s not to say that PDF lacks any 
structure; it does have an internal structure consist-
ing of objects such as pages, image streams and text 
streams, bookmarks and ‘article threads’, all nicely 
indexed in a tree-like index called the pages tree. 
However, the structure of PDF is based around 
display tasks; it is quite agnostic about the editorial 
structure of the text.)
An HTML file is presented as a linear string, in 
reading order. But in PostScript, there can be an 
astronomical number of different ways to ‘paint’ a 
page, and PDF is at the mercy of the PostScript that 
gets fed to Distiller. As a humorous example, David 
displayed two columns of text with a narrow gap 
between (see Fig. 4 above). The column gap could 
be mistaken for uneven wordspace within a single 
column, and even the human reader is fooled by this 
for a while, until it is obvious that the passage doesn’t 
make as much sense read ‘straight across’ as it does 
when read as two columns.
Distiller, in generating PDF, takes as its guide only 
the order in which text strings were imaged on the 
page, and some typesetting systems output multi-
column text in ‘baseline sort’ order, not true reading 
order. (One such system was Miles 33, which evolved 
to produce multi-column journal output on third-
generation CRT photosetters without page buffer 
memory; this forced Miles to expose the bromide in 
baseline-sort order. When Miles made the transition 
to PostScript, they didn’t change their composition 
engine, so PostScript is generated in the same order.) 
It is issues like this, which are the fault of page make-
up programs, that can make it difficult to extract text 
from PDFs in a logical and useful sequence.
A comparison of hypertext linking in HTML and 
PDF also shows up the lack of logical structure in the 
latter. In HTML, a link start-point is anchored to text 
This is an example of
a two-column article having
a narrow gutter width that produces
potentially disastrous effects
via text selection in PDF.
Indeed the whole mess resembles freaking out totally.
becomes annoyed,
his girlfriend who
a profound relationship with
french fries within
a hungry alligator eating
Fig 4: ‘Gutter-hopping’ happens when 2-column journals are imaged in baseline-sort order; 
this can totally confuse attempts to extract the text from the PDF in logical order.
The Many Faces of Acrobat & PDF
David Brailsford: Moving Web & Print closer together
An Electronic Publishing Specialist Group meeting report
or a graphic, and may also point to a specifically-
named anchor located in a text stream. In PDF, a link 
‘hot spot’ may be positioned over some text or a 
graphic, but it is only a bounding box defined in the 
page co-ordinate space, and is not structurally linked 
to the text or image it ‘covers’.
Likewise, the destination of a link in PDF is just 
bounding box, a ‘view’ of a particular page, in no way 
linked to any object on that page. PDF ‘bookmarks’, 
although they give the illusion of structure, are also 
simply linked to page views.
What does Structured PDF mean?
Structured PDF offers a way of recording within PDF 
that such-and-such an object is a table, or a figure, 
or a paragraph, as one can in SGML or XML. It also 
records the correct logical reading sequence of these 
objects within another tree-like index – the structure 
tree – irrespective of the imaging order in the pages 
tree. Thus an array of PDF chunks, not necessarily 
contiguous in the PDF file itself, might form a para-
graph object in the structure tree, even if it breaks 
over a column or a page. This requires that structure 
markers be placed within text objects, pointing to a 
location in the structure tree; conversely, pointers in 
the structure tree must point back to the objects.
Even the disastrous ‘baseline-sort’ mess shown in 
Fig. 4 can be rescued by the Marked Content markers 
that were newly introduced in PDF 1.3. Each line can 
be bounded by a Begin Marked Content marker and 
an End Content Marker, given an ID, and hooked into 
the structure tree in correct sequence.
Structural markers would certainly help the kind 
of ‘round tripping’ between PDF and HTML which 
people have been asking for, especially if PDF could 
contain a default set of markers equivalent to HTML 
tags such as <P>, or <Hn>, or list-items. Indeed, the 
Web Capture utility described above has an option to 
write structure markers into the PDF it makes while 
capturing Web sites, so that the logical structure of 
the HTML is retained.
What can we expect from
Structured PDF?
The idea of structure within PDF is the subject of 
intense internal debate within Adobe Systems and 
the final outcome is not clear, but by the time 
Acrobat 5.0 comes out, Adobe will very likely have 
defined the ‘default tagset’ for structured PDF, 
roughly at the level of HTML: header 1, header 2, 
list-item etc. If that were the case, tools could then 
be developed to extract content in a logical sequence 
and repurpose it to HTML or SGML; or maybe even 
to reflow that text in a sensible way, for example for 
a little Palm Pilot screen, something one would not 
dare to attempt without an unambiguous record of 
the document structure.
Furthermore, it seems likely that publishers who 
already use SGML and a custom DTD would be able 
at some time in the future to ‘drop down’ as many of 
their own custom tags as they desire into the output 
PDF. The provision in structured PDF for ‘role 
mapping’ would allow that publisher to designate 
which default PDF tags are broadly equivalent to the 
publisher’s custom tags, so that standard Acrobat 
tools that work with the default tagset would also 
work with the custom tags, albeit not to the same 
degree of discrimination (thus several custom tags 
might all map to a single PDF ‘emphasis’ tag).
PDF structure elements will also be like XML 
elements in having attributes, and in being able 
to share arrays of attritutes via a class map. Such 
attributes could include revision numbers, and a 
record of which applications were used to create or 
modify each element in the PDF, and at what time.
Because a structured PDF file contains two hier-
archical index trees –  the pages tree and the structure 
tree – cross-indexing will be required between them 
so that the abstract content elements will be mapped 
to objects on real pages.
The structure tree bears fruit
The research collaboration between the University 
of Nottingham and Adobe Systems is already bearing 
some fruit. Some of the work at Nottingham on how 
to recognise document structure from page appear-
ance has influenced Acrobat Capture, the program 
which takes scanned images of pages and builds PDFs 
from them, using outline fonts. Capture does try its 
best to set out the PDF text in logical reading order – 
and it gets it right most of the time.
Structure will be even more important to the next 
release of Capture, because now Acrobat tools can 
used structure markup to leave little memos for 
themselves. Another priority will be to add intelli-
gence to how Capture recognises the structure of 
data in tables, etc, and to find ways of refining the 
structure partially detected by Capture while scan-
ning in further work sessions that can benefit from 
knowledge of the captured document as a whole.
The Many Faces of Acrobat & PDF
David Brailsford: Moving Web & Print closer together
An Electronic Publishing Specialist Group meeting report
Scalable Vector Graphics
The other theme in David’s talk was the ability of 
SVG to play an important role in bridging the worlds 
of structure and appearance.
When the World Wide Web Consortium asked for 
proposals for a standard for vector graphics for the 
Web, Adobe contributed their April 1998 proposal 
for the Precision Graphics Markup Language, PGML, 
not surprisingly based on the Adobe imaging model 
that lies behind PostScript and PDF. David said that 
Adobe’s involvement with this standard was always 
going to be important if there were to be any hope of 
unifying the worlds of print and the Web; had the 
emergent standard been PostScript-hostile, efforts to 
convert graphics between the two worlds might have 
been faced with insuperable barriers.
Also in April 1998, Macromedia published the 
internal format which they use in their ‘Flash’ vector 
graphics format for the Web, and in the following 
month Macromedia joined Microsoft and others in 
a proposed alternative to PGML, called the Vector 
Markup Language (VML).
In September 1998, at a session of the Seybold San 
Francisco electronic publishing conference, where 
David had been invited to speak about graphics for 
the Web, Chris Lilley announced that all interested 
parties would be getting together under the aegis 
of the World Wide Web Consortium to merge the 
various competing proposals into a single standard, 
to be called Scalable Vector Graphics. By this time, 
discussion had moved on to acknowledge the need 
for such aspects as interactivity, animation and 
transparency in the standard.
SVG promises to bring something extraordinary 
to the Web: a page-definition-like model for signifi-
cant components of Web pages, offering consider-
able fidelity to a designer’s intentions, and with more 
software-like interaction features than could be 
offered by a static graphics model, even such as PDF.
To demonstrate the power of SVG, David showed 
the ‘coffee browser’ sample that had been presented 
at the Seybold San Francisco meeting. The vector 
definitions for this interactive map of downtown San 
Francisco were produced by exporting them from 
Adobe Illustrator via a plug-in.
The demo map features hot-spots which, when 
moused over, causes animated icons and overlaid 
captions to appear to describe coffee-shops in the 
area, and one can zoom in to view the details: in 
the process, it became obvious that the type in the 
image was in outline formats, and would also print 
beautifully. Certain parts of the graphic functioned as 
buttons that could toggle other graphic and anima-
tion features on and off, for instance to display and 
hide highlighting. And lest it be thought that SVG 
supports only vector graphics, the ‘far’ view of the 
map includes a colour bitmap image of the Golden 
Gate Bridge, clipped within an elliptical mask.
The University of Nottingham continues to play 
a part in SVG development, working to provide 
public-domain tools such as input and output SVG 
drivers for Ghostscript, and researching ways of 
Fig. 5: the interactive 
SVG ‘Coffee Browser’
This screen capture shows 
a point part way through 
David’s demonstration. He 
had zoomed in to the area 
around the Moscone Centre 
(marked yellow) and clicked 
on ‘show locations’, which 
caused the coffee-cup icons 
to appear. Clicking on the 
text link for ‘Megabeans’ 
caused its icon to develop 
a transparent halo highlight,
and animated steam began 
to waft from the cup.
Documents you may be interested
Documents you may be interested