Some of you may remember that some time ago we discussed making websites in Flash. At the time I strongly objected and suggested that some day SVG would be able to handle the resolution independent rendering which Flash offers without all the accessibility problems. Well I'm very excited to share that I think that day has finally arrived (or almost has).
Firefox 1.5 RC1 was released today and with it comes support for SVG. This adds to the list of browsers supporting SVG: Opera and Konqueror which is a total of roughly 13% of the browser market. Add to that the IE Adobe SVG Plugin for IE6 (85%) and the picture starts to look pretty rosy.
I have put up a proof of concept at [1]. Please give it a good work-out. It will not work in Konqueror <3.4, Opera <8 or Firefox <1.5. IE 6 doesn't allow rescaling fonts but it does display the content correctly.
[1] http://jasonclinton.com/calig_test.html
I strongly feel that this is the future of the web and I'm looking forward to playing around with HTML+SVG. Let me know your thoughts!
On 11/4/05, Jason Dewayne Clinton me@jasonclinton.com wrote:
Some of you may remember that some time ago we discussed making websites in Flash. At the time I strongly objected and suggested that some day SVG would be able to handle the resolution independent rendering which Flash offers without all the accessibility problems. Well I'm very excited to share that I think that day has finally arrived (or almost has).
Firefox 1.5 RC1 was released today and with it comes support for SVG. This adds to the list of browsers supporting SVG: Opera and Konqueror which is a total of roughly 13% of the browser market. Add to that the IE Adobe SVG Plugin for IE6 (85%) and the picture starts to look pretty rosy.
The example looks really great. I was pleased to here that Mozilla / Firefox can support SVG now, and since I've been working with XForms, I can see the potential the two together have. I found the following article that some of you might be interesting.
http://www.xml.com/pub/a/2002/05/22/svg.html
Jason, what did you use to build the svg file you used in the example?
Josh
On Friday 04 November 2005 10:22 am, Josh Charles wrote:
Interesting.
Jason, what did you use to build the svg file you used in the example?
Inkscape. I had to make two modifications to the file to get it to scale. I had to change the width and heigh to PX values and then add a "viewBox" property. I also added a white background (<rect>) since KSVG doesn't paint a white background by default.
On Fri, 4 Nov 2005, Jason Dewayne Clinton wrote:
Jason, what did you use to build the svg file you used in the example?
Inkscape. I had to make two modifications to the file to get it to scale. I had to change the width and heigh to PX values and then add a "viewBox" property. I also added a white background (<rect>) since KSVG doesn't paint a white background by default.
This is very interesting. However, playing devil's advocate, I see two serious problems with svg for web pages.
1. Complex SVG files are huge. Those node and fill definitions get massive in a hurry.
2. Complex SVG files are mega-cpu intensive. Everytime you try to scroll the page, it shuts down your computer for x seconds to redraw.
But, I definitely do like the concept. I've talked about this before, but try http://www.zeni.net/trf/mgspec/157.php for scaleable graphics. I generate a libraray of jpgs with different scaling for the most common screen resolutions, although the user can plug any "zoom" value that he wishes into the location bar and the server will choose the closest sized image and scale it for you on the fly. Php is your friend.
Yes, these catalog page background images start out as vector but they are mega smaller when scaled and converted to jpg raster.
On the other hand, experts have been telling me for years that the whole world will be using broadband by Tuesday.
Regards,
-Don
On Saturday 05 November 2005 09:57 am, you wrote:
This is very interesting. However, playing devil's advocate, I see two serious problems with svg for web pages.
- Complex SVG files are huge. Those node and fill definitions get
massive in a hurry.
This is true. However, because the information is text, it is highly compressible (compression ratios of around 0.2). And that's why svgz is part of the standard. And of course, no one is advocating using SVG all the time; just when it's appropriate (user interfaces, text and clipart).
- Complex SVG files are mega-cpu intensive. Everytime you try to
scroll the page, it shuts down your computer for x seconds to redraw.
This is true inside of an SVG editor and perhaps also in SVG animations. However, on static SVG images in web pages, the SVG is rasterized and then blitted to the scroll buffer for hardware accelerated scrolling (this is true for Firefox, Konqueror and Opera). So there should be no difference once the picture has been rasterized. There might be a problem on really low video memory systems, though. (Like less than 8MB of VRAM.)
But, I definitely do like the concept. I've talked about this before, but try http://www.zeni.net/trf/mgspec/157.php for scaleable graphics. I generate a libraray of jpgs with different scaling for the most common screen resolutions, although the user can plug any "zoom" value that he wishes into the location bar and the server will choose the closest sized image and scale it for you on the fly. Php is your friend.
Yes I think this is very interesting approach. I considered doing it using the Batik [1] server-size SVG rasterizer which can do almost exactly what you suggest but in the end the unresolved printing issue turned me off. But I still think there's some very useful applications for this approach.
[1] http://xml.apache.org/batik/
Yes, these catalog page background images start out as vector but they are mega smaller when scaled and converted to jpg raster.
Yes that's a huge improvement. It would print poorly but its ideal for screen display. This is also how the DejaVu file format works. It obtains huge compression ratios versus PDF but it isn't well suited for printing.
On the other hand, experts have been telling me for years that the whole world will be using broadband by Tuesday.
We're at about 40-50% market saturation in the US aren't we? Maybe not...
On Sat, 5 Nov 2005, Jason Dewayne Clinton wrote:
This is true inside of an SVG editor and perhaps also in SVG animations. However, on static SVG images in web pages, the SVG is rasterized and then blitted to the scroll buffer for hardware accelerated scrolling (this is true for Firefox, Konqueror and Opera). So there should be no difference once the picture has been rasterized.
I see. I tried plugging a different SVG into your test page, but it didn't size. I haven't really played too much with inkscape, maybe I didn't set the "viewbox" property? Where the heck is that, anyway?
Yes I think this is very interesting approach. I considered doing it using the Batik [1] server-size SVG rasterizer which can do almost exactly what you suggest but in the end the unresolved printing issue turned me off.
Yeah, I'm not much of a printer. My ink is usually dried up, adn my wife won't let me use the lazer printer.
Yes that's a huge improvement. It would print poorly but its ideal for screen display. This is also how the DejaVu file format works. It obtains huge compression ratios versus PDF but it isn't well suited for printing.
Well, if you get bored here's a script that can be easily edited to create a whole rash of .jpg libraries at any resolutions that you choose. It's currently set to start with a directory full of .pngs and create 3 libraries, but add enough array elements and you could fill a hard drive.
------------------------------------>8------------------------
#! /usr/bin/perl -w ##Don Erickson 2005 ##convert8.5x11images.pl ##this script will create libraries of scaled images. It is set for a ##high-resolution 8.5x11 inch source file size using imagemagick. ##edit pix* arrays to define desired width and height ratios.
(@images)=qx (ls *.png); print "@images\n"; $i=0; @pixwidth = ("691","864","1037"); @pixheight = ("823","1029","1235"); @zoom = ("80","100","120");
foreach(@pixwidth) { print "creating image bank $pixwidth[$i] x $pixheight[$i]\n"; # create the proper directory system(mkdir $zoom[$i])==0;
foreach $_ (@images) { chomp ($change =($_)); if ($change) { $outchange = "$zoom[$i]/$change"; $command = "convert -resize '$pixwidth[$i]x$pixheight[$i]' '$change' '$outchange'"; system("$command"); print "$command\n"; $change =~ s/.png//; $change = "$zoom[$i]/$change"; $outchange = "$change.jpg"; system ("convert -depth 8 '$change.png' '$outchange'")==0; } } $i++; }
print "\n\nFini\n";
------------------------------------------8<--------------------
On the other hand, experts have been telling me for years that the whole world will be using broadband by Tuesday.
We're at about 40-50% market saturation in the US aren't we? Maybe not...
I think that you have to count work and home environments to get up that high. The number is certainly climbing though, no doubt about that.
Unless you consider the growing number of companies that firewall the internet from their employees...
Regards,
-Don
On Friday 04 November 2005 08:09, Jason Dewayne Clinton wrote:
Some of you may remember that some time ago we discussed making websites in Flash. At the time I strongly objected and suggested that some day SVG would be able to handle the resolution independent rendering which Flash offers without all the accessibility problems. Well I'm very excited to share that I think that day has finally arrived (or almost has).
Last I checked, XHTML/CSS handle dynamic resolutions just fine...
Firefox 1.5 RC1 was released today and with it comes support for SVG. This adds to the list of browsers supporting SVG: Opera and Konqueror which is a total of roughly 13% of the browser market. Add to that the IE Adobe SVG Plugin for IE6 (85%) and the picture starts to look pretty rosy.
Using Konqueror 3.5-subversion here and all I see is text...
On Friday 04 November 2005 11:53 am, Luke-Jr wrote:
Last I checked, XHTML/CSS handle dynamic resolutions just fine...
Bahumbug. You need to check again. I run at 1600x1200 at 98 DPI and I can say with certainty that pages that are designed to fill the entire width of the page start to become unreadable when the font is 11pt. That means that lines are REALLY long and it becomes hard to follow line-by-line. Resolution isn't just width and height. On a good platform (X11 and Mac OSX) it also means the DPI of the monitor. And that's to say nothing of the printing issues that are created by virtue of printing being done at 600 DPI or more while screens are in the lowly range of 75 - 110 DPI. The nasty differences are apparent when you try to print off a map from a web page and it becomes less readable.
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.
Why did you even reply to this message? Are you going to make the claim that SVG has nothing to offer? Just trying to pick a fight for no good reason?
Using Konqueror 3.5-subversion here and all I see is text...
So you didn't even try it? Check your KSVG plugin by trying to click on an SVG file in your local file system from Konqueror; it should open up in Konqueror. Otherwise file a bug against 3.5 RC1.
--- Jason Dewayne Clinton me@jasonclinton.com wrote:
On Friday 04 November 2005 11:53 am, Luke-Jr wrote:
Last I checked, XHTML/CSS handle dynamic
resolutions just fine...
Bahumbug. You need to check again. I run at 1600x1200 at 98 DPI and I can say with certainty that pages that are designed to fill the entire width of the page start to become unreadable when the font is 11pt.
Well there are configuration issues, web design issues and graphics issues all at play in this. Not to mention individual browser interpretation issues. First off if you configure your browser in a certain way you will override the browser's ability to render the web page to the best resoultion. Secondly, if the coder who wrote the web page did a poor job then the page may also display at a constant size which may not be readable on some displays. Thirdly, SVG wont help render fonts any better, unless you have some very strange installed fonts.
That means that lines are REALLY long and it becomes hard to follow line-by-line. Resolution isn't just width and height. On a good platform (X11 and Mac OSX) it also means the DPI of the monitor. And
DPI of the monitor? Please share with us whatever you're smoking. ;') Seriously though, I understand what you're trying to say here, but most websites are designed for 800x600 or 1024x768 *total* pixels. The DPI is really irrelevant when speaking of monitors. The bigger the monitor, the more total pixels and hence the lower the DPI of a webpage will be if stretched to higher than designed resolution. True, SVG might make this irrelevant ... someday.
that's to say nothing of the printing issues that are created by virtue of printing being done at 600 DPI or more while screens are in the lowly range of 75 - 110 DPI. The nasty differences are apparent when you try to print off a map from a web page and it becomes less readable.
And for what reason would you try to print at 600 dpi something that only has maybe 150 dpi, unless of course you are shrinking the output. This is like scanning in a 35mm negative at 600 dpi and trying to print an 8x10 picture from it and expect photo quality results. It is possible to scan in a 4x6 print at 600 dpi and print out a 6x8 print at photo quality. Most prints have 300 dpi, while most negatives have 3000-5000 dpi.
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.
Well, considering web pages weren't designed to do this, I have to disagree that they /should/. While at the same time I'll say it would be /nice/ if they did. However there are a lot of poorly designed websites, and a great many websites assign point sizes to text, and absolute pixel sizes to graphics, rather than proportional measures. So until the majority of the web gets rewritten to your standard you'll likely continue to have issues.
While, I'll give SVG in web pages two thumbs up for coolness factor, it'll be some time before I'll be doing any graphics for the web in SVG, unless it is for a targetted audience.
Brian JD
On Sunday 06 November 2005 11:46 am, Jack wrote:
Well, considering web pages weren't designed to do this, I have to disagree that they /should/. While at the same time I'll say it would be /nice/ if they did. However there are a lot of poorly designed websites, and a great many websites assign point sizes to text, and absolute pixel sizes to graphics, rather than proportional measures. So until the majority of the web gets rewritten to your standard you'll likely continue to have issues.
Your entire email was patently false and completely missinformed with exception to this one point. This is *exactly* the reason I am excited about SVG. The standards which support the WWW as it stands today are unable to cope with differences in DPI. It is SVG which finally offers a standards based way out of that problem and it is for *this reason* that I am advocating moving to SVG *where it makes sense*. And it's not my standard -- it's the W3C's.
While, I'll give SVG in web pages two thumbs up for coolness factor, it'll be some time before I'll be doing any graphics for the web in SVG, unless it is for a targetted audience.
I guess you didn't read my first email. In a few months, 95% of the market will be running Firefox 1.5, IE6, Opera 8, Safari 1.4, or Konqueror >3.4 with SVG support. In around a year or two, when Firefox
1.5 has replaced all the 1.0 installations, roughly 98% of the browser
market will be able to view SVG content with very little or no extra effort required... Today, IE6 already can do this with any site being able to offer an instantly installed Adobe SVG plugin. Up until this point, it has been the OSS browsers that have been lagging behind. And they just caught up and did it much better than IE6 did... that's what's new and exciting.
On Friday 04 November 2005 20:36, Jason Dewayne Clinton wrote:
On Friday 04 November 2005 11:53 am, Luke-Jr wrote:
Last I checked, XHTML/CSS handle dynamic resolutions just fine...
Bahumbug. You need to check again. I run at 1600x1200 at 98 DPI and I can say with certainty that pages that are designed to fill the entire width of the page start to become unreadable when the font is 11pt.
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.
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...
Resolution isn't just width and height. On a good platform (X11 and Mac OSX) it also means the DPI of the monitor.
Last I checked, DPI was separate from resolution.
And that's to say nothing of the printing issues that are created by virtue of printing being done at 600 DPI or more while screens are in the lowly range of 75 - 110 DPI. The nasty differences are apparent when you try to print off a map from a web page and it becomes less readable.
Maps have always printed fine for me...
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.
Why did you even reply to this message? Are you going to make the claim that SVG has nothing to offer? Just trying to pick a fight for no good reason?
SVG is purely useful as an image format. They belong within IMG HTML tags, not as a replacement to the HTML itself.
Using Konqueror 3.5-subversion here and all I see is text...
So you didn't even try it? Check your KSVG plugin by trying to click on an SVG file in your local file system from Konqueror; it should open up in Konqueror. Otherwise file a bug against 3.5 RC1.
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.
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.
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.
On Friday 04 November 2005 08:09, Jason Dewayne Clinton wrote:
[1] http://jasonclinton.com/calig_test.html
I strongly feel that this is the future of the web and I'm looking forward to playing around with HTML+SVG. Let me know your thoughts!
Now with KSVG installed (part of kdegraphics, as I suspected), I see it... BUT! it crops, it does not
On Wednesday 09 November 2005 02:01 am, Luke-Jr wrote:
On Friday 04 November 2005 08:09, Jason Dewayne Clinton wrote:
[1] http://jasonclinton.com/calig_test.html
I strongly feel that this is the future of the web and I'm looking forward to playing around with HTML+SVG. Let me know your thoughts!
Now with KSVG installed (part of kdegraphics, as I suspected), I see it... BUT! it crops, it does not
As I said in the text on the web page: "Try changing the font size and then hitting *refresh* if your browser doesn't automatically update the size of the image to the left."
-
Don Erickson -
Jack -
Jason Dewayne Clinton -
Josh Charles -
Luke-Jr