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.