First Working Draft of SVG 1.2

Hello.

Are there any proposals to sort out the problems using absolute units in
SVG?
The new draft of the SVG 1.1 spec still recommends only using pixels to
avoid "inconsistent visual results", and doesn't appear to address the
problem with absolute units not being permitted in paths or transforms.

This could easily be fixed by adding either one of the following
properties -
1) A default unit property
If a unit is not (or cannot be) specified on an element or property where a
length or coordinate could realistically be expected, then it will be
assumed to be in the unit specified in the default_unit property. This
property could then be inherited down through groups should some data be
more easily specified in points (e.g. around large blocks of text data) or
mm (e.g. path data)

For example:
<svg width="10cm" height="10cm" xmlns="http://www.w3.org/2000/svg"
version="1.1">
  <path default_unit="cm" d="..."/>
  <g default_unit="pt">
    <text x="5" y="5" font-size="12pt">Some text</text>
    <text x="5" y="17" font-size="12pt">Some more text</text>
  </g>
</svg>

2) A resolution property on the svg element
Instead of allowing the user agent to arbitrarily pick the resolution, this
property will define what resolution to use. This effectively defines the
conversion between pixels and real units so that if the SVG does contain a
mix of units everything is guaranteed to be rendered at a consistent size
regardless of what program is used to view / process the SVG.

Either of these properties are simple changes that remove a problem that the
spec itself acknowledges exists, yet increase the usability of SVG. A
practical example of why this would be a necessity is for publishing
software. Users of this type of software usually have a specific sized area
on a page for a diagram, so need to be able to design the graphics for the
diagram at this size, and be sure that everything will stay at the same
relative size. Such a user needs to work in absolute units as a printed page
and barely has any concept of a pixel as it is without then having to
explain that this pixel can be as big as you feel like.

Personally, I'm surprised this hasn't been sorted earlier especially with
people like Adobe and Corel on the list of authors. One of the core features
of both Adobe Illustrator and Corel Draw is to be able to draw vector
graphics at an absolute size so that a user can draw an object at for
example 5cm by 5cm, when they print it or import it into a publishing
package (e.g. Adobe PageMaker) it will stay at 5cm by 5cm and not get
imported at 7cm by 7cm. Presently the spec allows this to happen because
Illustrator on a clients machine is free to chose the resolution to be
72dpi, yet PageMaker on a different machine might decide the resolution to
be 90dpi. I'm assuming that this is only avoided because Adobe have decided
on a set resolution for all their products. But there is no guarantee that
the same would be true between Adobe products and Corel products, or between
Corel and Jasc, etc.
The way things are at present, users are limited to saving their graphics in
the proprietary format of their vector graphics package because they can't
rely on SVG to render the graphic correctly everytime.

The SVG Requirements document, http://www.w3.org/TR/SVG2Reqs/ (22 April
2002), lists the following requirement:
  1.. SVG 1.1/1.2/2.0 should be targeted as a standard feature on desktops
(web browsers, graphical applications, authoring tools, file interchange),
mobile and small devices (browsers, user interfaces, automotive systems),
printers and industrial applications.
At present by still allowing this inconsistency, the SVG spec falls short
particularly with regards to graphical applications, printers and industrial
applications.

Section 4.2.12 in the requirements document, which says the following:
  1.. Units
    1.. SVG may allow CSS units in the polylines, polygons, paths and
transforms. However, the CSS unit facility may be deprecated in favour of an
alternative approach using constraints. [SVG 2.0]
suggests that this was going to be at least addressed in SVG v2.0, yet from
the working draft recently issued, it looks like it is going to be ignored
again. I'd obviously suggest NOT deprecating CSS units as I believe them to
be essential if you intend to meet the first requirement of SVG, above.

I believe this is a simple problem to solve, and should definitely be fixed
for SVG 2.0, maybe even SVG 1.1 if it is not too late in the process.

Richard


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Received on Monday, 18 November 2002 09:10:47 UTC