mvc display pdf from byte array : Extract image from pdf java application Library tool html .net windows online EPSG_Acrobat19990-part1873

The Many Faces of Acrobat & PDF
A report of the 1 July 1999 conference of BCS–EPSG:
the Electronic Publishing Specialist Group of the British Computer Society
A timely opportunity to look closer at PDF
In this special one-day seminar, the Electronic Publishing Specialist Group took 
a look at Adobe’s Acrobat technology and the Portable Document Format, PDF, 
which bridge the world of on-line media and traditional print publishing. Soon 
after the launch of Acrobat 4.0 and the revision of PDF to level 1.3, this seemed 
a particularly apposite time to assess the expanding role of PDF for publishers, 
designers and print professionals alike.
In 1999, Adobe began to promote PDF as a superior way to deliver print jobs to 
repro houses and printing plants. PDF has started to become viable as a graphic 
file format too, assisting digital delivery of advertising art; while the integration 
into Acrobat 4.0 of enhanced proof annotation tools gives it an expanded role 
in collaborative editing. Meanwhile, the ‘interactive’ side of PDF continues to 
develop with links to Web URLs, sound and video, scriptable electronic forms etc. 
Researchers are developing ways of adding metadata and structure to PDF.  
Finally, key elements of the graphics model which underpins PDF and PostScript 
alike lie behind the Scalable Vector Graphics format being developed for the Web.
Fundamentals and futures
Recognising that information on Acrobat can be hard to find, EPSG developed the 
programme of this event to ensure that important fundamentals were reviewed 
for the benefit of delegates relatively new to the use of Acrobat in publishing, and 
a Technical Question Time session gave us an opportunity to explore common 
problems. However, most of our speakers showed examples of new applications 
that are ‘pushing the envelope’ of what can be achieved with PDF and SVG.
Audio recording of the event has allowed us to report the speakers’ presentations 
in unprecedented detail, and they are presented here in the order given. However, 
we must confess one casualty. Chris Lilley of the World Wide Web Consortium 
gave a fine presentation on Scalable Vector Graphics, which was not recorded due 
to a glitch. As this topic was also at a slight tangent to the main thrust of the event, 
we have chosen not to try here to reconstruct his presentation from memory.
By presenting the proceedings of the event in this level of detail, we hope it will 
continue to play a useful role for an expanding circle of electronic publishers.
I take this opportunity to record my gratitude to the speakers – Peter Hibbard and 
Mike Clarke, Thomas Merz, Aandi Inston, Chris Lilley and David Brailsford – for 
their close co-operation with me and with each other before the event to ensure a 
balanced coverage of our topic. They truly made a terrific team.
Conrad Taylor, organiser of the EPSG Acrobat/PDF event.
About EPSG
many fascinating subjects, in a fast-
changing field. Desktop publishing, 
digital imaging, multimedia and now 
the Internet and Web challenge us 
to keep up to date with the rapid 
changes in our industry. What better 
way to keep up than to join a friendly 
group of like-minded specialists?
We know that professionals in this 
field need to understand a vast range 
of products, and that much of the real 
struggle is to get disparate elements 
to work together. Our position as a 
specialist group within the British 
Computer Society means that we 
are not attached to any commercial 
organisation, and can take a wide 
and independent view of events and 
The Group generally holds about four 
regular one-day meetings each year, 
mostly in London. These are kept to 
a size which permits people to meet 
and exchange ideas in an informal 
and stimulating atmosphere. Each 
such meeting covers a single subject, 
which allows us to focus on areas of 
particular interest. A typical meeting 
includes an overview of the topic, 
talks by experts at the forefront of 
the field, and examples of real-life 
Membership of EPSG is open to all. 
You do not have to be a member of 
BCS to join (though it does cost less 
if you are). More information about 
the Electronic Publishing Specialist 
Group is available from the Group’s 
office, or the Home page.
EPSG Office:
c/o Edgerton Publishing Services,
Pett Road, 
East Sussex
TN35 4HA,
Tel +44 1424 813003
Fax +44 1424 813301
Edited, illustrated, designed & produced by Conrad Taylor using Adobe software: FrameMaker+SGML, Illustrator and 
Photoshop for Macintosh, and the Adobe Minion and Frutiger font families. Event photography by Michael Popham. 
Screen shot on page 20 supplied by the University of Nottingham. © 1999 Electronic Publishing Specialist Group.
Extract image from pdf java - 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 pdf; pdf image extractor c#
Extract image from pdf java - 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 jpg from pdf; extract image from pdf java
The Many Faces of Acrobat & PDF
Conrad Taylor: an introduction
An Electronic Publishing Specialist Group meeting report
Introducing the many faces of Acrobat & PDF
Conrad Taylor
Conrad is a graphic designer, and a freelance trainer 
and consultant in electronic publishing and informa-
tion design. A member of the EPSG Committee for 
several years, Conrad had organised this day’s event 
and chaired it throughout.
In his introductory talk, Conrad recalled that in 
1991, Acrobat was pre-announced under the name 
at the Seybold San Francisco publishing 
conference by John Warnock, the CEO of Adobe 
Systems. Warnock argued that this technology was 
necessary because despite what was then starting to 
be called the ‘Information Superhighway’, document 
interchange was hampered by the lack of an inter-
change file format that would support graphically 
rich content, reconcile the text-encoding schemes of 
different operating systems, and reduce or eliminate 
the need to have the same fonts installed on the 
sender’s and the recipient’s machines.
Portable Document Format (PDF) was intended 
to play that role, turning documents into a form of 
‘electronic paper’. The imaging model was based on 
that developed for Adobe’s PostScript page descript-
ion language, conferring the immediate benefit of 
resolution-independence. If you zoom into a PDF 
page, you will see greater detail; also, when printed, 
PDF can take advantage of the higher resolution of 
a laser printer – unlike fax transmissions, which are 
stuck at a low fixed resolution.
A fine family of Acrobats
To achieve platform-independence so that PDF files 
could be made and viewed across several types of 
computer, Adobe developed and launched a suite of 
programs for DOS, Windows, Macintosh and Unix 
computers under the brand-name ‘Acrobat’.
Some of these programs (PDFWriter, Distiller) 
were developed to help users to 
PDF files from 
existing standard editing and design applications, 
such as Word, QuarkXPress, Illustrator, etc. Others 
were developed to allow users to 
from them, and 
with them.
Of the two PDF browser applications developed 
by Adobe, Acrobat Exchange was the more powerful 
and expensive version with which users could also 
edit PDFs to some extent, adding ‘Sticky Note’ 
annotations or a list of hyperlinked ‘bookmarks’, 
cropping pages and rotating them, deleting pages 
or merging pages from other PDF files, building 
hypertext links, and performing a number of other 
authorial tasks. From version 4.0, this software has 
been known simply as ‘Acrobat’ – an odd decision 
by Adobe which has caused some confusion.
Acrobat Reader was developed as a cut-down 
version of the browser, initially at low cost and later 
turned into free shareware. Reader allows users to 
read and print from a PDF file, and to use any hyper-
text links that had been placed there; but Reader 
users have never been empowered to make changes 
to PDF files, and one cannot save back out to PDF 
from Reader.
Fig. 1: Two roads to PDF, via PDFWriter, or via PostScript and Adobe Distiller
Reader or
PDF file
printer driver
Reader or
PostScript file
PDF file
Conrad’s Web site is one place from which this document 
can be downloaded:
Java Imaging SDK Library: Document Image Scan, Process, PDF
Using RasterEdge Java Image SDK, developers can easily open, read, edit, convert and such as: Bitmap, Jpeg, Gif, Png, Tiff, Jpeg2000, DICOM, JBIG2, PDF, MS Word
how to extract images from pdf in acrobat; extract images from pdf files without using copy and paste
Generate and draw PDF 417 for Java
Download the Java PDF 417 Generation Package and extract the file. type PDF417 barcode = new PDF417(); //Encode data for PDF 417 barcode image text in Java
extract photos pdf; how to extract images from pdf files
The Many Faces of Acrobat & PDF
Conrad Taylor: an introduction
An Electronic Publishing Specialist Group meeting report
Later, Acrobat Catalog was added to build search-
able indexes of collections of PDF files; and Acrobat 
Capture was created so legacy documents available 
only in print form could be scanned in, recognising 
not only the characters in the text but also their typo-
graphic styling, and converted to PDF form.
To provide for later addition of more capabilities, 
Acrobat browsers were constructed so developers 
could add features by writing ‘plug-ins’ for them.
How PDFs are made
As shown in Fig. 1 on the preceding page, there are 
two paths in everyday use for creating PDF from 
existing authoring applications (though in future, 
more applications may be able to write PDF directly).
Windows and Macintosh computers have system-
wide representations of internal graphic space (GDI 
for Windows, QuickDraw for Macs), and system-
wide printer drivers. Acrobat PDFWriter exploits 
this, appearing to users as a virtual printer. If you 
‘print’ to PDFWriter, the document’s page geometry 
is converted to an equivalent page description inside 
the PDF file that is saved to disk.
As an alternative, users with PostScript printer 
drivers can ‘print’ a page description to a PostScript 
file, which is converted to PDF with Acrobat Distiller. 
This route is preferred by graphic arts practitioners, 
many of whom use illustrations and photographs 
in the Encapsulated PostScript format. The high-
quality print-oriented image data in an EPS file is 
locked away in PostScript format, so PDFWriter is 
unable to render it correctly. Distiller has always been 
the only option available to Unix users, who do not 
have system-wide printer drivers. (However, from 
version 4.0, Adobe are not providing Distiller for 
Unix, only the Reader; Unix users will henceforth 
have to move PostScript files to a Mac or Windows 
machine for distillation.)
Whether you convert to PDF using PDFWriter 
or Distiller, there are dialogue boxes by which you 
request ‘Job Options’: e.g. you can define whether 
pixel-based images may be subsampled to a coarser 
raster, and what kind of compression techniques may 
be used on them. You may also choose whether font 
data is embedded into the file.
What happens to fonts in PDF?
Conrad showed slides with sections of PDF code to 
explain three ways in which fonts can be represented 
inside a PDF file.
At a minimum, the font’s name is unambiguously 
recorded, so that if the user reading the file has 
that font installed on his or her machine, it can be 
used to render and display the pages.
As the PDF file is being made, the metrics of each 
font used are recorded: e.g. the average width of 
stems, the height of capitals and lower case letters, 
the extent of ascenders and descenders, the degree 
of slope of italics, the set-width of every character 
in the font, and the character encoding used.
Finally, there is the option to save font data inside 
the PDF. Either full data for the font is written, or 
a subset consisting only of the characters actually 
used in the document.
In the first and third cases, it is clear that the font data 
is present and can be used to display the document 
correctly. But what if the font is not present on the 
user’s machine, and the author of the PDF file has not 
embedded the fonts?
When Acrobat browser software is installed, two 
special ‘Multiple Master’ font families are added to 
the system: one a fairly generic serif design, and the 
other a generic sans-serif. If a PDF file requires fonts 
that are neither on the user’s system nor embedded 
in the document, Acrobat generates a reasonable 
simulation of the missing fonts using outline data 
from the Multiple Masters, adjusted with reference 
to the font metrics data recorded in the file, so that 
at least the text will display with appropriate weights, 
widths and linebreaks, if not with 
fidelity to the 
original design. (See Fig 2, left, for a further explan-
ation of Multiple Masters.)
Fig 2: Minion MM is a Multiple Master font. Its set-
width and weight can be varied on a sliding scale 
along each axis. Adobe Acrobat uses two special 
Multiple Master font families as a base from which 
substitution fonts are synthesised to match the font 
metrics data recorded when the PDF was made.
Generate and draw UPC-A for Java
Download the Java UPC-A Generation Package and extract the file UPCA barcode = new UPCA(); //Encode data for UPC-A barcode image text in Java Class barcode
extract photo from pdf; pdf image text extractor
Generate and Print 1D and 2D Barcodes in Java
Graphic configuration options allow barcode image background, foreground QR Code, Data Matrix and PDF 417 in and UPC barcode supported by Java Barcode Generator
extract pictures from pdf; extract images from pdf c#
The Many Faces of Acrobat & PDF
Conrad Taylor: an introduction
An Electronic Publishing Specialist Group meeting report
Of course, this substitutional approach does not 
work with fancy fonts which generic masters cannot 
simulate, and certainly would not work with non-
Latin fonts. In such cases, one must embed font data.
A further issue is that while it may be technically 
possible to embed fonts, the font license may forbid 
it. The Enschedé Font Foundry in The Netherlands, 
for instance, forbids any embedding of its font data 
in either PostScript or PDF files.
But what is Acrobat for?
Conrad took the view that for much of its existence, 
Acrobat has been ‘a solution in search of a problem’. 
Several times, Adobe has seemed to shift its definit-
ion of what Acrobat could be used for.
Beyond paper:
At first, Adobe positioned PDF as a 
replacement for the paper document, a step towards 
the paperless office; a vision clearly expressed in a 
1993 Adobe Press book, 
Beyond Paper
. Corporate 
documents should no longer be faxed, photocopied 
or FedExed; they should be forwarded to colleagues’ 
screens as PDF. A document should be able to live its 
whole life on screen, saving forests’-worth of paper.
It is therefore ironic that PDF has become such a 
common file format on Web sites, but almost always 
to provide a document that people can print!
Proofing and collaboration:
After about a year, 
Adobe started pushing Acrobat as an excellent tool 
for designers to show page-proofs to their clients. 
Compared to faxed page proofs, the PDFs would be 
in colour, and the clients could use the Sticky Notes 
feature to annotate where changes should be made. 
However, this good idea was undermined by the 
inability to make detailed annotations integrated to 
the level that a proofreader would expect. A plug-in 
for Acrobat Exchange called 
did allow direct 
drawing and highlighting onto the PDF file, but the 
developer paid inadequate attention to the Mac 
version, failing to bridge one of the most common 
cross-platform communication scenarios, between a 
PC-based corporate and its Mac-based designers.
Adobe have now purchased the Re:Mark techno-
logy and are integrating it into version 4.0 of Acrobat, 
so this use of Acrobat as a page-proofing and collab-
oration technology may now take off at last.
Pages for the Web:
When the PDF standard was 
enhanced to level 1.2 and Acrobat 3.0 software came 
out, Adobe’s new tack was that one could use PDFs as 
a replacement for Web pages. Thanks to the Acrobat 
Reader plug-in for Netscape and Internet Explorer, 
PDF pages could appear in the browser window and 
links with HTML-based pages could be bidirectional. 
(This aspect of PDF use was discussed in greater 
detail by Thomas Merz, later in the day.)
In its first implementation, Acrobat 
allowed a user of Exchange to set up hypertext links 
from page to page within a single document, and to 
create a list of ‘bookmarks’ similarly endowed with 
hypertext linking powers. However, creating these in 
Acrobat Exchange was tedious, and if changes to the 
document content were required, one was forced to 
regenerate the PDF and re-create all the bookmarks 
and links manually.
Distiller was later enhanced to understand a 
special kind of PostScript comment called a 
and some document composition programs such as 
FrameMaker and Ventura Publisher were enhanced 
to write pdfmarks into the PostScript they created. 
This made it possible to generate bookmarks auto-
matically from selected levels of heading, and convert 
document cross-references to PDF hypertext links.
Presentations and multimedia:
Another job to 
which Adobe harnessed Acrobat was as a player for 
presentations, somewhat like Microsoft PowerPoint. 
(Most speakers at this conference used Acrobat for 
this purpose.)
To improve Acrobat’s suitability for this role, 
Adobe included an option for off-screen rendering of 
the next page so that it would be instantly ready for 
transferring to the screen, and they also introduced 
some inter-screen transition effects. They made it 
possible for the edges of type to display with an anti-
aliased effect, and in fact set this as the default display 
mode (many users complained about ‘fuzzy type’ 
and had to be shown how to switch anti-aliasing off). 
Additionally, Adobe enabled the embedding of a 
QuickTime movie in an Acrobat page.
It’s unlikely that Acrobat can usurp the position 
enjoyed by PowerPoint in the corporate world, as it 
does not offer the template-based authoring system 
and clip art of the Microsoft product. However, its 
image compression and font independence make 
Acrobat a good choice for presentations that are later 
to be posted to a Web site, as were some presenta-
tions at this event.
Delivery of documents for printing:
For some 
years, people have been delivering simple mono-
chrome documents to their print service suppliers as 
PDF files. This has been particularly true in technical 
publishing: for a documentation producer using 
.NET PDF SDK | Read & Processing PDF files
or grayscale raster images, search & extract text, highlight Advanced document cleanup and image processing options royalty-free .NET Imaging PDF Reader SDK of
extract image from pdf using; pdf image extractor
DocImage SDK for .NET: HTML Viewer, View, Annotate, Convert, Print
in .NET, including Microsoft Word, Excel, PPT, PDF, Tiff, Dicom of years before I found this .NET Image SDK. NET Document Imaging SDK and Java Document Imaging
extract pdf images; pdf extract images
The Many Faces of Acrobat & PDF
Conrad Taylor: an introduction
An Electronic Publishing Specialist Group meeting report
FrameMaker on a Unix system, PDF is a great way to 
hand off a document to a printing business equipped 
exclusively with Macs and QuarkXPress. However, 
major barriers stood in the way of PDF serving a 
similar role for publishers of full-colour magazines 
or high-quality marketing materials.
At the start of 1999, the PDF standard advanced 
to version 1.3, and the Acrobat software suite evolved 
to version 4.0 to exploit these possibilities. Amongst 
other things, PDF now includes the entire imaging 
model of PostScript Level 3, including sophisticated 
colour separation and colour management. Adobe, 
joined by printing-oriented companies as Heidelberg 
and Agfa, now promote PDF as the ideal way to send 
a print job to a print service supplier.
Has this strengthened role in the printing industry 
given Acrobat greater relevance today? There are 
strong signs that this is so, as Mike Clarke’s talk was 
later to demonstrate; however, not all of the elements 
are yet in place, and Aandi Inston’s talk was to show 
how the basic Acrobat software suite needed to be 
extended with plug-ins to do all of the jobs that are 
needed in a print workflow, such as managing colour 
separation, and organising pages into the imposition 
groups required for imaging onto printing plates.
Cautionary tales
As an information designer and a keen student of 
usability, Conrad offered two cautionary tales to 
temper enthusiasms for Acrobat.
The first case concerned research he undertook for 
the Child Poverty Action Group, to see whether their 
National Welfare Benefits Handbook
– an annually-
updated guide used by welfare benefits advisers – 
could be converted into a CD-ROM based electronic 
book. Both HTML and PDF were considered as 
methods of delivery, but the HTML option was set 
aside, perhaps prematurely, after early testing with a 
reference group. (This group had a strong resistance 
to scrolling-page displays; PDF was also seen as much 
easier to create than HTML.)
At first, the experiment seemed promising, 
especially since the Handbook is laced with cross-
references. This initially suggested that electronic 
hypertext would produce an enhanced, easier to use 
product; but the lack of physical clues to location 
(which the mere thickness of a paper book affords) 
meant that users got ‘lost in hyperspace’, to correct 
which a lot of the screen had to be given over to 
orientation and navigation clues and devices.
Another problem was that the coarse resolution of 
computer screens made small type difficult to read in 
Acrobat: either one puts up with the jaggies or allows 
Acrobat to render anti-aliased type. But Acrobat’s 
anti-aliasing, which does a good job with the large 
type used in presentations, is too fuzzy for small type.
To achieve some degree of reading comfort, the 
Acrobat prototype of the Handbook used 12pt type, 
so each screenful contained less than 40% of the page 
content of the A5 paper version. Considering the 
technical nature of the text, this was a problem: 
the atomisation of content into small pages made it 
more difficult to follow complex descriptions and 
recommendations. The project was abandoned.
Documentation horror story
Conrad noted that it is increasingly common for 
computer documentation to be delivered as PDF files 
on the installation CD-ROM. This saves costs for the 
manufacturer, but can be a nightmare for the user. 
As an example, he cited his personal experience with 
the SuperCard hypermedia authoring system.
The SuperCard documentation was authored in 
FrameMaker in a standard book format, 20cm tall by 
19cm wide, double-sided, comprising 395 pages with 
a 90-page Addendum. To avoid the expense of print-
ing and binding, it had been converted to PDF and 
dumped on the CD. Conrad wryly noted that to 
enjoy this economy in a usable format, he had to 
employ £8,500 worth of equipment and 10 hours’ 
labour to print, guillotine and Wire-O bind it!
To add insult to injury, the SuperCard author had 
printed all chapters to uncropped US Letter pages – 
some chapters landscape, and some portrait. Every 
now and then as he went through the manual, he 
encountered chapters lying on their side! Had he not 
had Exchange, rather than just the Reader, Conrad 
would have been unable to rotate some of the pages 
and crop all of them to print to A4 paper. 
As a final blow, Distiller  had been used with 
inappropriate Job Options settings: all screen shots 
had been subsampled and JPEG-compressed into 
complete illegibility. (Even Adobe have been caught 
out this way – in making the PDF version of their 
PageMill 3.0 manual.)
In summary, Conrad suggested that Acrobat is a 
wonderful technology, but one should be sceptical 
of claims about its ‘simplicity’ or ‘ease of use’. The 
difficulties one can encounter in using Acrobat are 
rendered all the more frustrating by the paucity of 
user documentation. He hoped that this conference 
would be a great opportunity to understand what one 
can do with Acrobat today, and in what directions it 
is evolving.
Zero Footprint AJAX Document Image Viewer| ASP.NET Imaging SDK
Converting Transform, convert and save web document or image file to PDF or TIFF com is professional .NET Document Imaging SDK and Java Document Imaging
extract vector image from pdf; extract images from pdf file
Image Converter | Convert Image, Document Formats
like ASCII, PDF, HTML, MS- Word, PDF/A Most Find image converters to suit your needs in this professional .NET Document Imaging SDK and Java Document Imaging
extract image from pdf online; extract photos pdf
The Many Faces of Acrobat & PDF
Peter Hibbert: Data structures in PDF
An Electronic Publishing Specialist Group meeting report
Data structures in PDF
Peter Hibbard, Adobe Systems
Peter Hibbard is a computer scientist who took part 
in the early development of Acrobat, and who set out 
to explain to us some of the early design principles 
which Adobe had incorporated into this technology. 
He explained that it had been Adobe’s intention 
from the start that Acrobat should provide a means 
to display ‘final-form’ documents with a very high 
degree of fidelity to the intentions of the designer, 
in a format which could be readily transmitted and 
archived electronically. Among other things, this 
dictated that an Acrobat document should be a single 
file, not a collection of files like a Web site.
A step forward from PostScript
PostScript was judged to be inappropriate as a file 
format for this application: the files can be large and 
slow to interpret, and to support large documents 
with many hundreds of pages, an interchange format 
would require internal indexes, accelerators and a 
well defined tree-like structure of internal objects, 
all of which PostScript lacks.
However, it made sense to build upon the success 
of the already established Adobe imaging model. 
This was also to ensure an economical interchange 
of data with PostScript so that no graphical attributes 
of the document would be lost.
Technical underpinnings
The team responsible for Acrobat started by consid-
ering how the internal representation of a document 
should be defined. It was decided that at the lowest 
level, the system should represent document data as 
objects of various types: booleans, numbers, strings 
of characters, names, key-value pair dictionaries and 
data streams, and also arrays built up of these objects, 
with ways of aggregating these objects into a hierar-
chical tree structure. (The most obvious example is 
that a page is an object with child-objects, including 
its contents, and annotations added to the page.)
It was also a design goal that the document struct-
ure which they were creating should be extensible by 
the addition of new key-value pairs to a dictionary, 
and by integrating new data types.
As for the role of Acrobat software in relation to 
this file structure, it was agreed that it should include 
a reading method for interpreting the PDF data into 
an internal detailed representation of the document 
structure, and a writing method for writing changed 
structure back out to PDF. The reading method 
would have to support incremental reading via look-
up of the index of a document’s object resources, so 
that individual pages could be loaded quickly and 
In outlining this separation between a completely 
defining file format (PDF) and the software required 
to read and write it (the Acrobat family), Peter added 
that the original intention had been that many more 
applications would have the ability to read and write 
PDF directly, but that this has been slow to develop.
Future pressures on Acrobat
Peter made the general comment that Adobe would 
have to consider external forces when figuring out 
where to take Acrobat, and that one of the biggest 
challenges has come from the Web.
The World Wide Web Consortium’s proposal 
for the Scalable Vector Graphics file format (SVG) 
has set out to achieve an imaging model equal to or 
better than the Adobe imaging model. At a simple 
level, Peter noted, it is trivial to map SVG imaging 
structures to Adobe ones. However, it is also intend-
ed to integrate additional features such as transpar-
ency, filters, animation and interaction;. This will 
challenge Adobe’s engineering teams to figure out 
how their applications can supply this functionality 
to publishers using SVG.
Before handing off to his Adobe colleague Mike 
Clarke, Peter mentioned that the beta-test version of 
a Java version of Acrobat Reader was now in circula-
tion. A Java Reader could be licenced by other manu-
facturers for inclusion in hand-held devices such as 
eBooks, he suggested.
Adobe speakers Peter Hibbard (l.) and Mike Clarke.
C# PowerPoint: Read, Decode & Scan Barcode Image from PowerPoint
C# PowerPoint: Decode PDF-417 Barcode Image, C# decode Intelligent Mail linear barcode image from PowerPoint NET Document Imaging SDK and Java Document Imaging
how to extract images from pdf file; how to extract a picture from a pdf
.NET OCR SDK | Optical Character Recognition
Able to extract text fromfacsimiles, photocopies and documents with usability interfaces to convert an image to a to memory, text searchable PDF, PDF/A, Word
extract pictures from pdf; extract image from pdf
The Many Faces of Acrobat & PDF
Mike Clarke: Is PDF ready for print publishing?
An Electronic Publishing Specialist Group meeting report
Is PDF ready for use in print publishing?
Mike Clarke – Adobe Systems
Mike Clarke works for Adobe in their Amsterdam 
office; his job is to ‘evangelise’ the use of PDF by the 
printing industry and its customers.
In posing his talk’s title as a question, Mike said, 
he was reminded of a EPSG meeting of perhaps ten 
years ago with a title something like ‘Is PostScript 
inevitable?’’Speakers at the time had concluded that 
PostScript had deficiencies but seemed the best thing 
on offer and so probably 
inevitable – and the rest 
is history. Mike expressed the hope that history was 
about to repeat itself, and that PDF is beginning to be 
accepted a serious format for print publishing.
Mike structured his talk around the requirements 
of three areas of activity within publishing where 
PDF is beginning to make an impact: the digital 
delivery of page components, especially advertising; 
delivery of jobs to commercial printers; and internal 
use of PDF within the workflows of periodical 
publishers (magazines and newspapers).
Page component delivery
When periodicals are trying to move towards a fully 
digital workflow, it is extremely frustrating if advert-
isers and their agencies still insist on delivering ads as 
sheets of separated film. Copydot scanning of these 
films to convert them back to digital data is a slow 
process, using expensive high-resolution scanners.
The better solution is to have the adverts delivered 
as digital files which can be placed within page make-
up software like any other art; and the ideal file 
format would be one that gives reliable fidelity to the 
advertiser’s intention, fits well in existing workflows, 
and ideally allows last-minute corrections.
At present, most digital delivery of adverts uses 
the Encapsulated PostScript file format (EPS). Mike 
described EPS as ‘a bit of a hack’: a two-part file 
consisting of PostScript data (which is never seen 
until it is output to a PostScript device) plus a low-
resolution raster preview image (which gives no clues 
about the quality of the associated PostScript data). 
He identified three main deficiencies of EPS:
The two halves of an EPS file can get detached; for 
instance, the PostScript data may be lost because 
a file ‘imported by reference’ gets deleted, moved 
or re-named, so only the preview image which has 
been imported into the page make-up software 
gets printed.
If specific fonts are required to ensure that the 
EPS-format ad prints correctly, the raster preview 
gives no warning of this, which may result in 
completely inappropriate fonts being substituted 
during the process of outputting to film or plate 
A EPS file may potentially suffer from all the 
typical problems which arise when PostScript has 
been written for a specific target printer, such as 
incorrect halftone screen rulings, inappropriate 
tonal transfer curves, etc.
Switching to PDF for digital delivery of artwork will 
bring benefits long before the time comes to transmit 
the advertisement to the periodical publisher. The 
file is smaller, and fonts can be securely embedded. 
The PDF can be sent for approval, and revisions can 
be requested by adding annotations to the file. (This 
facility has become much more versatile in Acrobat 
4.0, where one can draw directly over the page image 
and add ‘sticky notes’ to those marks, and also where 
a complete list of annotations can be reviewed in the 
viewing pane to the left.)
Small last-minute changes can be made without 
going back to the originating application; or, if it is 
desired to prevent such tampering, the file can be 
locked. Also Mike stressed the ease of moving the file 
cross-platform, and the ease of running ‘preflight-
check’ software against the PDF file structure.
Other advantages over EPS have come as a result 
of the upgrading of PDF to version 1.3, though Mike 
noted a current shortage of tools to exploit these 
features. For instance, job ticketing information may 
be added to a PDF file via PJTF, the ‘Portable Job 
Ticket Format’. Also, because PDF 1.3 encompasses 
all of the imaging facilities of PostScript Level 3, it 
is now possible to implement colour management 
by embedding an ICC profile. (An ICC profile is 
information, written in a format defined by the 
InterColor Consortium, which describes the colour 
gamut and tonal linearisation characteristics of a 
system – such as a colour monitor – within which a 
colour image was captured, created or approved).
At present, Mike confessed, an advert digitally 
delivered as PDF will most likely be converted to EPS 
at the last minute so that it can be placed in the 
publication, e.g. in Quark XPress.
The Many Faces of Acrobat & PDF
Mike Clarke: Is PDF ready for print publishing?
An Electronic Publishing Specialist Group meeting report
However, he demonstrated that Adobe’s new page 
make-up program, InDesign, can import PDF direct-
ly. If the selected PDF has multiple pages, you can 
choose (with a preview) the page to be placed; if 
multiple cropping rectangles have been defined for 
the page, you can choose between them; if fonts are 
missing, you will be advised. Once the PDF image 
is inside InDesign, it can be cropped, scaled, rotated 
or masked in the normal way; if small changes are 
required, you can launch Acrobat from within 
InDesign to make those changes. Finally, InDesign 
writes a final PDF of the whole publication directly – 
no need for Distiller – folding all the data from the 
imported PDF ad into the total PDF structure.
Is it happening?
There appear to be no technical obstacles to the 
digital delivery of artwork as PDF; there is a great deal 
of variation in the uptake of this method between 
different European countries, but this difference 
owes more to politics and organisation.
In Norway, 80–90% of display ads are digitally 
delivered – and mostly as PDF. This has been made 
possible by the collaboration of over 100 advertising 
agencies and 125 newspapers through NADA, 
Norske Avisers Digitale Annonseleveringssystem
– the 
Norwegian Publishers’ Digital Advertising Delivery 
System) which has laid down strict rules for creating 
PDFs, even giving out a PostScript Printer Descript-
ion file (PPD) for use when making PostScript, and a 
Distiller startup file to harmonise the application of 
Job Options. At present, the NADA system is based 
on the transmission of CMYK colour information, 
but other options are being considered.
Delivering jobs to commercial printers
In recent years, relationships between printers and 
their customers have become more ‘casual’, and a 
printer must be able to accept a wide range of jobs.
Typically, a printer today accepts application files 
from customers – usually Quark XPress files. This 
seems the wisest policy because it gives the printer 
the opportunity to make last minute corrections to 
the job before sending it to film or plate. The most 
common errors are things like inappropriate half-
tone screen ruling settings, wrong colour separation 
plate assignments and the like. If the printer is given 
a PostScript file, it is more difficult to check it, and 
impossible to change it.
Is PDF ready to step into this new role? In a sense, 
yes. At the Seybold electronic publishing conference 
in Boston in Spring 1998, the ‘PDF Experts Group’ 
published a white paper detailing the inadequacies 
of PDF 1.2 for commercial print; but at the Seybold 
event one year later, the Group’s representative, 
Stephan Jaeggi of Switzerland, was able to report that 
PDF 1.3 had met their objections at a technical level. 
(You can see the reports of the Experts Group at
PDF now supports smoothly graduated tints; 
masked images; and most significantly, the ‘DeviceN’ 
colourspace model, which makes it possible to define 
individual colour separations. This means that it 
is now possible to transmit a PDF that can be split 
into spot colour separations with duotones (photos 
printed in e.g. black plus one spot colour), or to 
support non-CMYK process colour systems such 
as Hexachrome.
Remaining problems in
PDF print workflow
However ready PDF itself may be, there are still some 
elements missing in the print workflow. For example, 
to separate duotone information from a PDF file may 
require a PostScript Level 3 RIP, and not all printers 
have these attached to their imagesetters.
There are also problems at the application end, 
especially for QuarkXPress users: the composite-
colour PostScript file that XPress produces is not 
written in a way that makes it easy to prise the colour 
information apart again into separations. (As Mike 
put it, “Xpress doesn’t expect you to do serious print-
ing from a composite-colour file”.
Problems of workflows and application support 
for PDF print delivery should clear up fairly quickly, 
but any printer who wants to accept PDF files from 
anywhere has to be aware of the current situation.
Commercial printers may also want to draw a line 
by supporting only a precisely defined subset of PDF 
called PDF/X which is being defined by CGATS to 
simplify job transfer. The initial standard, PDF/X-1, 
requires all printing data to be in a single file, but 
there is a second standard being drafted to permit 
some information to reside in external files.
Print-IT over the Web
One Web-based technique for sending documents 
to be printed is offered by Print-IT, an EC-funded 
research project on distributed printing in which 
nine companies have collaborated (Indigo, Adobe 
Systems, France Telecom Expertel, EDS, Il Sole 24 
Ore, KPN Research, Apple Computer, Drescher and 
Copyrama). The results are in the public domain.
The Many Faces of Acrobat & PDF
Mike Clarke: Is PDF ready for print publishing?
An Electronic Publishing Specialist Group meeting report
Mike demonstrated this, using an Acrobat plug-in 
which does a preflight check of the PDF file intended 
for transmission, connects to the print provider’s 
Web server and collects a PDF form by means of 
which which the print requirements are requested 
(print run, paper stock, binding, delivery address 
and so on). When this data is submitted, the print 
provider’s server will generate a quotation; if this 
is accepted, the print requirements are rolled up 
into the PDF job file in PJTF format and the PDF 
is uploaded to the server.
PDF in periodical workflows
Finally, Mike looked at the emerging role of PDF in 
the workflows of large commercial publications such 
as magazines and newspapers, where the scale of 
production often dictates long distances between the 
editorial offices and the print plant – or plants, if 
the publication is simultaneously printed in several 
cities. The more timely the news is, the less approp-
riate it is to image films at the editorial offices and 
physically transport them to the printing plant.
In the recent past, some publications have trans-
ferred page data as high resolution facsimile files in 
the TIFF-IT format, one such file for each colour 
separation. PDF files are smaller, because PDF is 
based on vectors and tonal bytemaps, encodes text as 
text not spots, and has various forms of compression. 
Still greater filesize benefits can be obtained if the 
workflow between publisher and printer is based on 
composite colour, perhaps even RGB colour, relying 
on the power of Level 3 RIPs at the printers to do in-
RIP separation, colour management, and trapping.
As a case study, Mike mentioned 
, which has delivered all its pages to the printer 
as PDF for more than a year. One very large publisher 
which has also gone down this route wholeheartedly 
is Bath-based Future Publishing. Particularly for 
large-scale operations, Mike pointed out, the simple 
factor of smaller file size can produce substantial 
savings of investment both in filestore capacity and 
transmission bandwidth.
In summing up, Mike asserted that we should now 
look to publishing application developers to provide 
better integration of colour management and job 
metadata into the PDF file structure. This 
done by embedding pdfmarks into PostScript files 
which are later distilled, but in the long term the 
better solution would be for more application soft-
ware to write PDF files directly.
Questions to Mike Clarke
Conrad asked Mike to comment on the difficulty of 
generating a PDF with different Job Option settings 
for different images: it may be OK to subsample and 
JPEG-compress a photograph, but a screen-dump 
should receive only lossless compression. There are 
ways of hacking PostScript to do this, but it would be 
nicer to have a way of  requesting exceptional over-
rides to Distiller Job Option settings in the page 
make-up program, on an image-by-image basis.
Mike agreed that this is a shortcoming of Acrobat 
at present. Commenting on Conrad’s proposal, he 
said that passing control data via PostScript with the 
aid of pdfmark comments is a clumsy and difficult 
method; it would be better if applications could write 
PDF directly, in which case they could handling each 
image as the user had requested.
Another questioner asked if image compression 
in PDF was now so good as to make it unnecessary to 
use OPI (Open Prepress Interface) systems, in which 
scanned image data is stored separately and merged 
with the publication data at the point where film or 
plates are made. Mike thought that increasing trans-
mission bandwidth might make OPI unnecessary 
as a strategy, but that some workflows which use lots 
of high-resolution photography would still benefit 
from OPI. (PDF does support OPI workflow.)
In answer to a question about Corel’s support 
for PDF, Mike replied that Corel support PDF in 
their graphics applications, in a manner which he 
considered the perfect solution – they had licenced 
the PDF-creation technology from Adobe. This 
should be good news for users as well, he suggested: 
it’s best if there is only one dialect of PDF.
Finally, in answer to a question about whether 
PDF information could drive a multi-tray printer 
(such as a Docutech) to print certain pages on certain 
kinds of paper stock, Mike replied that this is already 
possible to a degree in PostScript, though usually 
only to vary the stock used for the first page. To 
provide this feature, there would have to be a control 
interface, which would probably have to reside in the 
originating application. (Later in the day, Aandi 
Inston was to speculate that this could be a role for 
an Acrobat print-oriented plug-in).
The Many Faces of Acrobat & PDF
Thomas Merz: PDF on the Web and on the fly
An Electronic Publishing Specialist Group meeting report
“PDF on the Web and on the fly” 
Thomas Merz
Thomas introduced himself as a freelance writer, 
journalist and software developer based in Munich. 
He explained that because he aims to get computing 
applications to work, and seeks to explain to others 
how to use them effectively, he likes to study ‘behind 
the scenes’. This curiosity provided some of the 
motivation for his writing software that generates 
PDF without using the Acrobat tools.
The title of his talk referred to the two topics he 
addressed: firstly, an exploration of the use of PDF 
as a format for pages on the World Wide Web, and 
secondly an explanation of his techniques for gener-
ating PDF on demand.
Integrating PDF into the Web
Many publishers already use Acrobat Distiller to 
convert print-oriented documents to PDF, and then 
make these files available on their Web sites.
This is relatively easy, so much so that when 
Thomas recently published his second book, 
Publishing with Acrobat/PDF
, some people asked him 
what the big deal was: don’t you just make the PDF 
and put it on the Web? Why write a book about it?
From the point of view of a Web user, at least if 
they use a Netscape or Microsoft browser, PDF and 
HTML Web content can now be much more tightly 
integrated together, thanks to the Acrobat Reader 
plug-in and the Web-oriented functionality which 
came with Acrobat 3. Hyperlinks can now go from 
PDF pages to HTML ones as well as the other way 
round, and PDFs can appear embedded in the Web 
browser window. This opens the door to more 
imaginative and interactive view of PDF on the Web.
The PDF format has been enhanced in other ways 
to aid its use on the Web. Everything one can do with 
an HTML form can now be done on a PDF form: it’s 
fair to say, indeed, that the PDF form features are a 
superset of those in HTML. There are also multi-
media features in PDF, so that a PDF document 
can be used to present audio and video clips.
Another development which blurs the boundary 
between the Web and PDF is WebCapture, which 
is part of the full version of Acrobat 4.0. This is an 
HTTP client and HTML formatter which can be used 
to render a Web site as a PDF document, converting 
all of the links, form elements and so on into their 
PDF equivalents – as David Brailsford was also later 
to explain.
Why use PDF on the Web?
The major reasons cited for using PDF on the Web 
is that, compared to HTML, it offers precise and 
flexible control over page layout; it can transfer font 
data with the file; it is also more appropriate for long 
documents and where good quality printability has 
to be assured. However, a number of criticisms are 
often advanced as to why PDF might be inappro-
priate for use on the Web:
PDF files can be quite large, with correspondingly 
slow transfer times.
The PDF file structure is thought inappropriate 
for streamed delivery to a browser, because 
important file directory information is at the 
tail-end of the file and so arrives last.
Link management is thought difficult, because 
the link data structures are buried somewhere in 
the file structure, in a way which makes it difficult 
to update and repair links.
Internal links within PDF documents sometimes 
fail to work when they are viewed in the browser 
window via the Reader plug in (this is a problem 
of implementation in some versions of browsers).
Although millions and millions of copies of 
Acrobat Reader are now deployed, it’s still the 
case that most users of the Web don’t have the 
Reader – and won’t be bothered to go download 
and install software just to see one particular site.
In comparison to the ease of generating HTML 
content dynamically from a database, it is very 
difficult to generate PDF on demand to fulfil the 
same purpose of data-driven publishing.
Thomas proposed to lay some of these ghosts to rest, 
or at least quieten them.
Controlling PDF filesize:
One major problem that 
publishers have is learning how to control the size of 
Distiller-generated PDF, through intelligent use of 
the Job Options. In Thomas’ experience as a trainer 
and consultant, too many publishers simply place on 
the Web the same high-quality PDFs that they have 
generated for repro. To make smaller files, it is wise 
to redistill the source PostScript, choosing Distiller 
Job Options settings which reduce the resolution of 
document images through downsampling, and apply 
an appropriate method and degree of compression. 
Documents you may be interested
Documents you may be interested