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/
