Can SVG be a potential replacement for PDF?

[Mark]

I'm curious to get feedback regarding the potential SVG has in
performing the same functionality as PDF for fixing documents.

Thanks.

Mark

 

[Aandi Inston]

I'm curious to get feedback regarding the potential SVG has in
performing the same functionality as PDF for fixing documents.

"fixing"? In what sense were they broke?

 

[Robert M. Franz (RMF)]

Hi Mark

I'm curious to get feedback regarding the potential SVG has in
performing the same functionality as PDF for fixing documents.

SVG is a graphic format. How would you pack a multi-page document into
that ...?

2cents
Robert

 

[Mark]

Mark wrote:

SVG is a graphic format. How would you pack a multi-page document into
that ...?

Each page has its own SVG graphic?

Mark

 

[Robert M. Franz (RMF)]

Each page has its own SVG graphic?

That seems impractical at best.

You really want to replace one PDF file with [enter your favourite whole
number] SVG files ...?

Greetinx
Robert

 

[Mark]

Mark wrote:

That seems impractical at best.

You really want to replace one PDF file with [enter your favourite whole
number] SVG files ...?

So the SVG spec has not included the functionality to have multiple
SVG graphics within a single SVG file? (Of course, multiple SVG
graphics can be embedded within an XML document using a schema which
supports islands of SVG markup.)

To rephrase, does SVG have the power to be a substitute for PDF on a
page-by-page basis? For example, could SVG be used to produce IRS
forms which would look identical to the PDF versions? Or does
Postscript still have more power than SVG at the exact "fixation" of
text on a page?

Mark

 

[Dick Margulis]

"fixing"? In what sense were they broke?

Aw c'mon, Aandi. His meaning is clear enough. Fixing in the sense of
locking (as in fixing a microscopic specimen on a slide, for example).

 

[Ralf Koenig]

I'm curious to get feedback regarding the potential SVG has in
performing the same functionality as PDF for fixing documents.

"fixing" in the sense of "prepare a self-contained, platform-independent
stand-alone document including all resources".

To answer the question in the subject: Yes, but ...

If you compare the specs, the scope of both of SVG and PDF is pretty
much equivalent. Both build upon the Adobe graphics model for rendering
objects: They share stuff like coordinate systems, graphics stack,
operator names for basic obejcts, set of allowed operators, all this
low-level stuff.

PDF is more mature in terms of specification of embedded blobs
(compression algorithms, fonts, images), but XML (and therefore future
versions of SVG) is extensible enough to support this as well. SVG would
be a lot more accessible though with a simpler structure.

There are relatively good converters between PDF<->SVG, which kind of
proves their strong relationship.

The following three are very close to each other conceptually:

* PostScript :
* strengths in printing (fonts, halftoning, support of device
dependent features in PPD, ...)

* PDF : derived from PostScript with more "web features"

* multi page documents with navigation
* much better structure than PostScript
* better compression algorithms
* mostly device-independent
* optional linear organization to improve streaming
* object tree for page independance
* support of hyperlinks
* fillable fields
* bookmarks
* scripting with JavaScript
* document meta data
* document security model
* better performance by stuff like xref table, incremental write
* one-vendor spec with advantages (consistency, reference
implementation) and disadvantages (dependency, patenting issues, ...)
* commonly seen as too complex with too many features
* specializations: PDF/A for archival, PDF/X for printing and
reliable document exchange in the graphics and publishing industry

* SVG :
* XML-based
* extensible
* single page documents
* easy to make simple examples
* scripting with JavaScript
* fits XML-based workflows best
* but: XML with namespaces gets more complex
* SVG moves towards multiple implementation profiles to support
embedded applications such as mobile phones, where PDF would be too complex
* so far Adobe makes the most wide-spread SVG viewer, it's in their
hand whether they push SVG or PDF. So far, they pushed PDF.

Microsoft wants to push SVG with Longhorn, but - as usual - they made
their own dialect of SVG called WVG (Windows Vector Graphics) with
extensions.

It's just that PDF seems to be the best mix with best software support
currently, which explains the predominance of PDF over SVG. This may
well change when SVG support esp. in browsers, features and maturity
improve.

Ralf

 

[Guest]

I understand by "fixation" you mean location or position on the page. PDF
is normally limited by the page resolution you've selected (default 1200
dpi) but can go higher (not sure of the limit). Remember, the PDF format
can and often uses a text searchable format, as well as meta-words
(keywords) and indexing to further apply the use of PDFs. An all graphic
format could have some of this, special when combined with an additional
markup or embedded application (xml, html and so on) but I doubt it would
work as smoothly nor is it likely that 3rd party software would be as
willing to interface (we like really, really well defined standards). As
for identical looking documents, you picked a very good example. IRS pdf
forms typically use a number of fonts, some not so common, to build the form
and this is where differences may start to occur (size of the dots,
arrowheads, and serifs on characters are often troublesome). Although these
differences may be miniscule, it could make some forms non-machine readable,
such as a the "notorious" Medicare services application CMS-1500 form. I do
agree however, that you certainly could build a graphic alternative to just
about any form and pass it for the original, except for text (searchable)
and embedded information, I am just not sure as to why.

