Category: SVG

All about Scalar Vector Graphics (SVG)

Categories
Media SVG Writing

Working…

I’m almost ready to go live with the site. Right now I’m trying to create a custom Drupal theme from this site’s design. Once that’s finished, then we’ll be in business.

The image below was created by converting two bitmap graphics, the book cover and a painter’s easel, into one combined image using SVG–Scalable Vector Graphics.

Though the book cover image was large enough for my intended use, the easel wasn’t and using SVG allows us to resize images beyond the original and without pixelation. The combined image was sized to what you see here, and then re-converted back into a bitmap graphic, in this case a PNG.

I used Vector Magic to convert the bitmap images to SVG and Inkscape to convert back to the bitmap. Inkscape also has a bitmap trace function to convert from bitmap to vector (SVG), but I’ve not found it to be as good as Vector Magic for my purposes.

I received my inspiration for the drop shadowed clip art used in all of my sites from the old English/Victorian toy theaters. These wonderful creations featured static backdrops painted like a theater set, with characters that could be clipped or cut out from a book, pasted to a stick and then used to re-create a specific play. Ironically enough, toy theaters lost their popularity with the advent of television, itself endangered by the increasing use of the web to deliver video content. What goes around, comes around.

All is not lost for toy theater, though. Released last year and with a planned US release of this summer, a new movie adaption of Dante’s Inferno was created with modern theme and as toy theater. If your computer can swing it, select the HD trailer. Note that this trailer does have a mature theme.

For the more ambitious, a laptop framed in a toy theater box.

Categories
SVG Writing

Off Painting

We’ve finished up proofs on Painting the Web this week, and I have my first snap of the new cover. I embedded a version of the cover that’s been converted into SVG over at Burningbird, but have included a JPEG below.

Now I can turn my attention to the new book, as well as the site changes and book support sites. I’ve closed down my experimentation at Burningbird, leaving it for now with an appropriate background image. Red is not normally my color, but I rather like the warmth of the color and the new background SVG works exceptionally well in a flexibly sized environment.

Something will happen to RealTech, I’m just not sure what. Only the Feeds know what lurks within the hearts of online writers. Mwahaha, or something to that effect.

Spring has arrived here in St. Louis, though reluctantly and wetly.

Painting the Web

Updated: O’Reilly went with a Golden Oriole rather than a Prairie Chicken.

The cover of my newest book, rendered in SVG. I used Vector Magic to convert the raster image to an SVG vector drawing. I then “combined” it with another image that I had vectorized.

Categories
Specs SVG Technology

State of SVG, state of the Bird

I was quite pleased to see all of the activity related to SVG in the HTML5 working group’s public email list. I agree with those who say that HTML5 needs to be able to work with any unknown vocabulary via namespaces, rather than try to coerce a HTMLized version of SVG and MathML. A case in point is the vocabulary items providing metadata information about the image that Inkscape puts into SVG documents. Creative Commons, Dublin Core, its own stuff–Inkscape believes in metadata.

In the meantime, I will continue using XHTML with my SVG design integration. I was momentarily peeved about the repetition of the “draconian” error handling of XHTML every time anyone even mentions the topic. However, I’ve since decided that rather than be peeved, I should feel flattered. According to the people who talk about the “draconian” nature of XHTML, I must then be some kind of superwoman to be able to support it. Hey, go me.

Burningbird currently demonstrates my new philosophy of design, though not necessarily using a specific design I will keep–though it is bright and cheerful in a “Horton Hears a Who” way, and I need bright and cheerful with all the rain and flooding we’re having. As I’ve mentioned in a couple of earlier posts, the site uses a relatively simple SVG image as flexible background, in addition to other SVG for decorative accents. For IE or other user agents that can’t process SVG, I provide a tiny repeating blue striped background, so that they don’t get a plain page. Different but decent.

Though I use the rgba function to set the semi-transparent background of the center column and sidebar, I first define a background color using hex notation:


.column
{
        background-color: #fff;
}
.column
{
        background-color: rgba(255,255,255,0.8);
}

