[OT] dynamic resolution web sites

[Luke-Jr]

On Tuesday 08 November 2005 02:19, Jason Dewayne Clinton wrote:
> 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.
>
> 12/72 * 98 = 14.97 pixels

Myth? You just proved it as true...

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

A buggy OS does not make the format flawed in any way. It would affect SVGs 
just as well, note.

> Gnome stupidly has the same behavior.

Yet another reason Gnome sucks...

> So in both Windows and Gnome the number of pixels used to render this font
> at 12 points is: 
> 12/72 * 96 = 16 pixels 

So both Windows and Gnome are broken. Fix them before you mess with a 
perfectly good standard format.

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

Sure it does. Properly working browser/UI combinations will use the correct 
20.33 pixels in this case.

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

Which is exactly why people advocating using "px" are stupid. Real world units 
are always best when possible (anything except images thus far).

> Wouldn't it be nice if it didn't matter? That's what SVG can contribute.

SVG can't fix a broken OS/UI.

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

All standards-compliant browser/UI combinations will appear the same. Broken 
browser/UI combinations should be ignored.
> > > 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.

Most browsers have a zoom feature.

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

Not really. The printing stuff here all seems to size up images fairly well.

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

Web pages should only use image formats (PNG, SVG, etc) for images. All text 
should be inline and placed with CSS.

> > 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 have 3.5 Subversion kdebase ("base KDE distribution"), kdenetwork, kdepim, 
and kdegames installed. I suspect KSVG (along with KPDF, etc) are part of 
kdegraphics. All KDE's default icon themes are prerendered PNGs and while 
(IIRC) there is a small SVG engine in kdelibs, it is nowhere near complete 
enough to handle regular SVG images.
-- 
I digitally sign my emails.  If you see an attachment with .asc, then that 
means your email client doesn't support PGP digital signatures.
http://www.gnupg.org/documentation/faqs.html#q1.1
-------------- 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/20051108/8a7d80f9/attachment.pgp