Flannery O'Connor

(With a Bit of Explanation of the Method of Digital Imaging Called Scaleable Vector Graphics Which by Incorporating the Graphics Code with Popular Scripting Languages Can Display Art in a Most Flexible and Useful Manner As Will Be Evident By Looking At Various Images of Jazz Clarinetist Pete Fountain)

Yes, this is another picture of the American writer, Flannery O'Connor. This was created from scaleable vector graphics and can be compared to the earlier rendering - which was from a hand-inked pencil drawing - by clicking on the image.¹

Footnote

The colors, even in the original, were digital.

Close Footnote

The astute reader will note the subtle nuance when stating that the picture of Flannery is created from scaleable vector graphics - SVG for short - and is not the SVG drawing itself. Unlike the previous drawing of Pete Fountain which is the actual SVG image, the picture of Flannery is a Graphical Interchange Format (GIF) image which was created from the SVG image.

This brings up two questions.

Why SVG in the first place?

And why make a traditional bitmap once you have an SVG?

First things first. Why SVG?

Scaleable vector graphics are used - as those who read the previous and revised tribute to rock and roll star Bill Haley will remember - when there is the need for an image that can be expanded without loss of resolution. Such cases include creating variable sized icons for webpages as well as images for t-shirts and posters.

As beginning web programmers quickly learn, zooming in or expanding an image from the common bitmap formats - GIFS, JPEGS, PNGS, and TIFFS - can produce a jagged and fuzzy look. If you want to enlarge a bitmap, you have to create a new one at a higher resolution. But larger images come at a cost of computer memory and file space.

On the other hand when you zoom in on SVG pictures, they maintain their crisp and sharp look. So the image can be displayed large or small without actually making the file bigger or smaller.

OK. But why make a traditional bitmap GIF of Flannery from the SVG image rather than display the original SVG? We'd really like to know that.

I thought you would as Captain Mephisto said to Sidney Brand. But the explanation may take some time before you can say "I understand."

For one thing it ain't - to quote Sportin' Life - necessarily so that SVG's take less memory than the traditional bitmaps. Sometimes they do and sometimes they don't.

Fairly simple images generally have low SVG memory requirements. For that reason SVG has become popular for making icons and buttons. But more complex images - say a copy of Michelangelo's Sistine Chapel - might not only be oppressively demanding on memory, but it might be difficult to make a faithful SVG copy. On the other hand, if you need flexibility because you're not sure if the image needs to be made larger or not, SVG images might have the advantage.

For now, though, it will be useful to see exactly how the SVG images work. For our example we'll take the drawing of Pete Fountain as displayed below. This is an actual SVG picture, not a GIF copy, and is (obviously) black and white.

Now if you try to snitch the image by right-clicking the picture for downloading, you will fail miserably. And if the failure prompts you to view the actual source code, you won't see something like <img src="petefountain.svg"> which would mean there is a separate SVG file embedded in the page.

Instead this SVG picture is written directly into the webpage. That is, it is an inline image.

If you display the source code - easy if you know how - you won't see a link to a picture. You'll see the following equations (and to skip this rather lengthy bit of numerical brouhaha click here):

(To return to the top of the SVG code, click here.)

A crucial difference between vector graphics and bitmap "rasters" is how the image is actually displayed. A bit map is displayed by the computer defining a region of the screen and alters the individual pixels to be light or dark or of certain colors.

But a scaleable vector graphics drawing takes the text and numbers from the code and puts them into equations. The computer draws the equations on the screen. With the right type of equations and enough of them you end up with pictures.

That SVG's are made from equations is why the code is nothing more than text and numbers and can be viewed with a simple text editor. Opening a bitmap with a text editor shows gibberish.

Next, although the text and numbers needed to create the picture of Pete look pretty lengthy, the computer memory requirement is only 28 kilobytes. This is a nice, small, and compact size for any image and well suited for fast loading and display on the internet. In fact - an important point - this 28 kilobyte image is comparable in size to a GIF file which has similar resolution on a computer monitor.

All right. To demonstrate one advantage of an SVG over the bitmaps, we'll take a part of the picture and zoom in for a closeup. You can do that by turning to the top two lines of the SVG code, which to save you from having to move back to the top of the SVG equations, is:

