On Jan 22, 2010, at 12:26 AM, Linda A. Walsh wrote:
Jon Cruz wrote:
On Jan 21, 2010, at 11:29 PM, Linda A. Walsh wrote:
An errata was posted in 2001. http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html
Section 4.3.2 Lengths [2001-08-28] The suggested reference pixel is based on a 96 dpi device, not 90 dpi. The visual angle is thus about 0.0213 degrees instead of 0.0227, and a pixel at arm's length is about 0.26 mm instead of 0.28
ahh... that might be interesting, although the proper fix is to get Inkscape properly dynamic about DPI and remove all hardcodings.
You could, but then you'd be violating the new HTML5/CSS3 spec, which defines pixels as having a device independent value of 96 dpi in order to get around the the severe trauma pixel-addressing addicts have been inflicting upon hires screen users.
But that would only be CSS3 which in turn is not yet involved in SVG. Even SVG 1.2 Tiny still references CSS2.
To go along with that we would need to get CSS media selectors and many other fun things we *really* want to have. However, we could not call that SVG 1.x
Additionally, SVG allows for the user agent (that's us) to decide on what DPI to use. Specify an inch and you might get 72 dots or you might get 96, but you as a designer should not care.
Additionally, what is legible text to one person is often *not* legible to another, even when the monitor DPI remains the same.
Get a 144dpi display and watch large portions of the web be suddenly be 2/3rd's their intended size and much more difficult to read.
Well... that depends. If one defines a font in point sizes, then as the density of the display increased the number of pixels used in letters would correspondingly increase.
And, yes, I have used 144dpi systems and have done many tests, especially with Inkscape and SVG in mind.
Thus was born the idea of redefining pixels to have a fixed, device independent size so users wouldn't have their interfaces mucked up by web designers who couldn't use points, millimeters, centimeters, or inches. That's where the number 96 comes from -- it's not that it was a best guess, it's a redefinition of 'pixel' in CSS (and HTML5) to fix the size problem when moving to different devices. Content writers shouldn't be concerning themselves with the hardware addressing resolution of the output device. They should be disassociated, and people can then tell the unit's display manager to 'scale' the output (usually larger, but I don't see why smaller shouldn't be legal -- maybe it isn't -- MS doesn't support DPI's under 96 in Win7 (my Viewsonic is 94DPI) so I now suffer horribly on a display where everything is about 2-3% larger than it should be! The horror of it! (I did have my XP value set to 94DPI)). So I don't know if smaller values are legal or not just supported by MS, but if you really want things to be larger, you'll be able to do it with a device independant scaling factor. pixels will become a 'defined' value in CSS/HTML. So inkscape might want to spare themselves the work of trying to detect a hardware value that won't be supported.
? Is that good news or just freaky? :-)
Freaky. However, until SVG 2.0 we might be a bit stuck on things.
But... remember that we are dealing with the SVG world here, and not the HTML world. The pragmatic solution is to involve view boxes and such to pin things down to specific user needs. HTML is not often sent out to a laser cutter for creating home furniture, but SVG is :-)