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.
>> 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
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