Here the width and height parameters refer to the actual display size of the picture. Since we're using percents, it means the space allocated for the image is 100% of the web page width and 60% of the height. You can also specify the dimensions in pixels, vw, or em designations. Pixels, of course, are the smallest dots on a computer display, vw is ¹/₁₀₀ of the viewing width of the display, and em is the current font-size.

The viewBox parameters refer to how much and where you zoom in on the image. The units are in pixels. From left to right the parameters are the minimum x value and minimum y value - the upper left hand corner is 0 0 - then the last two numbers are the width and height of the image. So without additional formatting the picture of Pete as created by the code is 715 pixels wide and 736 high.

But you can change the viewBox numbers to zoom in and out and pan left and right. There are also translate parameters that shifts the image up and down and left and right. The width, height, viewBox, and translate parameters all interact with each other to form the image as displayed.²

Footnote

The SVG picture of Pete is displayed so that changing the shape of the webpage window will not distort the image. So if the shape of the window is changed from a portrait to a landscape view, the image itself might be clipped.

Close Footnote

The original settings for Pete are set to display the entire drawing. But if you twiddle the numbers so the top line is changed to:

Hey, presto!, you'll get a zoomed in Pete:

So by changing the viewBox numbers the display brackets only part of the image. Then with the width and height both being kept at 100% the image looks expanded and cropped.

But note that when zooming in on Pete's face, the image still has nice smooth lines. But if you were to take a GIF image created from the original SVG picture and crop and zoom in, what you get is:

Now this picture really isn't that bad. But if you look closely (and aren't using too small a device) you'll see that there is some blurred and jagged look to the edges.

But now let's finagle the SVG numbers some more. That is, we'll change the first line of the SVG code to read:

... and the image will now be:

And although the usefulness of such an view may be questioned, it serves to show that even with this much zooming and expansion, the lines are still smooth and crisp.

As to what the corresponding zoomed in and expanded bitmap looks like:

... which wouldn't look that great if printed out.

By more twiddling you can actually display a complete SVG image of Pete at poster size but with the high resolution maintained. This could be done by changing the first line to read:

... you'll get the picture of Pete in poster size (which you can view in a separate window if you click here). And if you look at the URL directory you can verify the file size is only about 20 kilobytes.

So we see that if a printed image needs to be small, large, or enormous, you only need one SVG image. Best of all the larger display doesn't take up any more memory or file space than a small one.

A particular advantage of the SVG is when you want to toggle back and forth between a close up and far view by clicking the mouse. Often this procedure requires two images, one of the wide shot and the other one for the close up.

But with vector graphics you only need one image regardless of how much or how often you want to zoom in. If you click on the picture of Pete below, you'll see how this works.

Click on the Image to Zoom In and Out

Both views are from the same picture.

At this point curmudgeons will point out that, OK, you can paste the SVG code into a webpage for an in-line image and use no more memory than a separate bitmap file. And you can zoom in and out using a single picture.

But look at all the repeats of the pictures! Posting multiple images with the same SVG code means you're actually using more memory than a bitmap file. After all, you have to put new code at each place where you want the picture.

Weeeeehhhhheeeeelllll, that's true and false. There are short cuts. For instance if you've posted code for an in-line SVG image once, you can use the <use> command - a little poetic alliteration here - where you don't write the whole SVG code again. Instead you snitch just a part - for Pete's picture it's the <path> attribute.

To grab the <path> you simply add an identification reference - such as id="basicPath" - when you write the entire SVG code.

That is for:

⋮
etc., etc.,
⋮

... 1.17 0 0z" fill="#333" stroke-width=".32"/>

... you slip in the id tag:

⋮
etc., etc.,
⋮

... 1.17 0 0z" fill="#333" stroke-width=".32"/>

So now when you want the in-line SVG image in another place, rather than rewriting the whole <svg> stuff with all the path numbers - which took 28 kilobytes - all you need to write in toto for subsequent pictures is:

... and lo and behold!, we see:

... our picture of Pete.

But instead of 28 kilobytes needed for the first picture, this second rendering only takes about 0.1 kilobyte.³

Footnote

