W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2001

Re: on the adobe issue

From: David Woolley <david@djwhome.demon.co.uk>
Date: Sat, 27 Oct 2001 10:30:46 +0100 (BST)
Message-Id: <200110270930.f9R9Ukv07621@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org
> This is not true. There are two potential patents that are known, and neither

I assume that you are specifically challenging the patents issue and the
level of implementation, even though this is worded as though every statement
were being challenged.

> is expected to have any impact on SVG tools. There is at least one free open

I'm going by the public SVG mailing list on which the public version of
the patent claims was aired and there was no subsequent (except possibly
when I was on leave) discussion about their having no impact.

As I remember it, some contributors were prepared to waive royalties,
some were prepared to waive royalties if all others did so, and at
least one (IBM I think) was not prepared to waive royalties, but only
to charge "reasonable and non-discriminatory" royalties (thus changing
the conditionals into royalty requirers##).  I think generally they were
only prepared to waive or license on "reasonable and non-discriminatory"
terms to the extent that the patents were essential to the implementation
of SVG.

Where the confusion may arise is that many didn't explicitly enumerate 
patents, or only indicated that they might affect some ways of implementing
SVG.  I think one indicated that one sub-area of the specification would
probably conflict with the patent, but I can't remember the licensing terms
that they offered.  I haven't read the SVG spec in enough detail, nor read 
the patents listed, to make an opinion as to whether they are necessary for

If it is true that there are no patent conflicts involved with implementing
SVG, it would also imply that the companies were simply protecting their
own backs (far from impossible) as they were only going to grant relaxed
licensing for those patents essential to the implementation, so, in general,
they aren't granting any special rights.

> source tool, that implements accessibility features and is one of the leaders
> in implementation of the entire specification - Batik.

I think I've heard of Batik, but it is not very high profile and for what
ever reason, the time I wanted to fetch one of the betas, it didn't look
to be as complete/usable as the Adobe one.  Adobe gave the impression of
being the prime mover on the mailing list.

> Currently SVG has beena  recommendation for weeks, and the developers are
> racing to make the two leading implementations (Adobe and Batik, although

Various discussions on the list suggested to me that Adobe were
preferentially implementing the features that were saleable/matched
their skill set, although maybe they are filling in now that the standard
has stabilised.

A point that I didn't mention is the virtual silence of Microsoft.
I strongly got the impression (but possibly only from the silence)
that they were waiting to see if authors adopted the standard before
implementing it in their browsers.  Given their antipathy to Acrobat
(which I consider to be much more the immediate ancestor than HTML),
I'm not sure that they want to encourage an Adobe led initiative.

Either IE6 does implement it but Microsoft have not promoted the fact, or
IE6 doesn't implement it.  In the latter case, very wide support will have
to wait for IE7, or at least IE6 SP1.  Significant support amongst power
users will require that Windows Update add the support - I note that 
there is no Windows Update support for Acrobat, but there is for Flash.
I don't see any great swing to Mozilla/NS6 yet.  (I haven't checked the
SVG implementation status pages since the release, but previously 
Microsoft were not represented.)

In the end though, I think, if it does take off, SVG will be used in
non-accessible ways as Flash replacements or for paste up designs with
no sensible linearised order.

In fact, it is probably weaker than Acrobat 5, in that it requires that
the linearised reading order and the rendering order be the samei++, whereas
Acrobat allows one to impose a semantic order that is different from the
rendering order (earlier versions allowed "threads" that allowed reading
order to be linearised when articles were interleaved).

++ Sophisticated users could use server side scripting to generate the
SVG from a linearised form, but scripting has its own problems and many
designers will not be bothered with this level of sophistication.

## I'm not sure if this still applies if it turns out that those with
unconditional royalties don't have relevant patents.
Received on Saturday, 27 October 2001 05:37:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:15 UTC