Your are correct, PDF/A is for archiving (which is the area we work
in), PDF/X is for print. I only recent became aware of these ISO
specifications. I think this will be our direction. My mistake.
The MOST Important issue (coincidentally that you did not address) is
that the PDF specification is controlled by Adobe. I don't think it
takes a crystal ball to figure out why. It is so Adobe can
continually "change" the specification in the name of innovation, in
order to render other people's tools at least temporarily obsolete.
With Adobe's considerable size and resources it is able to keep its
tools up to date (usually) with its own specification, but most
cannot. Sounds eerily similar....
I would argue that 99% of the pdfs in existence use 10% of the
specification. PDF Reader has become bloat-ware because the
specification is bloated. We ship a PDF viewer that handles most of
the important parts of the PDF specification in a 200k jar file.
Adobe Reader is 80mb and then some???
I just think if you look at ALL of the interactive features, there
are probably far better ways to handle them (even via flash 'applets').
I think by diverging PDF from its original goal, it has lessened its
impact. The ISO standards are a step in the right direction.
If you are trying to develop "software" in PDF, or using PDF as a
delivery model, I think there are probably far better methods.
I really respect PDF and could not image doing prepress, or
distribution documents (M$ Word??? ugh...) without it.
i think it is just a shame that Adobe is trying to make it all things
to all people. Anyone remember the Simpsons episode where Homer
designed the car? Granted, you don't have to use all of the
specification...
Curious, does Acrobat allow an option 'Save as PDF/A'? or 'Check PDF/
A compliance'?
On Jan 1, 2007, at 6:46 AM, Leonard Rosenthol wrote:
On Dec 31, 2006, at 8:13 PM, robert engels wrote:
What is missing from PDF that you think is required for a static/
fixed document format?
You missed the point my original statement. It is a great layout/
static format.
It is a poor interactive dynamic format,
Depends on your definition of an "interactive dynamic format"...
People have done some AMAZING things with PDF in terms of
interactive catalogues & brochures. There are also excellent
eLearning-type solutions out there based entirely on interactive PDFs.
That said, I agree that it doesn't do everything that it could
potentially do in this area - but there are actually reasons for
many of those...a lot of which do indeed go back to the mentality
that PDF is "static content".
Which is why we're working on technologies such as Apollo (<http://
labs.adobe.com/wiki/index.php/Apollo>) where the interactivity of
Flash & AJAX are blending with the richness of PDF.
and all of the dynamic/interaction capabilities that have been
added make it an extremely complex specification, which also
hampers the ability to create alternative PDF readers.
Everything is documented and published - and has been since
version 1.0. Sure, the more we add to PDF the more WE have to add
to Reader/Acrobat and the more others can choose to support in
their viewers. FWIW, even Adobe Reader/Acrobat do not support 100%
of the PDF spec ;).
But how do you innovate otherwise??
I challenge you to create a simple document that lays out
differently based on the client viewers screen resolution, size,
or accessibility needs. It can be done, but it certainly is not easy.
That's not what PDF is about...
HOWEVER, a Tagged PDF (<http://www.planetpdf.com/enterprise/
article.asp?ContentID=6067>) when opened in Adobe Reader/Acrobat
can be reflowed to indeed match the users screen & window sizes -
just like HTML, etc. And since PDFs created by a variety of
programs and tools can created Tagged PDF - I can easily do what
you ask - as can you!
Such as? Name me one plugin from Adobe Systems for Acrobat that
is Windows-only?
By even allowing the user to add arbitrary third-party content
that is not controlled by the specification itself opens the door
that certain documents will only be viewable on certain systems.
Interesting argument - but I don't buy it ;).
The reason that "arbitrary 3rd party content" can be added to a
PDF is because of the same design flexibility that makes it
possible for Acrobat 2.0 to open up a PDF created by Acrobat 8!
That's 6 versions and over 10 years of innovation...YET, the design
works! How is this possible? Because the viewer simply "ignores"
stuff it doesn't know about - BY DESIGN!
Also, that a document might require a plugin that is tied to the
Reader API limits the usefulness as an interchange format (since
any competing viewer probably will not have the Reader API - but
might support the JavaScript and DOM).
Now you are entering the interesting discussion areas of PDF vs.
Viewer design.
Adobe has made a clear distinction that JavaScript (and it's DOM)
do NOT get access (either read or write) to the actual content of
the document. It may work with "structural elements" such as
bookmarks, form fields, etc. but it can't change what the users
sees. This is, again, by design. The reasons should be obvious
and take us back to the above discussion of where technologies such
as Apollo fit in.
Just because Abode doesn't ship an 'Windows' only plugins does not
make any difference. I am sure many of the plugins they do ship
won't work with their Palm OS reader.
FYI: Reader for Palm OS doesn't actually view PDF documents - it
views a special format that is created by the "bridge". Reader for
Pocket PC, however, is a true PDF viewer.
The ISO standardized version PDF/Archive is a subset of PDF
designed for the print industry - WHICH IS EXACTLY WHAT I SAID PDF
SHOULD BE.
Interesting that you should bring up PDF/A, since I've been a
member of the PDF/A committee since the inaugural meeting and am
currently the editor of the PDF/A-1 application notes and PDF/A-2
specification in my role as Adobe's Technical Standards Evangelist
for PDF standards.
So first, PDF/A is NOT for the print industry. PDF/X (<http://
www.pdfxreport.com/faq.html>) is for the print industry. It too is
an ISO standard, and was the first such one, currently representing
4 different flavors with two more in DIS.
PDF/A is instead about long term archival storage of electronic
documents in the PDF format.
Also, PDF/A is based on PDF 1.4.
PDF/A-1 is based on 1.4, though the current draft of PDF/A-2 is
based on 1.6, though it is expected to move to 1.7 before DIS.
All of this points to exactly what I said. PDF and what it has
become is a VEY POOR standard.
PDF is a very rich standard, and as such may not be completely
suitable for certain specific uses. That's the whole reason that
the ISO PDF committees were formed - to create subsets of PDF that
focused on specific verticals such as print, archiving, engineering
(PDF/E), etc.
Please don't generalize!
PDF does not contain any information of the logical structure of
the document, which make relayout or other interaction features
very difficult.
PDF has supported logical structure (called Tagging & Structure)
since Acrobat 4 (PDF 1.3). In fact, it is the basis for the
differences between PDF/A-1a and PDF/A-1b. 1b does not require the
inclusion of structure while 1a does.
There are many PDFs in existence (not normally recent ones) that
you cannot do any full-text search on, because of the proprietary
font encodings and lack of unicode mappings.
That's true, but that's because Unicode didn't exist when PDF 1.0
came out. But when it did, it was added to PDF 1.2 (Acrobat 3).
The fact that 3rd party PDF creation tools chose (or in some cases,
to this day, choose) not to use that feature isn't our fault. We
added it a LONG time ago and have used it pretty consistently from
our own tools for many years.
SVG is an excellent tool, but it's viewability is limited :(.
There are MANY SVG viewers, including direct support in many
browsers.
Yes, but just like PDF viewers, NONE of them COMPLETELY implement
the SVG 1.1 specification. For that matter, most don't even fully
support 1.0.
I think it is far easier to find a "open" SVG plugin to view maps
for a browser (or even for Reader), than to develop a proprietary
plugin for Adobe Reader to view maps in a proprietary format.
I guess I don't understand what you are missing from PDF today
that you need to support maps in Reader? I am not saying there
isn't anything - but I'd like to know what YOU think is missing!
Because I can then take that information back to the Acrobat
engineering team (of which I am a senior member) to get it
evaluated for inclusion in the future.
We just shipped Acrobat 8 - which means NOW is a good time to
start considering the future...
Leonard
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://itext.ugent.be/itext-in-action/
