[OT] dynamic resolution web sites

[Jason Dewayne Clinton]

On Sunday 06 November 2005 09:52 pm, Luke-Jr wrote:
> The 'pt' unit is a real-world size. If it appears different based on
> your DPI or resolution, then that is a bug in your OS/browser.

If only it were that simple. Allow me to thoroughly debunk this myth:

A 'pt' is 1/72 of an inch. If your OS is aware of the width of the 
monitor (such is the case with Mac OSX and X11), then it must take this 
in to account when deciding how many pixels to use when rendering an 
11pt font. It is this process that maps the ratio of pixels to points.

For example, lets say that I am wanting to render a 12 point font to my 
screen and printer. My screen is a 20" 1600x1200 screen. The exact 
measurements probed by X11 are show in the output of 'xdpyinfo' in a 
terminal:

screen #0:
  print screen:    no
  dimensions:    1600x1200 pixels (411x311 millimeters)
  resolution:    99x98 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32

So, the next step of the font engine is to look at that and calculate 
the number of pixels required using a simple ratio:

12/72 * 98 = 14.97 pixels

Now, before I move on to how the printer works with this, let me make an 
important point: Windows COMPLETELY ignores the size of the monitor and 
ALWAYS assumes that the DPI of the monitor is 96 DPI. Gnome stupidly 
has the same behavior. So in both Windows and Gnome the number of 
pixels used to render this font at 12 points is:

12/72 * 96 = 16 pixels

These are pretty close but slightly different (enough to cause trouble).  
Let me show you where things really start to break down -- when you're 
dealing with a laptop with 1400x1050 on a 15" screen:

screen #0:
  print screen:    no
  dimensions:    1400x1050 pixels (289x219 millimeters)
  resolution:    123x122 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32

So a 12 point font is now:

12/72 * 122 = 20.33 pixels

That makes it much easier to read on this tiny screen but doesn't bode 
well for rendering web pages which use points as their font size 
indicator. In order to address these complications, web designers have 
been advocating using CSS styles and the "px" unit instead of the 
relative "pt" unit. This means the web page will display mostly the 
same on all platforms. But the problem here is that 15px is tiny on a 
1600x1200 15" laptop screen and huge on a 17" CRT monitor running at 
800x600. Wouldn't it be nice if it didn't matter? That's what SVG can 
contribute.

The printer works using the same principle except that it uses dots 
instead of pixels. So on my trusty, old 600 DPI laser printer, the 
number of dots required to render a 12 point font is:

12/72 * 600 = 100 dots

So that's how we end up with such different web page renderings across 
different platforms and different environments.

> > That means that lines are REALLY long and it becomes hard to follow
> > line-by-line.
>
> Only if your browser is sized bigger than your preference for reading
> a webpage...

See above. And why shouldn't a user specify that they would like to use 
larger fonts without breaking the layout? That's what I would like to 
enable.

> Last I checked, DPI was separate from resolution.

That statement couldn't be more wrong. See above.

> Maps have always printed fine for me...

I can't read the names of streets very well on a 600 DPI B&W laser 
printer. Even if I grant that you can read them well, you have to agree 
that there's lots of room for improvement...

> > What /should/ happen is that web pages should become /sharper/
> > and /easier to read/ when more pixels are available; not smaller
> > and harder to read.
>
> Only if designed properly and the client is properly configured, in
> which case they do.

I don't know of any web standard besides SVG which makes this possible. 
Bitmaps are bitmaps. They don't scale without degradation.

> SVG is purely useful as an image format. They belong within IMG HTML
> tags, not as a replacement to the HTML itself.

I guess you didn't look at my example ... it's an HTML page with SVG 
embedded using an <object> tag ... the HTML text and the SVG picture 
are completely separated.

> Or maybe I don't have KSVG installed? I think older FireFox can
> handle SVG with plugins, too-- so if we're basing this off defaults,
> Konqueror doesn't support it.

KSVG is part of the base KDE distribution. It's required to render the 
default icon theme in KDE. It can be excluded by some functionality is 
lost. Perhaps you didn't pass the correct ./configure parameter.

-- 
I use digital signatures and encryption. My key is stored at pgp.mit.edu
0x8DB3BF09 FP: F628 D9D3 E57A C281 5EFE - 7DF7 B52A A393 8DB3 BF09
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kclug.org/pipermail/kclug/attachments/20051107/ae2da171/attachment.pgp