Larry T.

 

[Jan Roland Eriksson]

Microsoft wants to push SVG with Longhorn, but - as usual - they made
their own dialect of SVG called WVG (Windows Vector Graphics) with
extensions.

What else is new

It's just that PDF seems to be the best mix with best software support
currently, which explains the predominance of PDF over SVG. This may
well change when SVG support esp. in browsers, features and maturity
improve.

Not forgetting the fact that Adobe's PDF reader handles SVG just fine as
it is (via a plug in for Acrobat).

 

[Ralf Koenig]

Mark wrote:

Each page has its own SVG graphic?

That seems impractical at best.

You really want to replace one PDF file with [enter your favourite whole
number] SVG files ...?

Well, put them into a zip-archive, and you have a nice single file
package. That's what OpenOffice does, or Java archives (jar).

So the SVG spec has not included the functionality to have multiple
SVG graphics within a single SVG file?

Well, you can read, look it up in the spec for SVG V1.1 (the current
"stable" spec).
http://www.w3.org/TR/SVG/

SVG V1.2 (draft) includes a model for multi-page documents.
http://www.w3.org/TR/2004/WD-SVG12-20041027/

(Of course, multiple SVG
graphics can be embedded within an XML document using a schema which
supports islands of SVG markup.)

That's what the multi-page feature of SVG 1.2 does, essentially.

To rephrase, does SVG have the power to be a substitute for PDF on a
page-by-page basis?
Yes.

For example, could SVG be used to produce IRS
forms which would look identical to the PDF versions?

Yes, including all the form and scripting stuff when combined with XForms.

If you are mainly interested in printing: Take a current PDF to
SVG-converter, and it will convert the PDF to single page SVG files.
These files will look identical to the PDF version, when using an
uptodate SVG viewer, on screen and on paper.

Example converters:
http://www.pdftron.com/pdf2svg/ - There is also a demo version.
http://www.pstoedit.net/pstoedit - with SVG plugin
many more ...

Or does
Postscript still have more power than SVG at the exact "fixation" of
text on a page?

Theoretically no, as both rendering models allow arbitrary precision in
placing graphics objects via transformation matrices.

But PDF and/or PS include some more printer-related functions: Alternate
colorspaces (CMYK, Device-dependent, spot colors ...), rendering intent
plus a few more. That's why SVG V1.1 is unsuitable for professional
graphics in print. SVG V1.2 will address some of these issues.

But in practice, Postscript may achieve better results for other
reasons, than a better model. Postscript is supported by many advanced
printers natively and licensed from Adobe. Since Adobe has control over
every sold Postscript printer, they can achieve a high level of
compliance to many details.

So, with Postscript there is less chance for errors. Printer makers
already started to put PDF renderers into the firmware of their
printers, e.g. current HP LaserJet models.

With SVG, there may be a longer pipeline of software (drivers,
converters, ...) where inconsistencies between different implementations
could cause differences.

Mark

Ralf

 

[jeroen]

For completeness sake, I'll mention our own commercial PDF to SVG batch
conversion software, pdf2vector, which is regularly chosen to convert
forms. It has different options to deal with fonts, which indeed tends
to be the main hurdle for an accurate conversion.

My simple take on this subject: SVG conceptually can be able to replace
PDF, since the core imaging model is indeed very similar. But the
current specification will need to be expanded with a number of
document/print-related features to make that happen. And then of course
there's the whole thing of industry support and application
infrastructure.

But to give an example: our software has been implemented to serve
multi-page financial reports from Oracle Reports (generated as
PostScript) to the client's Web browser as SVG (using Batik and a Java
applet for rendering). They chose this over PDF, so that the user's
workflow would not be disturbed by Acrobat Reader taking over his
browser window. The pages are a combination of graphics, images and
text.

Jeroen Dekker

 

[paron]

