W3C home > Mailing lists > Public > www-style@w3.org > March 1998

Re: browser, rez, OS issues

From: George Olsen <golsen@2lm.com>
Date: Wed, 18 Mar 1998 18:50:22 -0800
Message-Id: <v03110700b13620457a13@[207.155.82.161]>
To: www-style@w3.org

>Almost. CSS1 defines a "reference pixel" as a degree of visual angle
>equivalent to 1/90" at arm's length,

My mistake. Thought that was part of CSS2....

>" Consequently, when 30-pixel high type is printed out on a 600 dpi printer,
>" it's a faction of a point high.
>
>This was a bug affecting IE3 only.

Good to hear it got fixed. Got burned once, neglected to re-examine the issue.

>What does monitor size have to do with window size?

People with 640x480 monitors can't resize their monitor to handle a larger
window and by the phrasing of Victoria's question I assume she wanted to
design for something larger than 640x480. Personally I'd rather design a
page that is cohesive and works well even if it doesn't scale up to fill
the screen of somebody's 1920x1080 monitor.

Clive Bruton wrote:

>If you specify type in pixels you take a guess at what dpi someone's
>screen *might* be running at, this is a bad move.

Agreed. However, I was trying to answer the question as asked.

>So, measure your type in pt and you get the same notional real world size
>on Mac and Win, with the Win at a higher ppem value. Measure your type in
>px and the Mac type looks bigger by about a third in a real world
>application, though the ppem values are identical.

Don't know about the notional world, but on the Mac and PC in front of me
when I specify sizes in pt or em, Windows makes things about a third larger
using default resolutions (Mac at 72 ppi and Windows at 96 ppi).
Incidently, this also also true of HTML sizes using <FONT SIZE> in the
browser. In non-browser apps, such as MS Word, Quark and PageMaker,
specifying in type in point sizes also results in it being a third larger
on Windows.

When I specify type in px it displays equivalent in size between Mac and
Windows. In my test file it's easy to confirm that things are the same size
because the line breaks change. I've confirmed this by taking screen shots
and measuring the size of the type rendered on screen, as well as by
holding a plastic em-scale to the screen (on-screen em-scales won't work
because they're resized by the monitor's ppi).

Certainly there's some variation in displayed size (for example, I can set
my Mac to 800x600 rather than 832x624, which affects ppi resolution), but
I'm looking for cross-platform consistency rather than exact reproduction
of a particular point size. Slight size variations aren't a big deal to me,
especially as all elements on screen are affected equally by these
variations. OTOH, if I choose to overdrive my 17-inch monitor at 1024x768,
the type could get hard to read. However, *everything* on my monitor will
look tiny in this situation, so I figure my Web page will be no worse than
what the user is used to seeing. Now there is a problem if 300 ppi displays
come out, but I'll deal with that issue when it appears.

If the browser knew the ppem of the device its being displayed on, then yes
em spacing would be a better choice. However, as Todd pointed out, I'm
unaware of any way to do this reliably at the moment (if there is, I'd be
interesting in hearing about it.) Assuming this works though, we're still
faced with the issue of resolving type size to image size. That's to say,
assume you have a bit of type sized at 12 ppem and a 100x100 pixel image.
While the type will remain the same size, but the image will be a third
larger on Windows due to the differents in assumptions about the size of
pixels between Mac/Windows. Granted we could spec the image in ppems as
well but then we're back to the problem of image scaling.


George Olsen
Design Director/Web Architect                          mailto:golsen@2lm.com
2-Lane Media                                              http://www.2lm.com
vox 310/473-3706 x2225                                      fax 310/473-6736
Received on Wednesday, 18 March 1998 21:48:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:54 GMT