- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Sat, 27 Oct 2001 10:30:46 +0100 (BST)
- 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 implementation. 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