Browsers that don’t support the rgba function yet will pick up the hex notation, getting a nice coordinated blue center column, with white for content and sidebar; otherwise, they’ll pick up the rgba notation, with a completely transparent center column, and semi-transparent sidebar and entry area.

Safari and Firefox support rgba, but Opera doesn’t at the moment (it most likely will in the next beta release). However, again the design is such that it degrades gracefully and looks decent even without support for this CSS3 color module attribute. Or I think it looks decent, though lord knows I’m not a web designer. Let’s say my use of the technology is sound, but my design sense may suck, depending on your perspective.

I’ve also implemented text-shadow, in this weblog and at Burningbird. The sub-headings have a very tiny text-shadow, which really makes the text pop out nicely:


        text-shadow: #ccc 1px 1px 2px;

Opera and Safari both support text-shadow, but there’s no adverse impact with browsers that don’t. It adds a nice polish, but that’s all it is, polish. I really like it, though, and can’t wait until Firefox implements it.

All in all, Safari is currently the browser with the most advanced support for my design concepts, with Firefox a close second.

Another interesting point on the design is the flexibility as to scale. The background scales large for larger monitors, but the entire content will resize based on browser window size, as well as font size and resolution. If you resize the window small enough, the sidebar pushes to the bottom. This is not a bug–the sidebar gets pushed out of the way when the web page is accessed by a smaller device, such as an iPhone. It’s still there, but not taking up valuable real estate.

In fact, the photo and the bright yellow box currently showing also demonstrate the scaling–the yellow box is a SVG element that is constrained to size to the parent container, but preserve aspect ratio; the photo will display at its maximum width, but scale down as the window scales. All in all, the site can scale to an infinite width or down to a minimum 40em in width, and still be readable. The site even works with my Kindle, either using the mobile CSS, or when using the Kindle’s advanced web browsing, the scaled down width and the blue stripe background (though in gray tones, of course).

Best of all, you can zoom the text and the whole site zooms out, so that the words per line length is consistent.

That’s the key to my site designs in the future–not trying to get the sites to look the same in all devices, but looking good for each. Or at least good enough while still giving me the opportunity to try out new technologies. We’ve fixated too much in the past on making sure a site looks “the same” in all browsers. We’ve crippled our creativity trying to make sites look “the same” in all browsers. This was someone’s anal design “rule” set out long ago, and it’s time we toss the bugger aside.

I promised Bud a writing on SVG and performance, especially as compared to raster images (such as PNG, JPEG, and GIF). I actually checked out the WebKit code to see how it manages graphics, and was surprised at how easy I was able to follow the code considering that I haven’t worked with C++ since my old Windows programming days. The WebKit code is well organized and documented, with a minimum of tricksy coding. It really is an excellent product–not the least of which that it will probably be the first browser to pass Acid3. It or Opera, they’re both very close.

Anyway, the writing will be coming after my site redesign, after I finish proofs, after I get the next book started, but I wanted to quickly mention my discovery, in the course of my explorations, how committed Apple is to the use of SVG–in browser and out–because of the scalability. Think of it: if you have a desktop icon that you want to look good in a tiny screen, as well as a monster 60 inch television, would you want to use raster images? Of course not. OK, then, would you want to invent a graphics format, or use one that already has extensive tool support, as well as earning you brownie points with the development and open source communities?

*beep* time’s up

Apple chose wisely. Still, I was surprised at the strength of commitment Apple has to the integration of SVG into its products. And this despite HTML5 disapproval. Hey, go fruit.

Update Opera is stating they’ve reached 100/100 on Acid3. Congratulations Opera! Can’t wait to get my hands on a working tech preview. When I do, I’ll run it against the *Firefox Minefield edition, and the latest WebKit build and we’ll see how they’re all doing. The real test is getting 100/100 with a publicly accessible browser version.

I will declare a winner in my Acid3 races once I’ve seen the 100/100 with my own little eyeballs. Being as I’m superwoman and all.

*Oh, and IE8, too.

Categories
SVG

ACIDBird

Recovered from the Wayback Machine.

Today’s design is based on the Open Road SVG image that was just uploaded. This SVG image is ideal for a background, because it lends itself to morphing. It’s also a horizontal image, which works better for a background image.

