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.