Obviously the numbers in the <path> attribute were not written by hand. Pete was made with a drawing and then the SVG file was created using the proper software. This will then save the code so it can be used either as an external file - useful if the image is used on multiple webpages - or pasted in a page as an inline image. With something like the picture of Pete we used here, the size will be probably in the hundreds of kilobytes. But by making sure the scanned image isn't too large, and with certain simplification procedures, you can often produce a black and white SVG file less than 50 kilobytes.

Close Footnote

Now it is true that using in-line SVG's for something other than small icons can really clutter up a webpage. A webpage where you have, if not billion and billions then at least hundreds or thousands of numbers in a row, can be a pain to navigate and maintain. That's why people prefer using importable external files where instead of the in-line code all you see is <img scr="petefountain.svg">. So the webpage source code looks nice and uncluttered.

So external SVG files are generally the preferred route. And with proper software you can create SVG files from traditional bitmaps.

But ...

There's one thing that might bother new SVG users if they open an external .svg file with a text editor. At the top of the file they see there's an awful lot of Uniform Resource Locator addresses (URL's) to other web pages they've never heard of. If you edit out the URL references, even though what remains works perfectly for an in-line SVG image, if you import it from the file, you'll find the image won't display.

Although in reality the presence of the URL's are rarely a problem, you still may wonder if you can make external SVG files with no outside links or references. That way you can have the advantages of the external files which can be used by multiple webpages. But you don't have to worry if something messes up the link to another website.

Well, as Arte Johnson might have said, there are ways.

Today virtually all webpages use scripting languages. Although their number seems to be growing exponentially each year - Javascript remains popular. Like all web programming languages, Javascript can be used to write changeable or "dynamic" web pages. Best of all, if you can write an in-line section of a web page as Javascript, then you can cut it out of the page and put it in separate file. Then the file can be simply referenced into as many webpages as you like.

But rather than show how this is done using Pete - whose SVG code may seem rather intimidating for those just starting out - we'll follow Thoreau's advice: Simplify! Simplify! Simplify!

So we'll start off with something simple, simple, simple. Like a circle.

OK. If you draw a circle using in-line SVG, you'll write something like:

Simple enough. What this means is the svg element (as it's called) designates part of the window for the circle. In this case it's a rectangle taking up 40% of the window height and 100% of the width. The (x,y) origin of the svg drawing is the upper left hand corner of the rectangle and the x axis extends from left to right while - contrary to what we did in middle school geometry - the y axis goes downward.

Next we can see that we're going to draw a circle where the origin is at (15vw, 15vw) - remember 1vw unit is ¹/₁₀₀ the width of the window. The radius is 14vw units in length and the circumference is drawn with a black line 1vw thick. The interior is filled in with white.

So what you get is what you draw:

By changing the origin - the cx and cy - to percents and setting them to 50%, you can center the circle better:

Now here's where the Javascript comes in. If you're not familiar with it, don't worry too much about it. You'll pick up enough of it pretty quick. As an American President once said, "Trust me!"

What we do is to take the SVG code for the circle and convert it into a JavaScript function. This is actually pretty simple. You just write on the page:

Now note that everything between the double quotes is simply the code for drawing the SVG image. It's simply written as a single line. And to actually draw the circle, you write somewhere below the function:

<p id="circlePlace"></p>

<script>
DrawCircle();
</script>

The paragraph with the id="circlePlace" reference is put where you want the circle. Also you don't have to position the circle with the paragraph element <p>. For displaying pictures, the somewhat nondescript <div id="circlePlace"></div> is probably more typical.

A word of caution, though. If you want to draw more than one circle you have to use new id references - like circlePlace1, circlePlace2, etc. It's easy to make mistakes, but the point is you do not need to write the actual function again for the extra circles.

And the advantage?

The advantage is that you only have to write the actual function once. Afterwards you can draw as many circles as you like.

Some expert programmers may comment that this function uses the rather pedestrian innerHTML command. The innerHTML is used to write text to a webpage's source code. But using Javascript, you can control when and how the code gets written. So you can change what the viewer sees on the fly as it were.

But as we pointed out, you do have to put all the SVG code into one line without any line breaks. You also have to replace the double quotes (") in the SVG code with single quotes (') - double quotes are used to enclose the text of the innerHTML command. That is, they specify the content of the innerHTML element. Double quotes within double quotes don't work.

But once you've got everything written, you'll get:.

Yep. Exactly the same circle as before.

At this point it may seem that a Javascript function offers no real advantage to the <use> command which also lets us use the same code more than once without writing it again.

But functions also let you replace the numbers with variables. So you only need to write the function once to draw circles that look different.

Specifically you can rewrite the function as:

If you look carefully you can see that the innerHTML command does indeed write the code for drawing the circle. But you don't write the numbers. Instead you use variables like "height", "width", "centerX", "centerY", "radius", and the others are used instead.

And to actually draw the circle you write.

<p id="circlePlace1"></p>

<script> DrawCircle( "circlePlace1", "50%", "100%", "50%", "50%", "14vw", "black", "1vw", "white" ); </script>

...and now you get:

Exactly the same circle.

Now it's about at this point that once more the grumps come in and say, Huh! What's the big deal? A lot of work and gibberish to draw the same circle. And it's harder to read than the regular SVG code!

And what if you have something bigger to draw than this "simple" circle? It's going to make a big mess on your web page. And although we haven't made a deal about it, there are ways to change the attributes of inline SVG code without writing the whole thing as the Javascript function.

Some "improvement"!

Well, now we'll see the big advantage of Javacript. Instead of writing the function on the webpage, you put it in its own file.

Javascript files are recognizable by the .js at the end. Also you don't include the <script> and </script> header and footers. Just the function works fine, thank you.

For the circle we'll call this file drawCircle.js. So now with the function tucked away in its own file, to draw the circle all you see on the webpage itself is:

<p id="circlePlace2"></p>

<script src="drawCircle.js"></script>

<script>

DrawCircle( "circlePlace2", "50%", "100%", "50%", "50%", "14vw", "black", "1vw", "white" );

</script>

... and wherever the webpage sees <script src="drawCircle.js"></script>, then it thinks it's actually the whole function.

The net result is with the simple and compact code written above, you get:

And yes, it's the same circle. But at least the webpage isn't cluttered up with the whole inline function.

All right. The function's in its own file, and it's referenced in the web page. But now we can twiddle with the picture just as if the code was in the file itself:

So further down the page we can write:

<p id="circlePlace3"></p>

<script> DrawCircle( "circlePlace3", "70%", "100%", "50%", "50%", "28vw", "green", "3vw", "red" ); </script>

... and we get:

Note that even though this circle has a lot of changes, you didn't even have to rewrite the <script src="drawCircle.js"></script> line again. If we may paraphrase an Italian politician, once it's written, it stays written.

But as you expect, here the curmudgeons step in again! The circle, they say, whether inline SVG, inline Javascript, or external Javascript file, is a simple example. How about doing something both more complex and useful. Let's see you take the SVG code for Pete and make it suitable for using innerHTML

I thought you'd never ask.

Believe it or not, despite its considerable length, you CAN take the SVG code that draws the picture of Pete and make it into a Javascript function. That is, you can take the SVG code in its raw state and weed out the external URL's and other external references and metadata. They're all at the top of the file for easy weeding.

Then you make sure the blank spaces are only single spaces - sometimes you'll have multiple blanks in a row. Next make sure the adjacent brackets touch ( >< ), and that any line breaks are replaced with blank spaces. And don't forget to replace all double quotes with single quotes. If you do this all correctly, you'll find the SVG code is all on a single line that can be enclosed in double quotes for use in the innerHTML command.

Although what we've described seems like a truly Herculean task, the changes are easy and quick enough with a decent text editor - in fact, it's not necessarily that hard on a cruddy text editor. And the first part of the function with the variables isn't really any more complex that that of the circle. You now have variables for drawing Pete regarding size, position, viewBox, and translation.

So when all is said and done, the Javascript function for Pete ends up looking like:

Of course, you could use this as an inline Javascript function. But what we want is the function in its own file. And that's easy. Just open a new file with a text editor and cut and paste the function into the new file. Save it and name it something like petefountainsvg.js.

Then all you need on the webpage is:

... and eins mehr we get our picture of Pete:

Pete Fountain

And remember you can call the function and draw Pete as often as you want without even rewriting the <script src="petefountainsvg.js"></script> part.

And now we can see the big advantage of the external Javascript approach. We have a page of nice looking web code. And since it uses a Javascript function we wrote ourselves, we have the flexibility we want and no external links or metadata references. Nice and simple.

Without going into the boring details, by twiddling with the variables - and there's not really all that many - you can change Pete in lots of ways. For instance, you can make Pete smaller:

Pete Fountain
Le Petit

Shift him to the right:

Pete
A la droite

Or to the left:

Pete
A la gauche

Make him larger:

Pete
Le grand

And with a bit more Javascript you can even zoom in and out like we did before:

Click on Pete to Zoom In and Out

Pete Fountain

The point to remember is that all these pictures are from a single file with only a little bit of extra coding. So we can now enjoy the luxury of having all of the confusing numbers and elements of the SVG code conveniently tucked away out of sight. You can use the same file on multiple web pages and yet you can still twiddle the number just like each was an inline SVG image.

But it should be hastened to say that for all the personal satisfaction that programmers may garner by making their own homegrown external Javascript files, there's nothing wrong with using an .svg file that the various vector graphic software programs give you. This is after all the standard practice and the external files can often be be handled using the same syntax as any of the other graphic files.

Well, even though we can now say "I understand" about displaying SVG files and how they are suited for many image sizes, why isn't the original SVG file of Flannery posted rather than the GIF copy? We'd really like to know that.

As Captain Mephisto would say, as computer images become more and complex, particularly as more colors are added, the size advantage of an SVG graphic quickly reaches diminishing returns. And at some point bitmaps can become more memory economical.

In this case, the actual SVG file of Flannery used to make the GIF file takes up about 80 kilobytes. But the GIF file only needs a minuscule 19 kilobytes. True, 80 kilobytes is almost nothing compared to the gargantuan images posted today, but increasingly complex SVG images can quickly ramp up to the high megabyte sizes. Like so much in life, in selecting bitmaps or scaleable vector graphics, you have to look at the particular circumstances to make the correct decision.

As for Flannery O'Connor, you can read a bit about her life and books and stories if you just click here.

But wait a minute! Just hold on there!

... say the curmudgeons as they step in yet again. Don't think you can weasel out of doing the same for Flannery that you did for Pete. After all, Pete's file took only about 20 kilobytes; Flannery's was 80. We need proof that what was possible for Pete's simple black and white SVG image is also as easy with Flannery's multicolored picture.

So maybe if you take the SVG code that drew the picture of Flannery and make that into an external Javascript function, THEN maybe we'll accept there's a point for drawing SVG images from their own homegrown Javascript functions!

Well, certainly as files get bigger the editing requirements will increase. So in this case your purpose is both good and reasonable.⁴

Footnote

Henry VI, Part I, Act. V, Scene I, (Original: Act IV, Scene II), William Shakespeare, Mr. William Shakespeare's Comedies, Histories, & Tragedies, Published According to the True Original Copies, [First Folio], Issac Jaggard and William Bount (Editors), 1623.

Close Footnote

First we'll take Flannery's SVG code as saved by a graphics program. What you'll see is - and we've blanked out the specifics for the type of software and the websites referenced - is:

<?xml version="xxx" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://xxxxxxxx"
xmlns:cc="http://xxxxxxxx"
xmlns:rdf="http:xxxxxxxx"
xmlns:svg="http://xxxxxxxx"
xmlns="http://xxxxxxxx"
xmlns:sodipodi="xxxxxxxx"
xmlns:xxxxxxxx="http://xxxxxxxx"
version="xxxxxxxx"
id="svg10"
width="645.12"
height="645.12"
viewBox="0 0 645.12 645.12"

sodipodi:docname="flanneryoconnor_vector_xxxxxxxx_b_ver1.svg"
xxxxxxxx:version="xxxxxxxx">
id="metadata16">

rdf:about="">
image/svg+xml
rdf:resource="http://xxxxxxxx/>

id="defs14" />
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
xxxxxxxx:pageopacity="0"
xxxxxxxx:pageshadow="2"
xxxxxxxx:window-width="978"
xxxxxxxx:window-height="719"
id="namedview12"
showgrid="false"
xxxxxxxx:zoom="0.97346231"
xxxxxxxx:cx="322.56"
xxxxxxxx:cy="322.56"
xxxxxxxx:window-x="0"
xxxxxxxx:window-y="23"
xxxxxxxx:window-maximized="0"
xxxxxxxx:current-layer="g18" />
xxxxxxxx:groupmode="layer"
xxxxxxxx:label="Image"
id="g18">
<g
id="g22">
<path
id="path62"
style="fill:#fefefe;stroke-width:0.32"
d="M 0.06165749,488.88 C 0.09867557,437.49335 0.07634221,386.1064 0.214135,334.72 c 2.6059802,69.70278 28.381676,138.32381 ...

... A lot of numbers and other stuff ...

-8.00207,-6.997841 -8.50509,6.12784 -7.02823,11.43376 0.44959,9.98705 0.32489,19.99948 0.96113,29.97516 2.81728,-0.013 7.32591,2.26733 9.03414,-1.0357 z" />
</g>
</svg>

But then after we remove the external URL references, metadata, and references to the actual graphics software, we're left with:

Even now the file still has a lot of sequential spaces and a number of line breaks. And it is pretty big. If viewed in a text editor with word wrapping and with a 12 point font, the file takes up about 20 pages. The memory required to store the file is 80 kilobytes, which is, of course, the same as the image.

Admittedly simplifying Flannery's SVG code has been a bit more involved than for Pete. But not that much. For one thing we don't need all the id=" references nor do we need two <g> attributes. Once those are gone, we can now change the width and height from inches to percents, remove spaces between the end and beginning brackets so they come together (><), remove extra blank spaces, replace the line breaks with a blank space, and change the double quotes to single quotes. And this was all done pretty quick with a text editor.

So we end up with everything in one long line:

Now if you stick this directly in-line into a web page, it will create the SVG image. So you'll get our picture of Flannery:

And this is in fact an SVG. Not just a GIF copy.

And we didn't cheat. What you see really is from twenty pages of inline SVG code.

But now we can take this SVG code and alter it to a Javascript function like we did for Pete. That is, we write:

If you put this in the page, and underneath you add:

... you'll get Flannery again.

Again we didn't cheat. We really did put the massive Javascript function in-line. Seeing is believing and if you look at the file size of this webpage, you'll find it's over 260 kilobytes - huge by the standards of webpages. Looking at the source code will show you the whole function.

But now you know there are ways to avoid what we can call Javascript bloat.

As we did for Pete, we take the in-line SVG function and stick it in an external Javascript file. That's easy. Just copy and paste the function into its own file but without the <script> and </script> header and footer.

Now name the file flanneryoconnorsvg.js. Then instead of the whole function, just write in the webpage:

... and write below it:

<center>
<div id="flannery1" style="width:100%;"></div>
</center>

<script>DrawFlannery( "flannery1" , "100%" , "40%", "0", "0", "700", "650", "0", "0" )</script>

... and we get our picture of Flannery:

And again as with our picture of Pete we can reuse the external function and modify the image as often as we want. By changing the variables, we can make Flannery smaller:

Ms. Flannery O'Connor
From afar

Shift to the right:

Flannery
A la droite

Shift to the left:

Flannery
A la gauche

Make her larger:

Flannery Close Up

And even zoom in and out:

Click on Flannery to Zoom In and Out

Flannery Zoomed

... at no loss of resolution.

There is of course other things you can do with SVG images whether homegrown or software created. For instance, you can even have Flannery float around in the text.

Floating images are useful for illustrating webpages when you want to have an image close to the text it refers to. Floating an image is pretty easy and is mostly done from the formatting in the webpage rather than changes to the SVG parameters.

But although the size of the SVG image of Flannery is larger than the corresponding GIF file, there are advantages to the vector graphics. Remember the last seven images were drawn simply by calling the one external Javascript function. If these were bitmaps then making the different sizes would take pictures totaling around 100 kilobytes. But the single SVG function only takes about 80 kilobytes. So there's a net savings of 20 kilobytes.

There are of course many other ways to handle scaleable graphics. This demonstration was a simple one, and others, as Aragorn said to Gimli and Legolas, might be devised.

Return to CooperToons Caricatures

Return to CooperToons Homepage