The image is adding into the page in such a way that it expands to fill the page, regardless of how small or large the browser window is. It is resolution independent. I use two SVG attributes to manage how the images show in my sites, both set on the SVG element, itself.

The first SVG attribute I set is viewBox. The viewBox attribute is a way of capturing a specific section of the SVG image, and using this captured section to fill a given viewport. For instance, if the image naturally sizes to 400 pixels wide, 200 pixels tall, setting a viewBox to 0 0 400 200 is equivalent to how the image would fill the viewport by default without a viewBox. If you use different settings, say 50 20 350 150, then you’re modifying the viewport for the image, setting the beginning x at 50, beginning y at 20, the width at 350 and the height at 150. Since, by default, x increases from left to right, y increases from top to bottom, setting the beginning x and y clips the upper and leftmost edges of the image. If the width and height is less than what the image’s true width and height is, this clips the bottom and rightmost section of the image. You can use any combination, including negative for min-x and min-y, but you can’t use negative values for the width and height. If you use a negative value for the min-x and min-y, it’s about the same as using a margin–it pushes the image over and down.

The viewBox I put on the Open Highway SVG is 50 50 600 400. I decided I didn’t like the sun showing, so I set a smaller width, clipping the image on the right. I didn’t like as much blue sky, and I liked having the road focused a little off-centered, to the right, so I set the min-y and min-x accordingly.

Now, if I used the SVG, as is, with my expanded background, what would happen is the browser engine would attempt to fill my space, but still maintain the image’s original aspect ratio. The image would expand to fill the width at a 100%, but to preserve the aspect ratio, the height wouldn’t be enough to fill the space. The image expands in both dimensions until one fills the space, and then stops expanding along the other dimension.

This can work sometimes, and sometimes it doesn’t work. In this case, it doesn’t work.

I use the second SVG attribute, preserveAspectRatio, set to a value of “none” to tell the browser engine not to preserve the aspect ratio. Then the image expands 100% along the width and height–stretching the image, true, but filling in the space. If you choose the right background, such as Open Road, which works rather well, it doesn’t matter the perspective, it works. There are also other settings for peserveAspectRatio, but I’ll play around with those another day, with another design.

My two other images are not the same as the background, as I’m not demonstrating the resolution independent nature of SVG today. I used a coffee cup for the top image, and a little car for the bottom, both of which I think complement the “open road” scheme. Both have the viewBox set, otherwise the SVG images would not resize to fit the container. Instead, I’d be stuck with scrollbars (more on scrollbars later). The coffee cup viewBox creates a viewport big enough for the entire image. The car’s height is clipped, so that the wheels line up directly on the bottom of the page.

I used the object element rather than inputting the SVG inline for today’s theme, as I wanted to record another couple of bugs with WebKit and Opera.

Webkit stretches the image, but it doesn’t draw the content over the SVG until I scroll down and back again. In addition, WebKit also adds a white background for the SVG, which is something we can’t seem to control. This can really ruin a nice effect, such as the top coffee mug, and the bottom car.

 

Opera doesn’t stretch it at all, and also persists in putting scrollbars on the objects. No matter what I do to try and control the object overflow, the scrollbars get added.

I’ve turned in bug reports for WebKit about the drawing problem and the white background. I’ve also noted problems with pages for Opera, but I’m going to make sure formal bugs are entered for the gradient problem with yesterday’s design, and the object scrollbars and inaccurate resizing with yesterday’s and today’s design.

The work on the themes does demonstrate another important issue. Something like ACID2 and ACID3 are handy ways of seeing if key web technologies are supported, but they’re not comprehensive. Firefox 3b3 scores less than Opera 9.5b and the WebKit nightly on ACID3, but it has better overall support for SVG; especially as integrated into a web page. If the browser makers focus too much on the Acid tests, they may miss the overall picture, which is ensuring that SVG works well in a web page. I have confidence, though, that my reported bugs will generate activity.

I won’t keep this design for long–or at least, I won’t use the object elements–because IE does not deal well with SVG loaded into an object elements that are supposed to be in the background, no matter what version of IE I use. The content is pushed down with IE7, and gone altogether with IE8. I’m getting this behavior even when using the Adobe SVG plug-in.

