[thelist] A pixel is not a pixel

Arlen.P.Walker at jci.com Arlen.P.Walker at jci.com
Thu Jun 14 14:16:03 CDT 2001


>>Opera 5 for the Mac, which in fact renders pixel text on a Mac
>>considerably smaller than pixel text on a Windows machine.
>
>In my opinion this is still a bug, regardless of the newest pixel theory.

You're not alone in that view, but "newest pixel theory" has to be a
relative term. This comes from Tod Fahrner back in 1998:

"If your pixels are too small, so is your image. And if your "points"
rasterize into a fixed number of pixels, then so is your text. So The Right
Thing To Do is to scale, which is in fact what happens when you print.

<digression into printing elided>

"I take it as given that within 10 years, interactive displays will have
physical resolutions at least equal to low-end print. I don't want the Web
to shrink or distort down that hole.

"So the key is to know the appropriate scaling factor when your pixels are
unsuitably small for 1:1 display of raster data (such as GIFs, JPEGs,
PNGs). The reference pixel provides the basis for such scaling, correlating
literal raster data pixels with useful values in absolute or user-space
(inches or degrees of visual angle).

"Pixel scaling from a common reference or "virtual" pixel is essential for
achieving predictable rendering results across media and devices,
especially over time."

I think it's been one of those parts of the standard that wasn't looked at
very closely until Opera implemented it, and now we see it we're a little
unnerved by it.

>I look at it from the opposite point of view: all browsers show the same
text
>size except for Op5Mac, ergo: Op5Mac does not conform to the de-facto
>standard.

That dog won't hunt. No standards-compliant browser conforms to the de
facto standard. Therefore no company should produce a standards-compliant
browser? *Somebody* has to be the first to implement; if no one is to be
the first, then no progress can be made. We can debate whether the CSS
standard is fuggheaded on this point, but to say "no one else does it that
way, therefore they're wrong" is to assert that CSS should never have been
implemented by any browser in the first place.

>>Opera doesn't appear to consider this a bug, and in
>>reading the CSS spec, they appear to be justified in that assertion, as
the
>>CSS spec asserts that the user agent (AKA browser) should in fact *not*
>>consider a pixel as a screen pixel, but rather as a hypothetical unit
>>approximately equal to 1/90th of an inch.
>
>Then text should be exactly the same in Opera 5 on Win and Mac if both
>computers use the same Sony Triniton 19'' screen with 1152x870 resolution
>(which is my current setup). They're not the same, so one of them is
wrong.
>Since Op5Mac is the one differing from all other browsers, it is most
likely
>to be wrong.

Almost right, but not quite. Take out that "if clause" in the first
sentence to get it completely right. Type specified at 10px, according to
the CSS standard, should render at the exact same visible height,
regardless of the size and resolution of the monitor. 10px type should
render at about .11 inches high on *all* monitors, even your Sony when set
at 640x480 resolution. The missing piece of information is that the browser
currently is blissfully unaware of the ppi resolution setting of the
monitor, because the OS isn''t telling it anything reliable.

>>Which means that if the user agent is not given the video density of the
>>monitor attached, it will assume the platform standard (72 pixels per
inch
>>for MacOS) and resize the value accordingly.
>
>If a pixel is defined as 1/90th of an inch and an inch contains either 72
or
>96 pixels (depending on the OS), somewhere something must be terribly
wrong.
>These two definitions simply don't go together, only one of them can be
>true.

Yes they can both be true, and yes, there *is* something wrong here. The
standard reference pixel is a hypothetical creation, defined to be 1/90th
of an inch. Windows reports its monitors to be 96ppi and MacOS reports its
monitors to be 72ppi, if the browser asks. The actual monitor attached to
the system will have real, not hypothetical pixels, with a density of still
another ppi, almost guaranteed *not* to be either 96ppi or 72ppi (though in
a happy accident for Windows users, they are usually closer to 96ppi than
72ppi; IIRC the current range goes something like 80-130ppi).

The CSS spec currently requires the browser to scale pixel measurements
according to the pixel density of the monitor. Opera chose to write their
browser to implement the CSS spec, and *all* the OS's are lying to it,
rather than relaying accurate information, hence the size discrepancy. One
way for browser developers to get past this is to ask the user, via a
preference setting, what the ppi of the monitor is. IE5/Mac does something
like this already, allowing fonts to be rendered either via the
MacOS-standard of 72dpi or the Windows standard of 96dpi. But unless that
preference setting is made known to the page via javascript, for example,
you're not going to know which preference has been selected, and in any
case you won't know its relationship to reality.

What I'm trying to get clear here is that 1 CSS pixel is *not* 1 monitor
pixel. Yes, in theory a pixel will resolve to the same size on all screens
in all OS's. But so should a point. The size of a pixel, just like the size
of a point, is dependent upon the browser implementation. The fact that
pixels have been thought of as more reliable than points is simply an
accident of history that may now be coming to an end. IBM right now is
shipping special-application (AKA expensive) LCD's that approach 300ppi.
Imagine your 14px typeface on *that* without scaling it somehow. Ever tried
reading 3pt type from an old laser printer?

Monitors are not paper. We should stop trying to treat them like they are.
We're painting our creations on canvas borrowed from our audience. We're
taking pot luck, not dictating terms.

Hey, if it was easy, anyone could do it, right?

Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 224

Arlen.P.Walker at JCI.Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.





More information about the thelist mailing list