W3C home > Mailing lists > Public > www-html@w3.org > February 1999

Adding simple graphics in HTML (Part II)

From: Ong Zhixian <Ong123Z@URegina.CA>
Date: Tue, 16 Feb 1999 23:53:55 -0500 (EST)
To: "W3 Org" <www-html@w3.org>
Message-ID: <000001be59d7$23da43a0$680a038e@Zhixian>
Dear Friends,
                    Thank you all for all your helpful suggestions. Thanks to Braden, I went to take a look at draft specification of SVG and it proves to be what I'm looking for in my suggestion with one exception. It's designed for XML in mind and not HTML. So it doesn't exactly quite fit into the shoe.
                    Incidentally, does any of you know PostScript? It's somewhat similar to LaTex. The way I understand it, before HTML, document types like LaTex and PostScript are fairly popular because of their ability to integrate graphics into the document. That is really what I'm suggesting: Integration of simple graphics (boxes, circles, ...etc.) into HTML documents. I suppose, using picture files is fine but why download two files when you can just download one? Worse yet, given the scenario that you have a fair number of flowcharts that you want to present on the HTML document it would mean that you have to download several of such picture files where as if these graphics are integrated into the HTML document, you just have to download the document and let the browser do the rest of the work of presenting the graphics.
                    Take a look at the following picture:

                    It is written using these few lines of code:

306 396 translate

/c 10 def
/p 4 def

-90 rotate

 -100 0 translate
 0 0 moveto
 2 1 c{
  100 c div mul
  dup 0 exch
  -180 180 arc
 } for
 100 0 translate
 360 p div rotate
} repeat


Of course, this code doesn't really make much sense to those who doesn't know PostScript, but if these few lines of code can render a somewhat sophisticate picture like this, why not let HTML have such capacity as well? We can just simplified it and make it more readable.

                    I would like to thank Mr Ian Samson for asking a bunch of related questions and would like to address them here.

            I suspect the reason, no one complain HTML incapability of working simple graphics is due to the reason that simple graphics can be easily made using graphics program and then embedded into HTML files. While this process is modular and I somewhat approve it but given the scenario I raise above(multiple simple graphics on a single page), end users could be at the losing end for they would need to download more files than is necessary.
            Extended ASCII characters are as you have said it, ASCII characters. They are not really graphics in any real sense. They are just a whole bunch of funny looking characters. While they are use somewhat commonly to draw things like windows, lines, boxes, ...etc in their DOS environments, I don't think I ever saw a web page using extended ASCII characters to draw simple graphics. Heck! I'm not even sure if ISO-8859-1 (ie. Latin-1) supports extended ASCII characters. Anyway, extended ASCII characters are rather limited. There's no curves(arcs) or circles. So, it doesn't really count as a form of presenting graphics.
            I'm not proposing any line or graphics drawing characters. In my opinion, characters are really too limited to be of any decent use in graphics. Rather, I'm proposing this: Design a set of HTML tags that will draw graphics.
            Different font types and character sets is a somewhat concurrent problem although both Microsoft and Netscape has began to take steps to solve it through OpenType(Microsoft) and downloadable fonts(Netscape & Bitstream). I certainly don't have a solution to this problem. Anyway, if the what I'm proposing gets accepted, perhaps we could render fonts using the graphics engine used generating the simple graphics. The engine should render existing fonts on the computer into graphics for use with the simple graphics.
            As for why didn't academics develop things like this? One possible answer is that they are too used to the old technology (ie.PostScript and LaTex files) but I don't think this is so. It is more likely that they do not need the new technology. And if the wheel isn't broken, don't fix it, right? Or maybe, they don't think it's necessary or useful. Maybe, the developers are just too lazy. *laughs*. Just kidding. No, I don't know the real reason.
            As for the design of the tags, I'm thinking along the lines of things like: 
1.) Drawing a line.
<line x=? y=? color=?> 
2.) Drawing a curve
<arc curvature=? x=? y=? color=?>
3.) Drawing a circle
<circle circumference=? x=? y=? color=?>
4.) Drawing labels
<labels text="?" x=? y=? font=? color=? size? style=?>
and so on.
            For postioning purposes, we can use (a) CSS style sheets, (b) allow percentages, pixels or points for the values of X and Y.
            Browsers such as Lynx doesn't not render any real graphics at all. At best, they render extended ASCII graphics. So, I think, we can(?) ignore(?) them. And no, I'm not proposing an addition to over-extended languages and character sets on certain OS platforms but an addition to HTML capabilities.
            Yes, Java could probably do all these. But loading applets take too much time in comparison to HTML files. Besides, Java is a programming language. Why learn a whole new language(for those who are not familiar with Java, C or C++) when you need only learn a few simple(?) tags, right? Besides, with "dynamic" HTML coming out, many of the tricks done with applets can be similarly done with the help of scripting. But I suppose, Java is a class of it's own and can do more powerful things if you know how.

That's all for now. Once again, thanks for your comments, guys.

                                                                                                                Yours Sincerely,


(image/bmp attachment: Outlook..bmp)

Received on Wednesday, 17 February 1999 03:43:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:50 UTC