In the meantime, since Microsoft isn’t welcoming bug reports from the general public related to IE8, my only recourse is to remove the Adobe plug-in. Once the Adobe SVG plug-in was de-installed, then the page opened just fine in IE. Well, it’s in black and white, but legible.

updated

Bud didn’t like the clouds.

*poof*

Clouds gone.

Categories
SVG

The incredible, scalable SVG

Recovered from the Wayback Machine.

One of the advantages of SVG over some other graphics capability is the fact that SVG is vector-based. A vector graphic means that images are created via *recorded mathematical primitives (circle, line, square, etc.) rather than based on fixed pixels. Because SVG is a vector graphic, the same image can be sized very small or very large and remain crisp and bright regardless of the size. Typically the image has a smaller file size, too.

This doesn’t seem like a big deal if the image is placed in a weblog post, and statically sized. My own use of SVG at this site is statically sized and I could just as easily use JPEGs or PNGs, other than the fact that I recreate the images based on the header graphic. However, over at the main Burningbird site, I’m experimenting around with using SVG as a resizable background element, and it’s this use that truly demonstrates why SVG can be such an advantage over bitmap images.

Consider computer monitors and the problems we’ve always had about differing monitor sizes. Either our content seems to extend beyond the edges of the browser, generating a horizontal scroll bar. Or it’s a skinny little bar in the midst of a vast expanse of blank space. Even if we use a background image and repeat it, we still end up with a mind numbing expanse of *nothing*.

As an alternative to the static, repeating background image, I used an SVG image I found at the Open Clip Art site, sized dynamically in the background, and statically in both the header and footer. For the background image, attributes on the SVG element provide further instructions in how the image is resized, and whether to maintain perspective or to have the image fill the given space. Right now, I have turned off the perspective, and the result is interesting when viewed in different sized windows.

Providing a dynamically sized background image is a fairly new use for SVG, so it’s not without challenges. Opera on the Mac has problems with the resizing, as well as the gradients used in the image; Safari has problems with the gradient, though Webkit works nicely. However, I originally tried this approach using an external SVG file, incorporated into the page using the object element, but WebKit had problems with the object element. At this time, Firefox 3b3 is the only browser that manages both the gradient and the sizing, in addition to SVG inline or linked externally. I expect, though, that all three–Safari, Opera, and Firefox–will do well with using SVG for a background image in their next released versions.

As for IE, the entire site shows up primarily in black and white. The site is so plain, in fact, that I have a link labeled, “Why is this page so plain”, to a page explaining my use of SVG that only shows up when the site is accessed by IE. As I’ll be incorporating SVG into all of my sites, I’ll be continuing my “B&W” support for IE to all the sites, rather than restrict access with the XHTML MIME type, as I originally did with this site.

Apple announced that it will be supporting SVG in the version 2.0 of the iPhone SDK because, according to a story on the topic, SVG is a resolution-independent image format that is highly compressible. The three variations of the same image at Burningbird demonstrate the resolution independence, with the image looking good in the site footer, the larger header image, and the potentially very large background.

Once I’ve debugged why the image isn’t loading using the object element in Safari/Webkit, I could use one external gzipped SVG file, and eliminate most of the size constraints. The only restriction with using an external SVG file is that using the object element for the background can cause some odd behavior with IE. In addition, from a drawing performance perspective, I also found the inline SVG to be the best of the two options.

Eventually, though not implemented in any browser that I’ve been able to see, we’ll be able to set the SVG background using the CSS background-image attribute. This just adds to the intriguing possibilities. update This functionality is implemented with Opera 9.5, as demonstrated in this example.

*Bonus material: a detailed instruction video from Nortel on the differences between raster and vector graphics. This is an older video, though. Support for SVG has increased, both with editing tools and with browsers. Other video formats and image lessons from the Nortel LearniT page.

Update I’m just playing around with this pattern, I’m aware that not all browsers are processing it correctly. This gave me a chance to do a little browser testing and also have a little fun with color. We’ve had so much cold and snow that I was desperate for a little color.