Re: transform as a presentation attribute

Paul LeBeau:
> > Presumably SVG 2 will adopt this from CSS 2.1, this will apply as well.
>
> Has there been any discussion on adding an ability to alter the default
> DPI?
>
> For instance, a new attribute/property "unit-dpi" which has a lacuna value
> of "96 96",  Perhaps also with a special value "auto" in which the renderer
> chooses a device DPI based on values obtained from the OS.

If you change the ratio of width and height of the root svg element to
width and height of its viewBox, effectively you do something like this.

But obviously the applicable resolution is chosen by the user or 
given by the screen, depending on the type of screen, projector or printer.

In theory with media queries an author can provide other styling depending 
on the resolution in CSS (maybe applicable for SVG 2 as well?)
I think the change in CSS 2.1 had the origin in the problem, that microsoft
operating systems did not read out this information from the screen and
viewers relied on arbitrary information from the microsoft operating system
or from someone else (for example the old Adobe SVG plugin assumes 92px, 
not 96px per inch).
Other operating systems (for example Unix/Linux) provide resolution 
information properly and a few viewers, for example Gecko had a proper
presentation of units like centimeter or millimeter before the change in CSS 
2.1.
If we assume, that it still might be difficult for viewers either to get 
reliable information about the resolution from specific operating systems
or screens, how could this media query work?
And if it works: of course, this means a lot of files, authors have to write, 
if they need to provide another stylesheet for every resolution, to work 
around the fixed relation of 96 pixels per inch.


Tab Atkins Jr.:
 >Olaf's statement is unfortunately slightly
>incorrect, in a rather common way.  What CSS did was fix the ratio
>between the px unit and the other absolute units, effectively
>transforming px into an absolute unit just like pt is.  However, it
>*also* explicitly allows user agents to vary their definition of
>absolute units in order to make the px unit fit a more convenient
>size.

Well, I think, my statement is correct, the most friendly interpretation
of the sections in CSS 2.1 is, that 1px is defined to be 1/96 inch,
but CSS leaves it to the viewer, how to present absolute units like
inch or centimeter on a pixel based device 
(including some suggestions resulting typically in something different 
from the real size of the used absolute unit). 
This results in a situation, where the visual effect of absolute units 
become arbitrary and therefore in practice useless,
CSS (and presumably SVG, that has much more use cases for graphics 
in absolute units)  lost a meaningful feature due to this.
The naming of the absolute units in CSS is typically misleading now,
altogether nothing that looks like a meaningful 'recommendation',
more a summary of viewer behaviour (bug reports).

I have already seen, that viewers transfer this arbitrary behaviour to
printers, therefore it is not predictable, what is the scale for the graphics,
if a user decides to print an SVG document - effectively this means, 
authors cannot assume that technical drawings, maps etc appear in 
correct size for the viewer - better not to use a CSS related format for
tasks, where size matters :-(



Juergen Roethig:
>Hello world,
>
>Am 24.06.2014 23:44, schrieb Tab Atkins Jr.:
>> [...]
>>
>> <!DOCTYPE html>
>> <svg viewBox="0 0 10 10" width=100 height=100 style="border: thin solid;">
>>   <rect x=1 y=1 width=2   height=2   fill=blue ></rect>
>>   <rect x=1 y=5 width=2px height=2px fill=green></rect>
>> </svg>
>>
>> [...]
>
>Just a question: Is this really the way we should code SVG in the 
>future, or even in the present? As in the past, it looked somewhat 
>different (DOCTYPE, attributes, ...) ... especially the <!DOCTYPE html> 
>concernes me somehow.

The code above is obviously no SVG, it is some arbitrary tag soup ;o)
Of course, there is no problem to note this in a text file, but there is no
defined interpretation or no indication for a defined interpretation.
The 'DOCTYPE' indicates, that there should be a root element 'html',
but there is no. There is an element 'svg', but there is no namespace
indication, that this is somehow related to SVG, could be related to
some german 'Straßenverkehrsgesellschaft' as well ;o)
For SVG 1.x something like style="border: thin solid;" is not applicable.
Some structures look like attributes, but the part after the '=' for the value
would be wrong - therefore something arbitrary, that does not indicate,
what it is or how to interpret it.


Olaf

Received on Thursday, 26 June 2014 09:11:26 UTC