In addition (I don't think this has been mentioned here) SVG is an open
standard, and PDF is not.

If I can output SVG from my python script (python has been held back
from universal domination by crummy text and graphic output, IMO), then
I can view it or print it in any compliant application, on any
platform. You have to mumble that word "compliant" REALLY fast, but
the potential is there.

For that matter, I can read it and munge it in any XML-aware
application. I hope Adobe decides to "push" SVG over PDF. It makes
commercial sense, I think. "Microsoft =>proprietary; Adobe=>open" is
what they should foster in developer's minds.

 

[Berislav Lopac]

For that matter, I can read it and munge it in any XML-aware
application. I hope Adobe decides to "push" SVG over PDF. It makes
commercial sense, I think. "Microsoft =>proprietary; Adobe=>open" is
what they should foster in developer's minds.

With recent purchase of Macromedia by Adobe, I can easily imagine an utopia
where both Acrobat and Flash natively produce SVG output.

Berislav

 

[Aandi Inston]

In addition (I don't think this has been mentioned here) SVG is an open
standard, and PDF is not.

According to Wikipedia, which is hardly infinitely reliable, but is a
starting point:

http://en.wikipedia.org/wiki/Open_standard
"Open standards are publicly available specifications for achieving a
specific task."

http://en.wikipedia.org/wiki/Pdf
"PDF is an open standard"

There doesn't seem to be much universal agreement as to what "Open
standard" means. How do YOU define it?

 

[paron]

I guess I had in mind a standard promoted by a non-commercial body like
the W3C. Adobe could do whatever they like with the PDF standard, even
though they publish it. Of course, so could the W3C with SVG, I guess.

It's certainly possible to make a good argument that PDF is as open and
stable as SVG, and I don't want to argue with wikipedia -- too many
people watching it for it to be very far off base.

Still, I prefer SVG -- what if the MacroMedia deal fell through,
Microsoft bought Adobe, and radically altered (extinguished)PDF? Or
some other scenario that can happen to a commercial enterprise that
can't happen as easily to a non-commercial enterprise?

Anyway, that's why I'd prefer SVG. Perhaps I'm overly cynical about
commercial enterprise, maybe not cynical enough about the W3C.

 

[Ralf Koenig]

In addition (I don't think this has been mentioned here) SVG is an open
standard, and PDF is not.

What about:
http://partners.adobe.com/asn/tech/pdf/specifications.jsp

What about the free tools (all non-Adobe and non-commercial) at:
https://rnvs.informatik.tu-chemnitz.de/twiki/bin/view/Main/FreePdfUtilitiesAndLibraries

Why is SVG more "open" then?

If I can output SVG from my python script (python has been held back
from universal domination by crummy text and graphic output, IMO), then
I can view it or print it in any compliant application, on any
platform. You have to mumble that word "compliant" REALLY fast, but
the potential is there.

The following *free* libs ease PDF output from Python:

ReportLab Toolkit
http://www.reportlab.org/rl_toolkit.html

PDFlib lite
http://www.pdflib.com/products/pdflib/download-source.html

For that matter, I can read it and munge it in any XML-aware
application.

You're right here. SVG is much more accessible when reading files.

I hope Adobe decides to "push" SVG over PDF. It makes
commercial sense, I think.

I don't think so. Why reinventing everything?

Why not release an "official" way of expressing PDF in XML such as an
XML schema with a spec, and free reference implementations of converters
between PDF 1.6 (and lower) <-> PDF-XML 1.6? Then, all of a sudden, you
could process (parse, read, generate, modify, write) PDF-XML files with
your favourite XML tools. And by linking the converters to existing
programs, current applications could support PDF-XML with little
modifications.

Adobe is definitely working on that but they did not release any
documents or software for the conversion yet - AFAIK. I heard of
commercial Adobe software to do these conversions, but they are
big-money solutions.

It can't be that hard to come up with a reasonable (and standard!) way
of expressing the semantics of PDF operators and constructs in XML
syntax, enabling lossless conversion between the two formats. Again, a
big problem are binary objects so far. What parts of them should be
accessible via XML elements, what parts should remain in binary form for
compatibility with exisiting software and for efficiency?

"Microsoft =>proprietary; Adobe=>open" is
what they should foster in developer's minds.

That would be far too simple.

Ralf

 

[Aandi Inston]

Why not release an "official" way of expressing PDF in XML

Here's one:

< pdf >...contents of PDF 1.6 file in asci85 format ... < /pdf >

It's hard to see what advantage it would have, except being 20%
larger, and thereby helping struggling disk space manufacturers.

If you are talking about an XML mapping of PDF at a lower level, it's
worth bearing in mind that, in order to produce PDF files of a
reasonable size, Adobe had to add binary, compressible, streams
collecting together many objects...

This would not be an easy sell. "Use new miracle PDF XML! It's just
like the old PDF, except that very few applications handle it so far,
and it's several times larger than the original PDF".

 

[paron]

I'd really like to do input and output on screen and output on paper
using one technology. SVG just seems like the best bet, if a large
segment of the industry supports it. I could design specialized GUI
widgets and output results either to screen or paper, cross-platform,
without using proprietary formats.

If only SVG were adopted as a standard for graphic work by a large
segment of the industry.

As Berislav says, ". . . utopia . . ."

 

[Mark]

"paron" wrote:

According to Wikipedia, which is hardly infinitely reliable, but is a
starting point:

http://en.wikipedia.org/wiki/Open_standard
"Open standards are publicly available specifications for achieving a
specific task."

http://en.wikipedia.org/wiki/Pdf
"PDF is an open standard"

There doesn't seem to be much universal agreement as to what "Open
standard" means. How do YOU define it?

This is true -- there is not a comprehensive and accepted definition
of "open standard".

Many people, though, feel that in addition to the standard being
published and everyone can use it royalty-free, that an "open
standard" must also be controlled by a consortium of competing
companies and organizations in their sphere of interest. The PDF
specification, for example, is not controlled by the "PDF Consortium".
Rather, it is ultimately controlled by a single corporation: Adobe. On
the other hand, SVG is essentially controlled by W3C, which comprises
a large number of corporations and organizations, many of which
compete with each other.

Mark