Original Usenet thread from alt.ascii-art, started 13 Sep 1998.
_ _ _ _ _ _ | | | |___ ___ _ __ ___| |_ / \ _ __ ___| |__ (_)_ _____ | | | / __|/ _ \ '_ \ / _ \ __| / _ \ | '__/ __| '_ \| \ \ / / _ \ | |_| \__ \ __/ | | | __/ |_ / ___ \| | | (__| | | | |\ V / __/ \___/|___/\___|_| |_|\___|\__| /_/ \_\_| \___|_| |_|_| \_/ \___|
About rendering ascii code in a .txt medium
alt.ascii-art
· 48 messages · 13 Sep 1998 - 30 Sep 1998
Discussions on OE and Arial in parallel threads made me write this essay.
The correct or incorrect appearance of ascii pics in a .txt medium is
determined by:
the ascii code, which determines character only (including lower case, upper case)
PLUS the following typographical parameters
font face, i.e. Courier, Arial
font size
font color, default is usually black
background color, default is usually white
line spacing, which make pics appear taller or shorter
kerning, i.e. spacing between characters,
which make pics appear wider or narrower
alignment, default is usually left justified
and ...
... there are other parameters as well (such as font style, i.e. bold, italic,
etc) but the above parameters are key for most ascii pics.
Please note, that only the ascii code is standardized, and that NONE of the
typographical parameters is standardized. Since the typographical parameters
are absolutely vital for the correct rendition of any ascii pic, their
non-standardization is a constant source of debates, the most common of which
is the proportional vs non-proportional debate.
The simplest text editors have default typographical parameters that users can
not change. This makes it easy for the user to immediately use the software
"out of the box" but can also fool the user into thinking that the appearance
of ascii pics is determined by the ascii code only, which is NOT true. Again,
see the above listing of typographical parameters that will make or break any
ascii pic.
(On the opposite side of the spectrum, high-end word processors, page layout
software and the like, allow the user to change all of the above typographical
parameters and lots and lots more.)
In the past, the simple text editors that were built into email and newsgroup
software have defaulted to non-proportional font, size 9 to 12 for the font
sizes, etc. These common defaults, although not standardized, have allowed for
the correct transmission of ascii pics through email and newsgroup software.
Another example is the default font face on aol, Arial, which allows for the
correct transmission of ascii pics WITHIN aol. But of course, since Arial is a
proportional font, ascii pics transmitted from aol to the outside world (and
vice versa) will be distorted. (I refer to pics made from proportional and
non-proportional fonts as ascii pics, since both are based on ascii code,
albeit with different typographical conventions.)
Therefore, for the time being and for some time to come, it is best to use
Arial for aol only, and non-proportional font only for the rest of the world.
A few words on the future.
Text editors built into email and newsgroup software are evolving towards more
sophistication, e.g. more and more are defaulting to proportional font. This
evolution is good for general use, e.g. it provides improved legibility (your
own handwriting is proportional) but it is devastating for ascii pics.
Some time ago, Microsoft and working groups of the IETF (Internet Engineering
Task Force) have therefore published recommendedations against the use of
ascii pics on the Internet. But what they (and the ascii community) forget, is
that it is EASY to protect ascii pics by including the above typographical
parameters as part and parcel of the pics, say, in the form of html tags. This
would also allow pics generated within aol to be correctly viewed in the
outside world and vice versa ...
... and there are many more doors that are opened up. But I stop here, the
issue is still a few years out from becoming both threat and opportunity.
Also, I refer to my past essays illuminating different aspects of the same issue.
=========================================================
[] .oo Visit the Gallery of the 'steins! []
[] ( -) http://www3.sympatico.ca/petecasso/ []
[] " " Frogstein, who has a point behind his eyes []
=========================================================
Matthew Thomas wrote: > Pete, you are just too fond of writing essays. Stop it. :-> Why should I stop writing essays? The FAQs are essays too! Perhaps we should stop posting the FAQs then! :-) > Sorry Pete, but you're wrong, wrong, and wrong again. Well, I think I am right, right, and right again :-) And I think you are wrong, wrong, and wrong again, see the three points below. > First: typographical parameters are NOT `absolutely vital for the > correct rendition of any ascii pic'. Wrong #1. Typographical parameters such as proportional or non-proportional font ARE absolutely vital for the correct rendition of any ascii pic. > Second: the non-standardization of typographical parameters is NOT `a > constant source of debates'. Wrong #2. Just look at the guests dropping by here on this newsgroup wondering why they see garbage instead of pics. > Third, the choice between proportional and `non-proportional' (as you > call fixed-width) fonts is NOT a `debate'. Wrong #3. Both are ascii art, since they are both based on ascii code, just different typographical convention. > Yes, well see above for my disagreement with that definition. Answered in the above, both are ascii art. > And on the subject of AOL, I have no more details, but when I was aol member, ascii art with Arial worked well within aol and with my Mac. I just checked my system, and found the fonts Arial, Arial Black, Arial Narrow, and Arial Rounded MT Bold, presumable installed with the aol software. (aol allows RTF on their internal mail and newsgroups, wow, another topic for debate!) > Microsoft's recommendation, if you remember, resulted in derision from > both Jorn Barger (the author of the original FAQ) and myself; Hahaha, that is utterly inconsequential, I fear ... :-) > As for the IETF, only two IETF RFCs (2229 and 2295) mention ASCII art. You got me here, I don't have the IETF references at my fingertips and I will not dig into the humongous IETF archives either. This line here is also a response (or no response, if you will) to Ilmari's posting. > Wrong, and wrong, Pete. Firstly, I've said it before, and I'll say it > again: HTML is not a presentation language. It is a semantic markup > language. Well, I think I am right and right again :-) html tags can be used to convey info on how display ascii pics and they do so with less reliance on text editors having the right typographical defaults (see, I can say things without using buzzwords :-)) > Good luck trying to specify the font, color, and line spacing > to someone on a monochrome monitor who doesn't have the particular font > installed. Haha, this is like expecting color prints from a black and white printer! Of course, one does not have to be that stupid! Use a font that is available on all platforms, that's a little bit smarter! > Secondly, HTML is not acceptable in the majority of Usenet I have explicitely stated "a few words on the future" ^^^^^^ > Pete, I love HTML even more than you seem to, Hahaha again, it is uttlerly inconsequential how much you and I love or hate html ... :-) > Your attempts to provide a > pseudo-academic foundation for the use of HTML tags in a.a-a I am not attempting to provide a pseudo-academic anything, I am merely stating clearly observable trends. And that trend is, that the number of email and newsgroup software defaulting to proportional fonts is growing, for the benefits that it brings for general usage. So the numbers are growing, and if more than half the people on the Internet use proportional fonts, then html tags will not only work, it becomes an absolute necessity for ascii pics to be correctly displayed to the majority of Internet users. Again, that is still a few years out, in my view. > ASCII art is a simple medium; Hah, that is a failure to differentiate between artform and medium! > learn to enjoy the simplicity, instead of > pining for extensions to it. Thank you, thank you, I love simplicity and that's why I love ascii as an artform, I believe before you did. But perhaps you can learn how to enrich the artform with additional media :-) ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> is AOL available for the Mac? yes. at least the disks i used to get said 'if you need mac format call...' > If so, does it use the > Arial font, or something else (such as Geneva) which is more common on > Mac systems? If so, character art sent from a Windoze AOL user to a > Mac AOL user (or vice versa) will be distorted. And what about the > people with newer versions of AOL who can (I think) change the font to > read their messages in ...? doesn't matter if it's a different font or not. all 'arial font' are not created equal. --ever made a nice column of data/text by indenting everything, say, 5 spaces in? you print it out and the col. are all jagged? that's because the computer and printer don't agree on the details of the font, like for one an A is 1.4 times as wide as a B, but for the other it's 1.41 and spacing gets changed. (in many [most?] prop. fonts the *spaces* change size even depending on what their next to [actually, this) this has improved, but is still *far* from perfect. i've even had a nicely formatted bit of text and you change the size of the same font and it gets all messed up (try it!) (and i don't mean line wrap either --stuff that only goes 1/2 way across the page. nor any particular platform. [ug! obsidion sharp! oog! break too easy! flint *hard*!]). and of course prop. fonts are a half-way step anyway. something like tex* that knows about kerning etc. is (can be anyway) a huge improvement for the looks of a document (lessen, a course it's an ascii-art pic!) *the only such program i know by name that does this, but this shows clewlessness on my part, not a lack of such programs. i know there are others. and just so there's some ascii art here can anybody id the artist on this garfield? ##### ####### #**#!!### #**#!!!!## #****#!!!!# #****###!!!# #*****#!!!!# #*******#!!!# #******#!!!!# #*********#!###!*!*!*#!!!!!# -- #!*!*!*!*!*!#!##########!!!!# /_ ###########!##!!!!!!!!!!#!!!# //__ ###!!!!!!!!!!!#!!!!!!!!!!!!!#!!!####/// \ \ ##!#!!!!!!!!!!!#!!!!!!!!!!!!!!!#!!!!!!!# _\ ##!!#!!!!!!!!!!!#!!!!!!!!!!!######!!!!!!!*# \\ ##!!#!!!!!!!!!!!!#!!!!####### #!!!!!!***# ___\\#!!!###################***** #...!!*****# / \#!!!.# ***** # *** #....*******# #*....# *** # #.......*****# #**.....## ***** ##........!!****# #!........## *******#########......#...!!!!!*# #!...........#######.*****...............#.#..!!!!**# #*.....##.............#..#...............#...#.!!****# #*....#.#............#....#............##......!*****# #*.......##.......###......###........#.......!!!****# #*.........#######......!!....########.......!!!!!***# #!!!.................!!!!!!!!.............!!!*******# #!!!!............!!!!!!!!!!!!!!!!!!!!!!!!!!!******# #*******!!!!!!!!!!!!!!!!!!!!!!!!!!!!***!!!!*****# #******!!!!!!!!!!!!!!!!!!!!!!!!!********!!****# ##*****!!!!!!!!!!!!!!!!!!!!!#*************### ##****!!!!!!!!!!!!!!!!!!!!!###******#### ####!!!!!!!!!!!!!!!!!!!!!!!!######!# #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*# #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!***## #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!******# #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*******# #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*****# #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!**# #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!## #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*## #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!***# #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!####!!!!!!****## #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!###****##!!!!******## #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!##**!!*****#!!!********# #!!!!!!!!#!!!!!!!!!!!#!!!!!!!#***!!!!***!!!!**********# #!!!!!!!!!!#!!!!!!!!!#!!!!!!!#****!!!!!*!!!!!!!!!!*****# #!!!!!!!!!!!#!!!!!!!#!!!!!!!#*!!***!!!!!!!!!!!!!!!!!***# #!!!!!!!!!!!!#!!!!!!#!!!!!!#*!!!!!*!!!!!!!!!!!!!!!*****# #!!!!!!!!!!!!#!!!!!!#!!!!!#***!!!!!!!!!!!!!!!!!********# #!!!!!!!!!!!!!#!!!!!!#!!!!!#****!!!!!!!!!!!!!!**********# #!!!!!!!!!!!!!#!!!!!!#!!!!!#*****!!!!!!!!!!!!!!*********# my address: (rot13) cva...@qnegzbhgu.rqh
Pete Casso wrote: > > Discussions on OE and Arial in parallel threads made me write this > essay. Pete, you are just too fond of writing essays. Stop it. :-> >... > Please note, that only the ascii code is standardized, and that NONE > of the typographical parameters is standardized. Since the > typographical parameters are absolutely vital for the correct > rendition of any ascii pic, their non-standardization is a constant > source of debates, the most common of which is the proportional vs > non-proportional debate. Sorry Pete, but you're wrong, wrong, and wrong again. First: typographical parameters are NOT `absolutely vital for the correct rendition of any ascii pic'. The whole idea of ASCII art is that no matter which fixed-width font, color, line-spacing etc. you use, you will still be able to see the picture very nicely. Yes, this does require some care on the part of ASCII artists -- good ASCII artists know to use | instead of I and " instead of ~, for example, so that their pictures look equally good with all fixed-width fonts. But these matters are relatively trivial. Second: the non-standardization of typographical parameters is NOT `a constant source of debates'. I can't remember the last time I saw anybody debating which fixed-width font, or color, or line spacing, or whatever, everybody else should use. The reason is that noted above: ASCII art is supposed to be drawn to look good no matter which fixed-width font, size etc. are used. Third, the choice between proportional and `non-proportional' (as you call fixed-width) fonts is NOT a `debate'. ASCII art is art designed with the ASCII characters in a fixed-width font. People may draw any sort of character art with ASCII characters, but if they do not use a fixed-width font then it is not ASCII art in the commonly accepted sense of the term. >... > Another example is the default font face on aol, Arial, which allows > for the correct transmission of ascii pics WITHIN aol. But of course, > since Arial is a proportional font, ascii pics transmitted from aol > to the outside world (and vice versa) will be distorted. (I refer to > pics made from proportional and non-proportional fonts as ascii pics, > since both are based on ascii code, albeit with different > typographical conventions.) Yes, well see above for my disagreement with that definition. And on the subject of AOL, is AOL available for the Mac? If so, does it use the Arial font, or something else (such as Geneva) which is more common on Mac systems? If so, character art sent from a Windoze AOL user to a Mac AOL user (or vice versa) will be distorted. And what about the people with newer versions of AOL who can (I think) change the font to read their messages in ...? >... > Text editors built into email and newsgroup software are evolving > towards more sophistication, e.g. more and more are defaulting to > proportional font. This evolution is good for general use, e.g. it > provides improved legibility (your own handwriting is proportional) > but it is devastating for ascii pics. > > Some time ago, Microsoft and working groups of the IETF (Internet > Engineering Task Force) have therefore published recommendedations > against the use of ascii pics on the Internet. Microsoft's recommendation, if you remember, resulted in derision from both Jorn Barger (the author of the original FAQ) and myself; do a DejaNews search of alt.ascii art for `Jorn Barger AND Microsoft AND FAQ AND technology', and see also http://cgi.pathfinder.com/netly/article/0,2334,13735,00.html. As for the IETF, only two IETF RFCs (2229 and 2295) mention ASCII art. Neither of them discourage its use: one suggests ASCII art as an acceptable method of providing images to Web browsers which cannot read GIFs or JPEGs, and the other refers to ASCII art in database files. Pete, please provide a citation for your claim that the IETF is discouraging ASCII art. > But what they (and the > ascii community) forget, is that it is EASY to protect ascii pics by > including the above typographical parameters as part and parcel of > the pics, say, in the form of html tags. This would also allow pics > generated within aol to be correctly viewed in the outside world and > vice versa ... Wrong, and wrong, Pete. Firstly, I've said it before, and I'll say it again: HTML is not a presentation language. It is a semantic markup language. Good luck trying to specify the font, color, and line spacing to someone on a monochrome monitor who doesn't have the particular font installed. Secondly, HTML is not acceptable in the majority of Usenet groups (I'm not just talking about a.a-a), so even if HTML was able to do the miraculous things you claim, it would be a non-issue for a.a-a. Pete, I love HTML even more than you seem to, but even I know what it can't do, and where it doesn't belong. Your attempts to provide a pseudo-academic foundation for the use of HTML tags in a.a-a (I can't think of any other reason why you write these `essays') will not work. ASCII art is a simple medium; learn to enjoy the simplicity, instead of pining for extensions to it. Regards -- .._o Matthew Thomas (mpt26 @ student . canterbury . ac . nz) ..://\/ http://cantua.canterbury.ac.nz/~mpt26/ (Site for sore eyes) ..:_/\ ASCII ART FAQ: http://cantua.canterbury.ac.nz/~mpt26/art/ascii/ ..:/ Linux. Because life is too short to reboot.
Pete Casso (pet...@sympatico.ca) wrote: [big snip] : Some time ago, Microsoft and working groups of the IETF (Internet Engineering : Task Force) have therefore published recommendedations against the use of : ascii pics on the Internet. But what they (and the ascii community) forget, is : that it is EASY to protect ascii pics by including the above typographical : parameters as part and parcel of the pics, say, in the form of html tags. This : would also allow pics generated within aol to be correctly viewed in the : outside world and vice versa ... Funny. I haven't heard of any such recommendation by the IETF, even though one could assume that such an event would've been noticed and discussed in this NG. If one does exist, I apologize for my ignorance, but I wonder if you might've meant the W3C (or was it the WDG, I forget) recommendation against using ascii art in web pages. If you did, you couldn't have put it more out of context, as the recommendation was specifically targeted against embedding ascii art in HTML, on the grounds that it is incompatible with non-textual user agents such as talking browsers, and there is currently no practical way of including an alternative representation for those. This is in fact a special case of the general rule of keeping style and layout information (which ascii art like all preformatted text is all about) outside HTML. And to avoid a pointless thread, I'd like to note that the recommendation was intended against using ascii art for navigation (such as <a href="../"><--</a>) or to present other information which should be accessible to everyone (including blind people), not against presenting ascii art for its own sake on the web. -- . _, .. j u s t. h o w l.i n g i n .t h e n.i g h t .. ._, . , )'' . /\_ . ' ,/\ . , ``( , _\__/ |__.'\._______,--;_'_`-.___,.______,/_,_`.__,-.__'__,/`-._,_| \____ ,_f_)\. Ilmari Karonen ilt...@sci.fi http://www.sci.fi/~iltzu/ /(_|_,.
Matthew Thomas wrote: > > > First: typographical parameters are NOT `absolutely vital for the > > > correct rendition of any ascii pic'. > > > > Wrong #1. Typographical parameters such as proportional or > > non-proportional font ARE absolutely vital for the correct rendition > > of any ascii pic. > > All you have done here is simply say `you are wrong', without giving any > reasons. I have given you all the reasons why you are wrong, but you fail to acknowledge those reasons. For example, in the above exchange, the reason given for making or breaking ascii pics are typographical parameters (proportional/non-proportional fonts) which is a clear rebuttal of your statement that typographical parameters are not needed for rendering ascii pics. > Here are mine (again): ASCII art assumes a fixed-width font, This assumption is exactly the fatal flaw at the root of your arguments: the ascii standard has no provision whatsoever for fixed-width or proportional font. Fixed width and proportional are in the realm of typography, outside of the ascii standard. For example, Arial and proportional are both ascii, just with different typography. > Pete, a debate requires a disagreement between two sides. People > wondering why they see garbage aren't disagreeing with anyone, they just > want to know how to set up their software. I was referring to the two sides clashing on this newsgroup here, proportional fonts vs. non-proportional fonts. A debate does not have to be between persons. > As I said, most of the regulars here would disagree (as does the FAQ, > but then I wrote it, so I suppose you'll argue that it doesn't really > count ...). And that's what's important. Ha ha, perhaps there is something called what's true, too! There are, BTW, the other FAQs too, from which you took those myopic notions! > Yes, HTML (<PRE></PRE> in particular) can be used to tell HTML-readers > not to mess with ASCII art. Ah, and this is perhaps a fist understanding that ascii is supported in a different medium than a .txt medium. In this case ascii is supported in a .html medium! Moreover ... ... the html medium has more potential than the .txt medium ... there are many other media with even more potential which support ascii ... and surprise, surprise, in spite of all the different media, that's all ascii art! > Note that the FONT tag, used to specify > typeface, color, and size, is `deprecated' in HTML 4.0. To explain in a > buzzword-free fashion, that means that the tag is on its way to becoming > obsolete in a few years. Don't worry about the details, better typographical tags will become available, the web design community will demand those! > Name one. Go on, I dare you to. Name a single font that is available on > all platforms. Perhaps then you'll get my point. Well, don't ask me for my word, ask a multi-platform professional for a better word. On top of those fonts, these professionals are also using font substitution maps for the other fonts. These maps are part and parcel of the files that they send to service bureaus and the like. I think, in the long run, these maps are a very good solution for ascii pics as well. (WHOOOOOAH, that's even further out than typographical tags!) > Yes, Pete, I am fighting for the future. In this case, I am unashamedly > a member of the anti-HTML-in-e-mail-or-Usenet brigade, because I > recognize the waste of time and bandwidth that HTML represents in these > media. I don't think you are fighting for the future at all, on the contrary, you are fighting to maintain the status quo. For example, you like ascii to live within the constraints of a .txt medium. Whereas I am pushing the envelope, for example, I like to use other media that support ascii. (FWIW, I have already left html behind me and moved on to better media) > If they are clearly observable, why are you wasting your (and our) time > stating them? Well, clearly observable with wide open eyes, that is. I am beginning to open some eyes, and that's good use of bandwidth! > > So the numbers are growing, and if more than half the people on the > > Internet use proportional fonts, then html tags will not only work, it > > becomes an absolute necessity for ascii pics to be correctly displayed > > to the majority of Internet users. > You seem to assume that all e-mail/Usenet software which uses > proportional fonts also recognizes HTML. Not so. I did not say that either. What I said is that html tags will become a necessity in an increasingly proportional world (to correctly display ascii pics.) But indeed (and perhaps to your dismay) more and more email and newsgroup software will progress and will be html aware. > ... Well, Pete, on the subject of whether or not `art form' and `medium' > mean much the same thing, either Webster's dictionary is right, or you > are. I'm siding with Webster on this one. Well, you are just quoting generic definitions from a dictionary. You did not even make an attempt to apply those generic definitions to ascii specifically. Whereas I did apply the words artform and medium to ascii specifically, and using my pathologically enlarge ego ;-)) I can even point to my website where I have shown how the ascii artform can be practised in a variety of media! ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> Yes, HTML (<PRE></PRE> in particular) can be used to tell HTML-readers > not to mess with ASCII art. Note that the FONT tag, used to specify > typeface, color, and size, is `deprecated' in HTML 4.0. To explain in a > buzzword-free fashion, that means that the tag is on its way to becoming > obsolete in a few years. Curious..as I don't know much beyond HTML 1.0 or so -- what are they intending to replace the FONT specification with? All these years using Lynx has got me a little 'behind' :-) > > Haha, this is like expecting color prints from a black and white > > printer! Of course, one does not have to be that stupid! Use a font > > that is available on all platforms, that's a little bit smarter! (To Pete Casso here) Watch it Pete - I've seen a B&W printer reproduce very nice color images (in color of course).. separate color-specific ribbons are useful for that ;-) > Yes, Pete, I am fighting for the future. In this case, I am unashamedly > a member of the anti-HTML-in-e-mail-or-Usenet brigade, because I > recognize the waste of time and bandwidth that HTML represents in these > media. I also dislike the use of HTML for EMail and News - It would, however, be nice if there were some sort of standard to specify things such as color, underline, and other attributes, that works in all Email and News. Alas, there isn't, so this debate will probably continue to eternity :-/ > ... Well, Pete, on the subject of whether or not `art form' and `medium' > mean much the same thing, either Webster's dictionary is right, or you > are. I'm siding with Webster on this one. I've always had it figured that ASCII art is only ASCII art when it exists as a text file with only 7 or 8-bit characters (from a standard character set like ISO 8859-1). It becomes an image when it's converted to GIF or another graphic format. (IOW, I disagree with Pete here :-) -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pete Casso wrote: >... > Why should I stop writing essays? The FAQs are essays too! Perhaps we > should stop posting the FAQs then! :-) The FAQ is not an essay, but a set of individual answers to frequently asked questions. An essay would not work nearly so well for this purpose, because even fewer people would bother to read it. > > First: typographical parameters are NOT `absolutely vital for the > > correct rendition of any ascii pic'. > > Wrong #1. Typographical parameters such as proportional or > non-proportional font ARE absolutely vital for the correct rendition > of any ascii pic. All you have done here is simply say `you are wrong', without giving any reasons. Here are mine (again): ASCII art assumes a fixed-width font, just as films assume that their audience can see. Anything else (particular fixed-width typeface chosen, size, color, line spacing) is completely up to the viewer, and should make hardly any difference to their enjoyment of the picture. > > Second: the non-standardization of typographical parameters is NOT > > `a constant source of debates'. > > Wrong #2. Just look at the guests dropping by here on this newsgroup > wondering why they see garbage instead of pics. Pete, a debate requires a disagreement between two sides. People wondering why they see garbage aren't disagreeing with anyone, they just want to know how to set up their software. > > Third, the choice between proportional and `non-proportional' (as > > you call fixed-width) fonts is NOT a `debate'. > > Wrong #3. Both are ascii art, since they are both based on ascii code, > just different typographical convention. > > > Yes, well see above for my disagreement with that definition. > > Answered in the above, both are ascii art. As I said, most of the regulars here would disagree (as does the FAQ, but then I wrote it, so I suppose you'll argue that it doesn't really count ...). And that's what's important. >... > > Wrong, and wrong, Pete. Firstly, I've said it before, and I'll say > > it again: HTML is not a presentation language. It is a semantic > > markup language. > > Well, I think I am right and right again :-) html tags can be used to > convey info on how display ascii pics and they do so with less > reliance on text editors having the right typographical defaults (see, > I can say things without using buzzwords :-)) Yes, HTML (<PRE></PRE> in particular) can be used to tell HTML-readers not to mess with ASCII art. Note that the FONT tag, used to specify typeface, color, and size, is `deprecated' in HTML 4.0. To explain in a buzzword-free fashion, that means that the tag is on its way to becoming obsolete in a few years. > > Good luck trying to specify the font, color, and line spacing > > to someone on a monochrome monitor who doesn't have the particular > > font installed. > > Haha, this is like expecting color prints from a black and white > printer! Of course, one does not have to be that stupid! Use a font > that is available on all platforms, that's a little bit smarter! Name one. Go on, I dare you to. Name a single font that is available on all platforms. Perhaps then you'll get my point. > > Secondly, HTML is not acceptable in the majority of Usenet > > I have explicitely stated "a few words on the future" > ^^^^^^ Yes, Pete, I am fighting for the future. In this case, I am unashamedly a member of the anti-HTML-in-e-mail-or-Usenet brigade, because I recognize the waste of time and bandwidth that HTML represents in these media. >... > I am not attempting to provide a pseudo-academic anything, I am merely > stating clearly observable trends. If they are clearly observable, why are you wasting your (and our) time stating them? > So the numbers are growing, and if more than half the people on the > Internet use proportional fonts, then html tags will not only work, it > becomes an absolute necessity for ascii pics to be correctly displayed > to the majority of Internet users. You seem to assume that all e-mail/Usenet software which uses proportional fonts also recognizes HTML. Not so. >... > > ASCII art is a simple medium; > > Hah, that is a failure to differentiate between artform and medium! art form (n.) 1: a recognized form (as a symphony) or ***medium*** (as sculpture) of artistic expression. 2: an unconventional form or ***medium*** in which impulses regarded as artistic may be expressed. [1868] ... Well, Pete, on the subject of whether or not `art form' and `medium' mean much the same thing, either Webster's dictionary is right, or you are. I'm siding with Webster on this one. Bye -- .._o Matthew Thomas (mpt26 @ student . canterbury . ac . nz) ..://\/ http://cantua.canterbury.ac.nz/~mpt26/ (Site for sore eyes) ..:_/\ <-- If this looks a mess, change your font to Courier ..:/ Linux. Because life is too short to reboot.
> : underline, and other attributes, that works in all Email and News. Alas, > : there isn't, so this debate will probably continue to eternity :-/ > > Can anybody say "ANSI"? Ansi-364 has been the > standard (or VT-100) for remote terminal, communications, Well, first of all the standard is called ANSI X3.64. It is not part of VT100 as such, rather VT100 contains many of the same ANSI codes. ANSI is thus a subset of VT100. As to the use of ANSI, some might argue that ANSI codes are just as bandwidth-hogging as HTML codes. Not to mention that not all terminals can accept ANSI codes (mine can, fortunately). None of the newsreaders or Email programs I've come into contact with will display ANSI; most will display the codes as a series of caret-characters, like " ^[[0m " for the code that switches to the user's default color settings. The old Commodore systems had a nice way of setting color, underline, and so on - they used single-character control codes (such as ^E for White). Of course those codes mean something entirely different on other computers. There's also the chance of an ANSI bomb, which can do simple stuff like redefining your keyboard, or more complex stuff like executing commands to your Shell (I've heard of this happening in the BBS world in the past). Either way, I'm content to leave ASCII the way it is, even though colors and such would be nice. Of course, I don't advocate things such as varying fonts or sizes, just attributes that affect single characters instead of entire character sets (again, like colors, underline, flashing, and italics) > You can view them with the TYPE command in > DOS if you have ANSI.SYS installed in your CONFIG.SYS > file, or else you will need an ansi viewer, just ask. > If you only use windows, sorry I mentioned it. :-) These suggestions would be useful if I used DOS or Windows. I don't use either of these. I use BSDI (Unix), via a dial-upo shell account, which I communicate with using my Commodore 128. Perhaps sometime in the future a set of standards will be proposed, that include these attributes, but until then, I'll be content to remain with the mainstream and leave my ascii art as plain 7-bit B&W text. -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nate / DAC wrote: > I've always had it figured that ASCII art is only ASCII art when it exists > as a text file with only 7 or 8-bit characters (from a standard character > set like ISO 8859-1). It becomes an image when it's converted to GIF or > another graphic format. > (IOW, I disagree with Pete here :-) Actually, that's just an ascii pic in gif format, just like your variegated printout ;-)) which is an ascii pic on paper. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
Nate / DAC wrote: > > > Yes, HTML (<PRE></PRE> in particular) can be used to tell > > HTML-readers not to mess with ASCII art. Note that the FONT tag, > > used to specify typeface, color, and size, is `deprecated' in HTML > > 4.0. To explain in a buzzword-free fashion, that means that the tag > > is on its way to becoming obsolete in a few years. > > Curious..as I don't know much beyond HTML 1.0 or so -- HTML 1.0 doesn't have FONT anyway :-) > what are they > intending to replace the FONT specification with? Style sheets. It's part of the move to separate content and presentation, and bring HTML back to what it was originally intended for -- conveying information. Those who want flash page-specific presentation can provide one or more style sheets along with the page, to suggest different choices of fonts, colors etc. > All these years > using Lynx has got me a little 'behind' :-) There's a slogan which goes: `Lynx -- any other browser is for perverts'. :-) >... > I also dislike the use of HTML for EMail and News - It would, however, > be nice if there were some sort of standard to specify things such as > color, underline, and other attributes, that works in all Email and > News. Alas, there isn't, so this debate will probably continue to > eternity :-/ Well, you see, that's exactly what I disagree with. I don't think there should be a way to `specify things such as color, underline, and other attributes'. E-mail and Usenet is about sending ideas to other people. Fiddling around choosing fonts and colors will not help this. All it will do is waste the time of the sender, and annoy the recipient (because it's in a font/color other than the one that the recipient prefers). Of course having these abilities makes the software look flasher, which is why companies implement it, but in my experience something which looks flasher often works worse. I really should start posting fewer diatribes and more pictures :-) -- .._o Matthew Thomas (mpt26 @ student . canterbury . ac . nz) ..://\/ http://cantua.canterbury.ac.nz/~mpt26/ (Site for sore eyes) ..:_/\ ASCII ART FAQ: http://cantua.canterbury.ac.nz/~mpt26/art/ascii/ ..:/ Linux. Because life is too short to reboot.
Pete Casso (pet...@sympatico.ca) wrote: : course, one does not have to be that stupid! Use a font that is available : on all platforms, that's a little bit smarter! I just had to catch this one. I would really, really, like to see a font that comes with both Windows'95 and Amiga Workbench 1.3, not to mention the countless other platforms out there. (My newer Amiga, which has WB 3.0, does have a font called Courier, though its resemblance with the Windows font of the same name is another matter entirely..) The bottom line is, you can't. That's exactly the point in designing ascii art to be viewable in any fixed-width font. It's called portability. Sure, you can make ascii art that works only on some special font. The few people using the exact same font might even consider it good ascii art, at least until they try to share it with a friend. I'm not sure if we are using the same terms here. What you seem to call ascii art, I call text art, of which ascii art is a subclass. Either way, it seems to me that, using your terms, one cannot completely separate the artform from the medium, since the medium partially defines the artform. A virtual model of a sculpture is not a sculpture, since it lacks the limits imposed by real material. Similarly, a recording of a piece of music is not the same as a live performance. I do not say that either would be inferior to the original, but they are not the same. Ascii art is perhaps most closely related to mosaic works, and a similar distincition appears there; an oil painting of a mosaic is not a mosaic, though it may look like one. The reason some people go watch a play instead of seeing a movie - even though the latter can present the story identically, if desired, or possibly better that the former - is the limits (the stage) and the variability (live actors) imposed by the medium. These are not necessarily imperfections to overcome, but rather the very intrinsic characteristics of the medium that make the artform what it is. I could most likely present every ascii picture I make better by drawing it on paper. Even if the ascii version were "perfect", I could always reproduce it exactly. The reason for making any ascii art at all is the medium - the fact that ascii art can be represented as text and displayed in various fonts. The analogy is quite perfect in that the representation of an ascii artwork on the screen or on paper is related to the artwork itself just like a particular performance is related to the play itself. By transforming an ascii picture into a bitmap, or a play into a video recording, means removing some limitations and adding others - even exactness can be a limitation. And yes, I do see that with the right interpretation one could say that we both are right and saying the same things. Whether such an interpretation would be sensible is a different matter, as is whether we might also mean the same thing. I doubt it. -- __,,,------._ ,-/| `-. Ilmari Karonen (ilt...@sci.fi) ^ All opinions expressed /, '\, `. ,|"-;;.__ http://www.sci.fi/~iltzu/ | in this message are my / ' 4(_,-_,-"_,/.' `'--' ,------------------------' own. If you want me to "`-(_,-"" `-' (,' itz | make some for you too, you should pay for them!
Ilmari, you went from the specifics to the generics. Let me try to address the big picture first and then address the specifics. Definition: ascii art (in my view) is using ascii code to make pictures. PERIOD. Comment #1: One is free to use any of the myriads of media that support ascii, e.g. the .txt medium and a myriad others. I myself like to render ascii code in a variety of media and explore the capabilities of the various media, such as animation and inter-activity. And all that is ascii art, e.g. we have a newsgroup with the name alt.ascii-art.animation Comment #2: One is also free to use any typographical settings such as proportional and non-proportional font, e.g. Arial based pics are ascii art pieces with this specific typographical setting (the Arial font.) (Please note in the above definition and comments, that there are NO reproductions.) (Please note in the above definition and comments, that different media have different capabilities.) Now, having said that, I realize that most people on this newsgroup tend to limit ascii art to just one medium, the .txt medium, and to just one typographical setting, the non-proportional font. It is for this reason, that I have said things like "the ascii community behaves in a self-limiting way" not because I want to insult the ascii community, but because the ascii standard itself allows for vastly greater freedom in the choice of media and in the choice of typographical settings. I also realize, why the ascii community is behaving in such a self-limiting way, and that reason is what you called portability. Let's try to guestimate the portability of the .txt/non-proportional combination. aol has about 10% of the Internet users, and another 10% of Internet users have proportional in their email and newsgroup software. That means that the portability of the .txt/non-proportional combination is a high 80%. Now, let's try to guestimate the portability of the .html/non-proportional combination. The portability here is determined by email and newsgroup software being html aware, say, a low 20%. (Of course one can argue about the exact percentages.) Since: => the world is becoming increasingly proportional; => the .txt/non-proportional combination offering no protection to ascii pics; => the .html/non-proportional combination do offer protection to ascii pics; the upshot is: => the high portability of the .txt/non-proportional combination will decline over time => the low portability of the .html/non-proportional combination will improve over time The cross-over point of the above two portability curves will happen probably not earlier than several years from now on, although the trends are quite clear. On the "universal font" issue itself, I am not an expert, as I said in a previous posting (and quite frankly, I don't think that you are an expert on this issue either.) But perhaps I can share the following little story and subsequent deliberations, and we can perhaps move the yardstick together. I have on my website little movies with captions, and naturally, I want the captions to be as legible as possible. The most legible font on each computing platform is probably the system font, since you as the computer user are the most familiar with it, you see it so often. Some of my newer movies in Java and Shockwave (the media that allow for inter-activity) therefore detect the computing platform that you are using, and display the captions in the system font that is native to your computer. (This is basically the same idea that multi-platform professionals use with their font substitution maps.) The key point that I want to convey with the above little story, is that "universal font" solutions do not have to be brute force "must have identical font installed in all systems in the whole wide world" kind of solutions. These solutions can be smart "use adequate fonts that you already have on your system" kind of solutions. These solutions can include non-proportional AND proportional fonts. Now, how portable are these solutions? Well, that's what I don't know, this is a new area and I won't even risk a guestimate. Anyone want to risk a guestimate? Since I have left the .html medium behind me, I am not really up to date on style sheets and other typographical tools for general usage. I do know that the web design community needs them for general usage and with maximum portability in mind, i.e. to reach the largest possible audience. In any case, the ascii community really only needs a rather small subset of those tools and can easily piggyback on the general development trends and use those tools as they become widely available. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> Ilmari, you went from the specifics to the generics. Let me try to address the > big picture first and then address the specifics. > > Definition: ascii art (in my view) is using ascii code to make pictures. > PERIOD. Then this immediately rules out forms such as GIF and other non-ASCII storage methods. These don't use the ASCII code set in any way or form. The only form that uses the ascii code set as defined by this newsgroup is a plain 7-bit black and white text file. HTML source files fall into this category as well (but the files often associated with an HTML file, such as pictures or animations, do not). But as we've already said a million times, not many newsreaders accept the HTML standard, and those that do may or may not display it properly. > Comment #1: One is free to use any of the myriads of media that support ascii, > e.g. the .txt medium and a myriad others. I myself like to render ascii code The .txt medium (defining .txt as a standard 7-bit file containing no control codes or formatting options)( is the only "true" ASCII format. All others are supersets of ASCII media - HTML and Javascript both could fall into this category. If you want a file to be portable and displayable on every platform out there, ASCII is the only way to do it without losing the quality of the image. GIF, JPG, and other such files are useless - a system with a monochrome monitor sure can't display some 16M color image.. Low end systems like the Spectrum or the C64 can't display GIFs at anything close to the original quality (tho the C64 still does a good job anyways). Try throwing a JPG file at anything less than a modern PC, and see where it gets you. HTML? Sure, if you can view it. My machine can't without logging into my shell account (and Lynx still isn't the world's best browser, but it's getting better). Javascript? HAH, again try throwing that at any computer that doesn't have Java capabilities (read, any computer that's mnore than a few years old). But throw an ASCII file at any platform you want, and it will be able to display the image, as long as that machine is using a standard ASCII set (or can programmed to display with one). That pretty much includes virtually every computer buildt from the old Altair to the most modern super computer. Of course we can't really worry about the scant few computers (less than 1/100 of 1% I am sure) that can neither display ASCII, nor display a bitmapped screen (to which an ASCII picture could be plotted to manually). What we're concerned with here is the 99.9999% of computers that use ASCII (or that can use it) as thier primary display/communication method. Like another person said, portability. > newsgroup with the name alt.ascii-art.animation And this newsgroup is alt.ascii-art, so your point is moot. > Comment #2: One is also free to use any typographical settings such as > proportional and non-proportional font, e.g. Arial based pics are ascii art > pieces with this specific typographical setting (the Arial font.) One is NOT free to use these. Why? Can my computer display this Arial font? Not while I'm online it sure can't. What about my mom's 486 SX/25? Try loading that with Windows 95 (which Arial is supplied with). It's bad enough on her P166. Or the Macintosh? Last I knew, Arial wasn't a font in use on that platform (I may be wrong). Amiga? don't recall seeing it there either. The only font that is common to all platforms is the fixed-spacing (non-porportional) default system font that is used on the system's startup text screen (DOS, in the case of a PC). Specifying the "default system font" doesn't take trickery - it takes a simple act of not specifying other fonts. ASCII art is for fixed-spaced ASCII-oriented fonts. Not for Arial or Helvetica. > (Please note in the above definition and comments, that different media have > different capabilities.) Which is why we use 7-bit, fixed spaced, monochrome ASCII art. This media has enough capabilkities to make it pleasurable to draw in, yet is so portable that you'd be hard pressed to find a system that can't display it. > community, but because the ascii standard itself allows for vastly greater > freedom in the choice of media and in the choice of typographical settings. The choice of typographical settings (like fonts) is specific to the computer platform one is running on. Like I said, a PC running Windows 95 is about the only thing that comes standard with the Arial font (to use your example). Furthermore, choosing a font for a particular part of a text file means someone has to use some form of code system (such as HTML) to specify that font. Uh oh...Now we can't just TYPE (or MORE or @T) the file to our screen! It's full of "garbage" codes! Now we have to load up some program (like an HTML view/browser) to see the file. > way, and that reason is what you called portability. Let's try to guestimate > the portability of the .txt/non-proportional combination. aol has about 10% of About 99%. It's as simple as that. You'd spend longer finding one platform that can't display ASCII than you will trying to convince us to use other media like HTML. Of course I know of one or two platforms that can't use ASCII, but thier use is so limited anyways, and thier online presence is nil, so this doesn't even matter (in the context of the use of this newsgroup). > Now, let's try to guestimate the portability of the .html/non-proportional > combination. The portability here is determined by email and newsgroup > software being html aware, say, a low 20%. The portability is not defined just by the software - it is also determines by the hardware capabilities of those machines that are expected to conform to standard other than ASCII. SOme machines just can't do it. Am I wrong to assume a VT100 terminal system (like Wyse or Xerox) is limited to strictly text? Aren't systems like these (as well as Unix and related operating systems) what defined the Internet in the first place? I would guess, however that a good 80% of the machines out there can deal with more than just ASCII. Most can display graphics of some sort, but where do we stop? 320x200 in 16 colors (the Commodore 64 for example)? 800x600 in 16 million colors (most modern PC's)? 1024x768 in 32-bit color (don't know of any examples offhand)? It stops when a significant portion of the users can (*or can't if you prefer) display the image or format you would propose. HTML isn't as widely used as ANSI X3.64 (and it certainly isn't as standardised), but can all platforms use these standards? No. Most can, but not all. All can display ASCII (at least, all platforms that have some method to connect to the internet or to a local ASCII-only BBS). > => the world is becoming increasingly proportional; Sadly, yes. > => the .txt/non-proportional combination offering no protection to ascii pics; > => the .html/non-proportional combination do offer protection to ascii pics; What do you mean by "protection" [of] an ascii pic? There's no need to "protect" a picture. You just specify that it is an ASCII picture, and 99.99999% of the users out there will know what to do with it, or at least, how do display it. At least 90% will know what kinda of characters to expect, and what screen size to assume (80x24 usually). Those 10% that don't know what to do with an ASCII picture probably aren't interested in ASCII art anyways. > => the high portability of the .txt/non-proportional combination will decline > over time The high portability will NEVER decline. Why? There's always going to be the need for a fixed-spacing font for one purpose or another. For example, it's needed for lists and tables, computer source code listings, and many other items not inherently related to this news group. All of these are much easier to read than if they are written/displayed in some porportional font. Would you want to pour through 150KB of assembly language source code that was printed in Dwinelle font? (Old english style writing) > => the low portability of the .html/non-proportional combination will improve > over time I have to agree with this, only because these types of tools are becoming more common. No argument there. > On the "universal font" issue itself, I am not an expert, as I said in a Universal font as defined by this newsgroup means the default fixed-spaced font that your system uses on startup (or at least, that it uses for things like text dumps, documentation files, and other unformatted text). Universal font doesn't mean Helvetica or TImes New Roman. It doesn't indicate a specific typeface. It indicates only the ASCII compatible (or modifyable) fixed-spaced font that is used when you are not running a graphical environment. Try getting Arial font to be used when you're running a DOS program! Unless you load the font with a program designed to modify the DOS font, you're not gonna see it. And even if you do, you're still gonna see a fixed-spaced screen. That's what defines ASCII art. > and Shockwave (the media that allow for inter-activity) therefore detect the > computing platform that you are using, and display the captions in the system Try detecting the platform I am running at this very moment! It's not too easy to find what platform you are running if you are dialed up through a shell account (many people I know use shells, probably a good 10% of the Internet community uses them on a daily basis, and another 10% probably have a shell available if they need it. By shell I mean a Unix command prompt on your internet provider, NOT a DOS shell on your computer). By the way, your "detect" idea would fail miserably here - I'm at my mom's house using her PC, telnetted into my shell account on a BSDI (Unix) system, yet this machine is running Windows 95, over a PPP dialup connection to my mom's provider. a pretty common scenerio, realy, for those of us who use a shell but sometimes use a computer away from home, that doesn't necessarily use a terminal program for modem communication (read: virtually every Windows-based PC in existance). > "universal font" solutions do not have to be brute force "must have identical > font installed in all systems in the whole wide world" kind of solutions. That's not what universal font means. That however, does exactly fit your idea of using some specific font such as Arial for ASCII artwork. If a person doesn't have that specific font installed, all they're gonna see is a screen full of garbage. Throw a standard ASCII picture (as defined in this newsgroup) at that person and they'll be wuite happy, knowing that thier system, like all computers, has a fixed-width font already installed. The same thing goes for using any other font besides fixed-width 7-bit ASCII. If the computer doesn't have it loaded, it just isn't going to look right. Hence, the portability of porportional spacing in terms of use in ASCII art is defined by the small percentage of computers that actually use the font in question. If I wanted to, I could probably draw up an ASCII picture using one of the fonts availble in Wheels 4.0. Not a single person on this newsgroup would be able to view it exactly as I drew it, unless said used happens to be running Wheels 4.0 (or any version of GEOS). > These solutions can be smart "use adequate fonts that you already have on your > system" kind of solutions. These solutions can include non-proportional AND > proportional fonts. The issue isn't what specific types of fonts one has - the issue is the fact that a fixed-width font is the same across all platforms - every charaacter takes the same amount of space in the character set, regardless of what that character set it, and regardless of what platform the person is using. When you start going into porportional fonts, you begin to rely on the user to already have some specific font installed (whatever font the picture is designed to be displayed in). But, when you speak of fixed-spacing fonts, the user already has one. It doesn't have a name, nor a number - it is just there. In DOS, for example, that font is the one you are looking at throughout your DOS session. In a Unix shell, the font is whatever your systemn uses for fixed-width display, and that system may be a dial-up terminal, oir the very machine running the Unix OS. On any platform that does not default to a GUI on startup, that font is what the user is staring at when they type thier first command. > Now, how portable are these solutions? Well, that's what I don't know, this is > a new area and I won't even risk a guestimate. Anyone want to risk a guestimate? At this stage, your estimate has to be based on the following criteria: * How many people use the OS you are using? * How many people have the specific font you are drawing your artwork in? * How many people have that font set as thier default? * How many people want to constantly switch fonts around when viewing different user' artwork? * What encoding or markup scheme do you propose to use to specify fonts within an ASCII drawing? * How many people can use this sceheme (i.e. how many have viewers)? * How many people have the necessary hardware and/or software to support some new encoding method? (I mention the use of " markup scheme " for the purpose that HTMl is not allowed in this newsgroup, it's been ruled out. So now, you've got to come up with a new method. HTML is *NOT* an option here, PERIOD.) > style sheets and other typographical tools for general usage. I do know that > the web design community needs them for general usage and with maximum > portability in mind, i.e. to reach the largest possible audience. Hrm... Ok if you think you're so smart... Go grab a copy of Lynx (or turn off all graphics and movies in your current browser so that it's text only). Now, go view http://www.jensenaudio.com This site is one I needed to look through yesterday, trying to find specifications on a car audio amplifier. Know what I found? Mounds and mounds of [LINK], [IMAGE] and, [INLINE]. Very little text. This is reaching the widest possible audience???? Seems to me that a company like Jensen would be concerned about this, yet the tools you speak of are most likely what is responsible for this site (among the many thousands of similar examples) being almost totally graphical. > In any case, the ascii community really only needs a rather small subset of > those tools and can easily piggyback on the general development trends and use > those tools as they become widely available. The ASCII community only needs three things: A program to edit ASCII pictures (*note pad does nice for some, Pico and Pine work well for me) A program to display the ASCII pictures on screen (your newsreader and Email programs of course) A fixed spaced font (every computer ever built has one, even if it has to be rendered on a printer rather than a CRT display) -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi Nate / DAC, On September 16 at 19:06 you wrote: > I also dislike the use of HTML for EMail and News - It would, however, be > nice if there were some sort of standard to specify things such as color, > underline, and other attributes, that works in all Email and News. Alas, > there isn't, so this debate will probably continue to eternity :-/ Actually, there is. On another medium called Fidonet it is quite common to use asteriks for bold *like this*, underscores for underlining _like this_ and slashes for italics /like this/. I don't think this causes too much annoyance to people who read it without a program that converts the asteriks for bold-style text. My newsreader is capable but then again, I'm using a superior Amiga newsreader ;-). Regards, Robert -- ___ _(ooo)_ Robert Kersbergen A winner never quits. ((((|)))) robert @ youyou . net A quitter never wins. / \
> > Definition: ascii art (in my view) is using ascii code to make pictures. > > PERIOD. > Then this immediately rules out forms such as GIF and other non-ASCII > storage methods. These don't use the ASCII code set in any way or form. That's not correct. Correct is that the ascii standard very wisely does not prescribe any media, and therefore, myriads of media are supporting ascii in the real world. Consider again the ascii pic printout, it is ascii art, because it uses ascii code to make the pic, although it has lost the ascii code. Similarly, an ascii pic contained in a gif file is ascii art since it uses ascii code to make the pic, although it has lost the ascii code. > The only form that uses the ascii code set as defined by this newsgroup is a > plain 7-bit black and white text file. That's exactly the reason why I said that the ascii community has a self-limiting behaviour. This is not to insult anyone, this is because the ascii standard itself allows you to use myriads more media, see the above. > HTML source files fall into this category as well (but the files often > associated with an HTML file, such as pictures or animations, do not). Well, if the pics are made with ascii code, then that's ascii art, no matter what media (html or otherwise.) If the pics are not made with ascii code, then that's not ascii art, no matter what media (html or otherwise.) If the animations are made with ascii code, then that's ascii art, no matter what media (html or otherwise.) If the animations are not made with ascii code, than that's not ascii art, no matter what media (html or otherwise.) > All others are supersets of ASCII media - HTML and Javascript both could > fall into this category. I would simply say that the ascii code can be used for making pics in the html and Javascript media and that you can therefore generate ascii art with these media. > If you want a file to be portable and displayable on every platform out > there, ASCII is the only way to do it without losing the quality of the > image. That is not correct either. The correct rendition of ascii pics depends heavily on typographical settings, even in such a simple medium as a .txt medium. For example, if the typography of a newsreader is set to proportional, then non-proportional based ascii pics will be damaged. I think that you are confusing two different things: 1. compatibility of ascii code with most computing platforms 2. correct rendering of ascii pics Compatibility of ascii code is high, close to 100%, no disagreement here. But the topic of this thread is something different, it is the correct rendering of ascii pics. And with regard to that, I guestimated the portability of ascii pics at 80% and declining, due to the world moving to proportional. > > newsgroup with the name alt.ascii-art.animation > And this newsgroup is alt.ascii-art, so your point is moot. You took the quote out of context. The context of the quote was an example that animation is ascii art, as long as ascii code is used for making it. Therefore, the quote is very well relevant. > > Comment #2: One is also free to use any typographical settings such as > > proportional and non-proportional font, e.g. Arial based pics are ascii art > > pieces with this specific typographical setting (the Arial font.) > One is NOT free to use these. That is not correct. Correct is, that the ascii standard itself allows for ANY typographical settings. The ascii standard has (very wisely again) refrained from prescribing any typography and myriads and myriads of typography in the real word therefore supports the ascii standard! What you then went on to say has to nothing to do with the ascii standard. What you are saying below has only to do with typography, which is outside of the ascii standard. > Why? Can my computer display this Arial font? Not while I'm online it sure > can't. <snip a lot of lamentation on *typography*> > Specifying the "default system font" doesn't take trickery - it takes a > simple act of not specifying other fonts. ASCII art is for fixed-spaced > ASCII-oriented fonts. Not for Arial or Helvetica. Ensuring that the system font is used in a multi-platform piece, does require a little trickery, i.e. you need inter-activity between the piece and the computer that it happens to run on, to determine and access the system font, that happens to be native on that particular computer. If you don't do this little trickery, then the typographical setting of the email or newsgroup (or any other) software will override the system font. > Furthermore, choosing a font for a particular part of a text file means > someone has to use some form of code system (such as HTML) to specify that > font. Uh oh...Now we can't just TYPE (or MORE or @T) the file to our > screen! It's full of "garbage" codes! > Now we have to load up some program (like an HTML view/browser) to see the > file. You have to load some kind of software anyway to look at the ascii pics on the newsgroup, and more and more newsgroup software is defaulting to html. Moreover, this is both challenge AND opportunity to make lemonade from those proportional lemons! (Can someone please draw proportional lemons and lemonade?) > I would guess, however that a good 80% of the machines out there can deal > with more than just ASCII. Most can display graphics of some sort, but > where do we stop? 320x200 in 16 colors (the Commodore 64 for example)? > 800x600 in 16 million colors (most modern PC's)? > > 1024x768 in 32-bit color (don't know of any examples offhand)? > > It stops when a significant portion of the users can (*or can't if you > prefer) display the image or format you would propose. HTML isn't as widely > used as ANSI X3.64 (and it certainly isn't as standardised), but can all > platforms use these standards? No. There is no stop as far as the ascii standard itself is concerned. Just use ascii code and you are free to use all the resolution and all the colors you want! > What do you mean by "protection" [of] an ascii pic? Wow! That is a central theme of this thread! Anyway, assuring the correct rendition of ascii code into an ascii pic, that's what I meant by protection of an ascii pic. For example, the .txt medium just uses its typographical setting, and if the setting is proportional, then garbage is displayed, that's what I meant with the .txt medium offering no protection for ascii pics. In contrast to that, the .html medium has typographical tags to ensure the correct rendering of the ascii code into ascii pics, and that's what I meant with the .html medium offering protection for ascii pics. > There's no need to "protect" a picture. You just specify that it is an > ASCII picture, and 99.99999% of the users out there will know what to do > with it, or at least, how do display it. There is increasingly a need to protect ascii pics in this increasingly proportional world. Just look at the many guests on this newsgroup wondering why they see garbage instead of pics. Many don't even know how to change their typographical setting even after receiving advice! > Those 10% that don't know what to do with an ASCII picture probably aren't > interested in ASCII art anyways. Well, we certainly turn off most of the 20% of the guests who see garbage and have problems fiddling with their typographical settings, just to read this newsgroup. They would have to pay a price too, you know, in foregoing the benefits of proportional font. The world is going proportional for a reason, i.e. for its benefits. For some of the guests, the price will be too high, which is, in principle at least, not necessary at all. > Universal font as defined by this newsgroup means the default fixed-spaced > font that your system uses on startup (or at least, that it uses for things > like text dumps, documentation files, and other unformatted text). > > Universal font doesn't mean Helvetica or TImes New Roman. It doesn't > indicate a specific typeface. It indicates only the ASCII compatible (or > modifyable) fixed-spaced font that is used when you are not running a > graphical environment. You took the above quote out of context. The universal font issue was to denote a font face which was availabe on all computing platforms and which also looks (near) identical on all computing platforms. The univeral font in that context did not refer to the non-proportional aspect only. > Try getting Arial font to be used when you're running a DOS program! Unless > you load the font with a program designed to modify the DOS font, you're not > gonna see it. And even if you do, you're still gonna see a fixed-spaced > screen. That's what defines ASCII art. Well, that's again like expecting color prints from a black and white printer! And you are lamenting on *typography* again! Typography (in DOS and elsewhere) does NOT define ascii art. What defines ascii art is the ascii standard which does NOT prescribe typography. Things are becoming repetitive, aren't they? > > and Shockwave (the media that allow for inter-activity) therefore detect the > > computing platform that you are using, and display the captions in the system > Try detecting the platform I am running at this very moment! It's not too > easy to find what platform you are running if you are dialed up through a > shell account (many people I know use shells, probably a good 10% of the > Internet community uses them on a daily basis, and another 10% probably have > a shell available if they need it. By shell I mean a Unix command prompt on > your internet provider, NOT a DOS shell on your computer). > > By the way, your "detect" idea would fail miserably here - I'm at my mom's > house using her PC, telnetted into my shell account on a BSDI (Unix) system, > yet this machine is running Windows 95, over a PPP dialup connection to my > mom's provider. > > a pretty common scenerio, realy, for those of us who use a shell but > sometimes use a computer away from home, that doesn't necessarily use a > terminal program for modem communication (read: virtually every > Windows-based PC in existance). These solutions do work. For example, the Java applet is downloaded to the user's computer (even via multiple concatenated links,) the applet then runs on the user's computer to find suitable fonts on the user's computer that it then uses to display the ascii movies! I have tested these solutions before posting on my website, BTW. And FWIW, I have left the .html medium behind me, exactly because other media are so much more capable! > Throw a standard ASCII picture (as defined in this newsgroup) at that person > and they'll be wuite happy, knowing that thier system, like all computers, > has a fixed-width font already installed. Well, there will be about 80% happiness and 20% unhappiness, with the happiness is going down, see above. Decisive is not whether a fixed-width font is installed, but whether their email and newsgroup software have the correct typographical setting. If the typography is set to proportional, then having fixed-width font installed won't help, and that's where the 20% (and growing) unhappiness comes from. (Yep, things are becoming repetitive!) > But, when you speak of fixed-spacing fonts, the user already has one. It > doesn't have a name, nor a number - it is just there. In DOS, for example, > that font is the one you are looking at throughout your DOS session. The point is, that the "non-proportional only" solution works less and less well in an increasingly proportional world, the 20% unhappiness will increase. Look at the big picture, and you will see the following issues: * the issue that email and newsgroup software are increasingly defaulting to proportional, destroying ascii pics * most computer users do not change fonts * the issue that having a fixed width font installed in your system does not guarantee that your email and newsgroup software is going to use it, they may very well have a proportional setting for example * most computers now use a GUI that often correlate to proportional > At this stage, your estimate has to be based on the following criteria: > * How many people use the OS you are using? <snip list> > * How many people have the necessary hardware and/or software to support > some new encoding method? > (I mention the use of " markup scheme " for the purpose that HTMl is not > allowed in this newsgroup, it's been ruled out. So now, you've got to come > up with a new method. HTML is *NOT* an option here, PERIOD.) Well, again, it is utterly inconsequential how much you and me love or hate html, mainstream development will run its own course. But you missed my point altogether with the above list of criteria. The point that I made in my previous posting went far beyond html, comparable to the Java applet that displays the ascii pic on each individual computer in the best possible way, based on the what fonts the Java applet finds on your computer etc. > This is reaching the widest possible audience???? Seems to me that a > company like Jensen would be concerned about this, yet the tools you speak > of are most likely what is responsible for this site (among the many > thousands of similar examples) being almost totally graphical. Well, I am not responsible for other people doing bad web design. You can always do bad designs even with the best tools. Generally speaking, bad examples say nothing. > The ASCII community only needs three things: Self-limiting behaviour, better is: the ascii community has myriads of resources at its disposal > A program to edit ASCII pictures (*note pad does nice for some, Pico > and Pine work well for me) > > A program to display the ASCII pictures on screen (your newsreader and Email > programs of course) Self-limiting behaviour, better is: the ascii community has myriads of media at its disposal > A fixed spaced font (every computer ever built has one, even if it has to be > rendered on a printer rather than a CRT display) Self-limiting behaviour, better is: the ascii community has myriads of typography at its disposal But no worry, sooner or later everyone will understand! ;-)) ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> That's not correct. Correct is that the ascii standard very wisely does not > prescribe any media, and therefore, myriads of media are supporting ascii in > the real world. The ASCII standard prescribes only one media - displayable text that doesn't require some decoding process to be rendered (not counting, as I said, for machines that must render text to a bitmapped screen). > Consider again the ascii pic printout, it is ascii art, because it uses ascii > code to make the pic, although it has lost the ascii code. Similarly, an ascii > pic contained in a gif file is ascii art since it uses ascii code to make the > pic, although it has lost the ascii code. The printout is ASCII art, no argument there. The GIF is NOT ascii art. Why? Because it can no longer be manipulated as ASCII (the printout can't really be manipulated either, but that's because it is a physical media that you can hold in your hand). The GIF now must be manupulated as a graphic image, and now requires 20x the storage space. Sure it may look like ASCII art, but as soon as you change one pixel (if even to make some character fit it's intended use better), it is no longer ascii ART. This includes simple things like colorising the picture, editing individual pixels (except to remove blemishes that are not part of the picture), adding lines or borders aroun the image, cropping or rotating it, or distorting the image in any way. Perhaps it's still ASCII art before it's modified, but even if it is, let's see you write a convertor program that will render an exactly identical file to what the GIF was created from. I.e. take it from a text file, through the GIF format, and back to a text file. Chances are you can't. > > The only form that uses the ascii code set as defined by this newsgroup is a > > plain 7-bit black and white text file. > > That's exactly the reason why I said that the ascii community has a > self-limiting behaviour. This is not to insult anyone, this is because the > ascii standard itself allows you to use myriads more media, see the above. The ASCII standard doesn't allow for anything except some simple formatting codes (like linefeed or horizontal tab). You look in a standard ASCII chart (which can be found in most any programming manual) and show me the codes that allow you to specify a font, set the type-size, or change the color of the text. You can't, because these codes do not exist. The codes that do this stuff are a function of whatever browser/editor combination the artists happens to be using, be it a Commodore 64 color graphics editor like Screen Magic, a PC ANSI editor like TheDRAW, the Windows Notepad, or an HTML/Web designer program and browser. Each uses a custom set of codes to specify the various attributes that the format in question supports (except the Notepad, since it is designed primarily to deal with plain text). > Well, if the pics are made with ascii code, then that's ascii art, no matter > what media (html or otherwise.) Again, it's ASCII art until it's placed into a format that requires something more than a plain text viewer to render. If it contains any kind of formatting codes (like HTML tags, or cursor positioning commands), then * IT IS NOT ASCII ART, PERIOD. * > If the animations are made with ascii code, then that's ascii art, no matter > what media (html or otherwise.) They are ASCII art only as long as they can be viewed without any kind of conversion (other than translation to a machine's native code set, if needed). It is ASCII art in that sense as long as it can be translated back and forth between two code sets without ever losing a single character, and without altering the image in the slightest (aside from the fact that each computer uses a different font, tho they all have a fixed-spaced font available) > I would simply say that the ascii code can be used for making pics in > the html and Javascript media and that you can therefore generate ascii > art with these media. Right, ascii CODE can be used to make these pictures, but once they are imported into HTML or Java format, they are no longer ASCII art. They may look like it, but they are not. > That is not correct either. The correct rendition of ascii pics depends > heavily on typographical settings, even in such a simple medium as a .txt > medium. For example, if the typography of a newsreader is set to proportional, > then non-proportional based ascii pics will be damaged. The correct rendition of an ASCII art image (again, as defined by this newsgroup and the millions of people who have drawn standard ASCII artwork in the past), requires only one thing: * A fixed spaced font that contains all of the standard ASCII characters in thier standard order. OR * A way to view this artwork under the above single criteria > I think that you are confusing two different things: > > 1. compatibility of ascii code with most computing platforms > 2. correct rendering of ascii pics > > Compatibility of ascii code is high, close to 100%, no disagreement here. But > the topic of this thread is something different, it is the correct rendering > of ascii pics. And with regard to that, I guestimated the portability of ascii > pics at 80% and declining, due to the world moving to proportional. The portability is 100%. Why? Because as I said, every machine has a porportional font, and there will likely never be a point in time where fixed-spaced fonts become obsolete. They will always be around, and will always be needed for something. Like I made the example earlier, try pouring through 150KB of 6502 assembly source code (commented assembly mind you), or a huge BASIC or C program, in anything other than a fixed-space easy-to-read font. You won't get very far before declaring the document as not worth your time. > You took the quote out of context. The context of the quote was an example > that animation is ascii art, as long as ascii code is used for making it. > Therefore, the quote is very well relevant. Animation is only ASCII art if it doesn't require the user to load some special browser or launch some littlre Java applet or whatever to view the animation. The best examples are those we see here, when someone draws several images spaced a page or so apart. Those are ASCII art. All I have to do is page down to watch the animation. Maybe I have to adjust my screen size, but so what - I don't have to load some special viewer. Like I keep saying, ASCII art is only ASCII art if it uses ONLY standard ASCII codes without any formatting tags or special markup codes. The exception to that rule is when someone includes ASCII artwork into a web page via the <PRE> and </PRE> tags. The artwork itself hasn't been altered, it's simply been included with the appropriate formatting tag. Hence, that artwork is still ASCII art. But, when you start using tags and special codes to do things like adding colors, changing font sizes, or inserting special symbols, it is no longer ASCII art. It is the artform designated by the media you are using - HTML art or Java art might be good names, but not ASCII art. > That is not correct. Correct is, that the ascii standard itself allows for ANY > typographical settings. Then you show me the set of codes included in the standard ASCII code set that says to change a font to some specific setting, or to set the font size, or to change colors, or to set underlined, inverse video, or bold. You can't, cause they just aren't there. Thus, the "ASCII standard itself" doesn't allow for anything but the use of codes from 32 to 127. I stop here now, after realising I was wrong to assume codes above 127 were standardized - they certainly aren't (there are many "standards" in fact) > The ascii standard has (very wisely again) refrained from prescribing any > typography and myriads and myriads of typography in the real word therefore > supports the ascii standard! You are right to put it this way - any formatting method you want to suggest probably supports the ASCII standard. But the ASCII standard does not support any specific format other than the format for which is was originally designed - fixed-spaced type, as with a daisy-wheel printer or text mode screen display. This is the media for which ASCII was designed to operate. The fixed-spaced font displayed on a terminal screen or on paper. > Ensuring that the system font is used in a multi-platform piece, does require > a little trickery, i.e. you need inter-activity between the piece and the > computer that it happens to run on, to determine and access the system font, > that happens to be native on that particular computer. > If you don't do this little trickery, then the typographical setting of the > email or newsgroup (or any other) software will override the system font. You don't need interactivity at all. What you need is software that isses a code specifically ordering the browser to select the default system font. It should be the broswers job, not that of the page/cgi/java program, to find and use the default system font. That defaul font is of course, operating system specific - the person writing the application (Netscape for example) knows before he writes it what the default font is for any platform he writes for. If he doesn't, well he probably shouldn't be writing for that platform to begin with. > You have to load some kind of software anyway to look at the ascii pics on the > newsgroup, and more and more newsgroup software is defaulting to html. No, you have to load the software to view the newsgroup as a newsgroup, not specifically to view ASCII artwork. If I had to load software to view ASCII art specifically, that woul tend to mean I would have to switch applications every time an ASCII art picture comes onto my screen. Since I don't have to, and since the ASCII art form is already compatible with every newsreader on the planet (except for those stupid ones that like to alter incoming text inappropriately), it isn't needed. I just load my newsreader (Pine) and browse my newsgroups. I don't browse this newsgroup any different than I would comp.sys.cbm (except that I scroll down line by line to view the ASCII, whereas I just page down when reading text). > There is no stop as far as the ascii standard itself is concerned. Just > use ascii code and you are free to use all the resolution and all the > colors you want! Yes there is! ASCII does not support color. The stopping point, like I keep trying to tell you, is when you start altering that B&W 7-bit image to contain more information than what is directly supported by the 7-bit ASCII standard. In other words, color is not supported, because it requires markup tags or special codes to be included into the image. Attirbutes like underline and bold are the same way - they don't have some specific code in the ASCII standard. And as I said, they require you to deliberately load some program to view the altererd format. > For example, the .txt medium just uses its typographical setting, and if the > setting is proportional, then garbage is displayed, that's what I meant with > the .txt medium offering no protection for ascii pics. Okay, you are right in this aspect. However there's still a certain amount of protection involved. ASCII as designed for fixed-space displays. Even most idiots who draw ASCII art will assume that it is going to be displayed with a fixed space font, and most people also assume the viewer will be on an 80x24 display, or some similar size. In other words, the ASCII format's protection (as in the .txt medium) is the cooperation of the artist and the recipient, to get the idea across that the picture is to be displayed in a fixed-spaced font. > In contrast to that, the .html medium has typographical tags to ensure the > correct rendering of the ascii code into ascii pics, and that's what I meant > with the .html medium offering protection for ascii pics. It uses two tags - <PRE> and </PRE> -- so long as you are using those, your text is pretty much safe. Ever notice that by using those tags, even the latest browsers automatically use a fixed-space font? I wonder why? Hmm..... > There is increasingly a need to protect ascii pics in this increasingly > proportional world. Just look at the many guests on this newsgroup wondering > why they see garbage instead of pics. Many don't even know how to change their > typographical setting even after receiving advice! This is exactly why they see garbage - they either don't know how to change thier browser's settings, or don't care to. Or perhaps they never had a reason to before. Their setting is non-standard for this newsgroup. The ironic thing is, by changing the font to a fixed-spaced font, many will find it easier to read than a porportional font (I prefer fixed-spacing myself as well, except for the paper I wrote in school - in those cases a porportional font is used for a litle extra finesse). That's not to say that porportional fonts are bad for newsreading - they just aren't the standard to use here. > Well, we certainly turn off most of the 20% of the guests who see garbage and > have problems fiddling with their typographical settings, just to read this > newsgroup. No, we don't turn them off, we help them figure thier newsreader out. This isn't a matter of "it can't be done, sorry, go away". > benefits. For some of the guests, the price will be too high, which is, in > principle at least, not necessary at all. Name every benefit you can think of that a porportional font has over a fixed-spaced font (specific font faces like Arial or Helvetica do not apply here, we're talking about character spacing and size, not actual typefaces) I can think of only one - it looks more professional to used a porportional font versus a fixed-space (non-porportional) font for many things. Given that, like I said there are still reasons to use fixed-spaced fonts. Lists and tables are the most prominent ones, and of course ASCII art that can be viewed on even the oldest computer or display medium. > You took the above quote out of context. The universal font issue was to > denote a font face which was availabe on all computing platforms and which > also looks (near) identical on all computing platforms. The univeral font > in that context did not refer to the non-proportional aspect only. And in that context, such a thing does not exist, although fonts like Courier and Times Roman are similar across most platforms. There is no "universal font". That's why we draw with ASCII art - the viewer has the option to change the display to whatever fixed-spaced font he desires, without affecting the overall quality of the ASCII image. The exception to that rule of course, is when the font chosen disobeys some of the basic conventions of a font, such as the underscore character _ should appear lower in the character field than a period ._._._. But, when you start going after porportional fonts, you start restricting the user to requiring the exact same font as the artist. That means no more deciding on a good font that is easy to read for text and that renders well for ASCII art. If the artist chooses Arial, the viewer must have the Arial font installed to view the image correctly. Use any other font, and at the very least the spacing is going to be wrong (because different fonts have different character widths and intercharacter spacings). Same thing goes for any other font like Times Roman or Helvetica. Each has a different look as well as a different set of character widths and a different amount of intercharacter spacing (whether you like it or not, the font can be set to have a specific amount of spacing added to the machine's "default" setting). Of course this is the reason why we have so many different fonts available to choose from on most platforms, some just look better than others. But, if the artist assumes a fixed-spaced font, then there is absolutely no question as to what the viewer must use - any fixed spaced font that renders standard characters according to the ASCII code set. > Well, that's again like expecting color prints from a black and white printer! > And you are lamenting on *typography* again! > > Typography (in DOS and elsewhere) does NOT define ascii art. What defines > ascii art is the ascii standard which does NOT prescribe typography. The ASCII art form prescribes one typography, as you put it - the fixed-spaced font. Plain and simple. There'S no setting for size - that doesn't matter. No settin for colors - that's not even supported in the ASCII standard. No intercharacter spacing adjustments - that's for porportional fonts, and even if you did it to a fixed-spaced font, it wouldn't make much of a difference (unless the user goes crazy with the settings of course). > Things are becoming repetitive, aren't they? Yes, the are - because you keep insisting that the ASCII standard - the 7-bit code set that includes control codes from 0-31 and characters from 32-127 - supports more than standard black and white fixed-spaced text. It's more along the lines that other formats (like HTML) support ASCII. GIFs support ASCII attachments. Java supports ASCII. Most word processors support ASCII (indeed, I suppose most are based around the ASCII standard). Terminal programs support ASCII. But ASCII doesn't inherently support any of these. ASCII by it's definition, supports only one thing - black and white, simple, plain, unaltered, no-formatting-codes, TEXT. The typographical setting for ascii is assumed to be fixed-spaced font of some form (such as Courier, or whatever typeface your computer uses before your GUI is launched). It is assumed to be this because this is what ASCII was originally displayed on (if perhaps designed specifically for display, on either a screen or on paper). > These solutions do work. For example, the Java applet is downloaded to the > user's computer (even via multiple concatenated links,) the applet then runs > on the user's computer to find suitable fonts on the user's computer that it > then uses to display the ascii movies! Perhaps so, but how am I going to automatically receive a Java applet over a link (a Unix system) which doesn't support the kind of auto-download crap that is used on the web in places. In other words, your Java applet is going to sit on it's origin computer because there is on function on the target computer that could make i all the way across to request that applet. Not to mention that the media involved (the telnet client) likely won't even support anything but Vt102 or ANSI. > Well, there will be about 80% happiness and 20% unhappiness, with the > happiness is going down, see above. Decisive is not whether a fixed-width font > is installed, but whether their email and newsgroup software have the correct > typographical setting. If the typography is set to proportional, then having > fixed-width font installed won't help, and that's where the 20% (and growing) > unhappiness comes from. But this can be corrected by doing simple things like reading the newsgroup FAQ (something I should have done before I made my first post here). As I recall, the FAQ clearly states that a fixed-spaced (or mono-spaced) font is the stadard font to use with ASCII art. > * the issue that email and newsgroup software are increasingly defaulting to > proportional, destroying ascii pics Show me one Email or Newsgroup program that defaults to a porportional font, that cannot be changed to use a non-porportional font. > * most computer users do not change fonts Because they are either too lazy, or don't know any better. If these people are too lazy to move a mouse around to select the correct font, or heaven forbid, download a more capable newsreader, then they probably don't need to be using this newsgroup. > * the issue that having a fixed width font installed in your system does not > guarantee that your email and newsgroup software is going to use it, they may > very well have a proportional setting for example And if they have any kind of setting, the likelyhood is damn near 100% that this setting can be altered. > * most computers now use a GUI that often correlate to proportional And your point is? > Well, again, it is utterly inconsequential how much you and me love or hate > html, mainstream development will run its own course. And will likely pass this newsgroup by if we have anything to say about it. > But you missed my point altogether with the above list of criteria. The point > that I made in my previous posting went far beyond html, comparable to the > Java applet that displays the ascii pic on each individual computer in the > best possible way, based on the what fonts the Java applet finds on your > computer etc. And like I said, what if the computer can't run that Java applet? Seems to be that's pretty damn difficult if I'm not running a browser that is Java capable. Not to mention I know of a few people who have already started doing things such as turning off Java, primarily because they find that it just makes browsing slower. In other words, you're proposing a standard that can't possibly work, because there are just too damn many platforms around that cannot (yet) run Java or Javascript. <snip list of self liminting crap> Sure we have all of these at our disposal. But you know why we don't use them? Because they are NOT standard. There are hundreds, if not thounsands of fonts (typefaces), but porportional and fixed-spaced. There are many kinds of encoding schemes for text data (with ASCII being the most popular of course; I could site a few old computers that used proprietary schemes) There are many ways to edit and display the data (either on a graphic screen or with custom fonts on a text screen, for example). There are so many possible combinations that it boggles the mind. And not a single way to specify any of these with the standard ASCII format. Hence, the ASCII format has to remain as it is defind here - 7-bit, black and white, fixed-spaced, text/art. Why? Because this is already an established standard; has been for longer than either of us have been alive, I'm sure. Can someone shed some light as to when the ASCII standard was proposed? > But no worry, sooner or later everyone will understand! ;-)) It isn't that I don't understand, it's just that I/we don't really care about standard and non-standard formats that defay the very thing we use here (7-bit ASCII). As a side note: Sorry to make so many mentions of my computer (Commodore), it just happens to fit many of the examples we're discussing here) -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pete Casso <pet...@sympatico.ca> wrote: >Matthew Thomas wrote: >> Pete, you are just too fond of writing essays. Stop it. :-> >Why should I stop writing essays? The FAQs are essays too! Perhaps we should >stop posting the FAQs then! :-) >> Sorry Pete, but you're wrong, wrong, and wrong again. >Well, I think I am right, right, and right again :-) And I think you are >wrong, wrong, and wrong again, see the three points below. Congratulations. Your logic is irrefutable and suggests that you might indeed be genetically related to Archimedes Plutonium who has claimed to be a reincarnation of the famous New Zealand racehorse, Pharlap. Perhaps Matthew Thomas can arrange for you to visit the University of Canterbury, NZ (at your own expense of course) to deliver a series of lectures based on your essays. I await the announcement of these lectures in the University of Canterbury Diary which is published monthly in the local newsgroup. During your visit it may be possible to arrange a Stein one evening at the Students Union as a social function where your theories can be discussed more freely and openly than in formal lectures. A few NZ Steinlagers are excellent for relaxing minds and encouraging the release of "Shafts of Wit". |\ /| ___| \,,/_/ ---__/ \/ \ __ _ __--/ (D) \ / ('>- _ -/ (_ \ \__/ // / \_ / ==\ __------- L\_ ___--/ / \_ O o) / / \==/ / / || ) \_/\ || / _ / | Kiwi rider on Pharlap | | /--______ ___\ /\ : the famous New Zealand | / __- - _/ ------ | | \ \ racehorse of the 1920's. ? | - - / | | \ ) | | - | | ) | | | | | | | | | | | | < | | | |_/ < | /__\ < \ after /__\ /___\ -Jurcy- ( Pharlap was a famous New Zealand racehorse. There was a postage stamp issued in commemoration. ) Bye,
> The ASCII standard prescribes only one media - displayable text that doesn't > require some decoding process to be rendered (not counting, as I said, for > machines that must render text to a bitmapped screen). Please provide a quote from the ascii standard prescribing this one medium, I don't see it. > The printout is ASCII art, no argument there. > > The GIF is NOT ascii art. Why? Because it can no longer be manipulated as > ASCII (the printout can't really be manipulated either, but that's because > it is a physical media that you can hold in your hand). The gif is also ascii art if it made with ascii code. If the gif is not made with ascii code, it is not ascii art. In other words , what classifies the gif is NOT whether it can be easily manipulated or not, what classifies the gif is whether ascii code is used or not, just like in the printout case. > Perhaps it's still ASCII art before it's modified, but even if it is, let's > see you write a convertor program that will render an exactly identical file > to what the GIF was created from. I.e. take it from a text file, through > the GIF format, and back to a text file. Chances are you can't. I think it is a simple matter to retrieve the ascii code from a gif by feeding it into a character recognition program, but that's not the point. The point is that the ascii standard does not prescribe any medium, let alone prescribe code retrieval from any specified medium. What you said about manipulation and code retrieval does not provide any basis for classifying pieces as ascii art or not, since it is outside the ascii standard altogether. If you disagree, please post quotes from the ascii standard on prescribed manipulation and code retrieval methods, I don't see them. > The ASCII standard doesn't allow for anything except some simple formatting > codes (like linefeed or horizontal tab). Please provide a quote from the ascii standard spelling out the prohibition, I don't see it. > You look in a standard ASCII chart (which can be found in most any > programming manual) and show me the codes that allow you to specify a font, > set the type-size, or change the color of the text. Font, type-size, color are typographical parameters outside the ascii standard. Non-inclusion of these typographical parameters do not constitute a prohibition. On the contrary, the ascii standard is supported by myriads of typography in the real world. > Again, it's ASCII art until it's placed into a format that requires > something more than a plain text viewer to render. If it contains any > kind of formatting codes (like HTML tags, or cursor positioning commands), > then * IT IS NOT ASCII ART, PERIOD. * By the same token, please prohibit ascii art websites to use the word ascii art. They violate your definition of ascii art by using html tags. I have (ironically) suggested that before, but not surprisingly, all of them still call their html enhanced pieces ascii art, and justifyably so. > > If the animations are made with ascii code, then that's ascii art, no matter > > what media (html or otherwise.) > > They are ASCII art only as long as they can be viewed without any kind of > conversion (other than translation to a machine's native code set, if > needed). > > It is ASCII art in that sense as long as it can be translated back and forth > between two code sets without ever losing a single character, and without > altering the image in the slightest (aside from the fact that each computer > uses a different font, tho they all have a fixed-spaced font available) Please provide a quote from the ascii standard stating the above viewing and translation requirements, I don't see them. > Right, ascii CODE can be used to make these pictures, but once they are > imported into HTML or Java format, they are no longer ASCII art. They may > look like it, but they are not. Please prohibit the naming our parallel newsgroup alt.ascii-art.animation I think the name is justified, for the same reason as in the above. > The correct rendition of an ASCII art image (again, as defined by this > newsgroup and the millions of people who have drawn standard ASCII artwork > in the past), requires only one thing: > > * A fixed spaced font that contains all of the standard ASCII characters in > thier standard order. > > OR > > * A way to view this artwork under the above single criteria 20% of newsreaders are set to proportional, damaging ascii pics. It is unrealistic to expect everyone of them to change to non-proportional, and over and above that, the trend goes the other way, i.e. the world goes to proportional. There are better solutions available, based on html and more advanced techniques (that will be become imminent only in several years to come or even later.) > > I think that you are confusing two different things: > > > > 1. compatibility of ascii code with most computing platforms > > 2. correct rendering of ascii pics > > > > Compatibility of ascii code is high, close to 100%, no disagreement here. But > > the topic of this thread is something different, it is the correct rendering > > of ascii pics. And with regard to that, I guestimated the portability of ascii > > pics at 80% and declining, due to the world moving to proportional. > > The portability is 100%. The portability is not 100%, but at around 80% and declining, because 20% of email and newsreader software is set to proportional and the trend is towards proportional. > Animation is only ASCII art if it doesn't require the user to load some > special browser or launch some littlre Java applet or whatever to view the > animation. > > The best examples are those we see here, when someone draws several images > spaced a page or so apart. Those are ASCII art. All I have to do is page > down to watch the animation. Maybe I have to adjust my screen size, but so > what - I don't have to load some special viewer. Why is it ascii art if your finger does the paging, and why is it all of a sudden not ascii art if the paging is automated? To me, both of them are ascii art, with or without automation. If the viewer is the stumbling block, please post a quote from the ascii standard prescribing some viewers and prohibiting others, I don't see any such words. > > The ascii standard has (very wisely again) refrained from prescribing any > > typography and myriads and myriads of typography in the real word therefore > > supports the ascii standard! > > You are right to put it this way - any formatting method you want to suggest > probably supports the ASCII standard. Aha! That's a key point that I want to get across! The ascii community has myriads of typography at its disposal! > > Ensuring that the system font is used in a multi-platform piece, does require > > a little trickery, i.e. you need inter-activity between the piece and the > > computer that it happens to run on, to determine and access the system font, > > that happens to be native on that particular computer. > > If you don't do this little trickery, then the typographical setting of the > > email or newsgroup (or any other) software will override the system font. > > You don't need interactivity at all. What you need is software that isses a > code specifically ordering the browser to select the default system font. > It should be the broswers job, not that of the page/cgi/java program, to > find and use the default system font. You do need the interactivity because that specific multi-platform piece may want to use a different font than what is specified in the settings of the browser software. > Since I don't have to, and since the ASCII art form is already compatible > with every newsreader on the planet (except for those stupid ones that like > to alter incoming text inappropriately), it isn't needed. I think you keep missing the message that about 20% of newsreaders see garbage instead of ascii art. > Their setting is non-standard for this newsgroup. The ironic thing is, by > changing the font to a fixed-spaced font, many will find it easier to read > than a porportional font (I prefer fixed-spacing myself as well, except for > the paper I wrote in school - in those cases a porportional font is used for > a litle extra finesse). > > That's not to say that porportional fonts are bad for newsreading - they > just aren't the standard to use here. Unfortunately, this newsgroup is not the center of the universe. On the contrary, the ascii community is pretty small. The onus is therefore upon us, and not the rest of the world, to make sure that ascii pics are rendered correctly in the many media that the rest of the world is using to view ascii pics (And we need to do so without asking the rest of the world to change their settings.) > No, we don't turn them off, we help them figure thier newsreader out. This > isn't a matter of "it can't be done, sorry, go away". We don't turn them off with those words, we turn them off because they can't get their settings right, even after receiving instructions, or they simply prefer proportional settings for the other stuff that they do. > Name every benefit you can think of that a porportional font has over a A discussion would not be productive. Reality is that the world is going proportional and there are good solutions for protecting ascii pics that we will need if the portability is going below 50%. > There is no "universal font". That has been spelled out too and the discussion was inconclusive because there was no multi-platform expert at hand. But I did suggest solutions, including solutions that will work with both proportional and non-proportional fonts, multi-platform ascii artwork that interactively chooses adequate fonts on the viewer's computer, etc. (I don't want to repeat the discussion.) > But, when you start going after porportional fonts, you start restricting > the user to requiring the exact same font as the artist. That means no more > deciding on a good font that is easy to read for text and that renders well > for ASCII art. Those are bad solutions, if you can call them solutions at all. There are better solutions available (I don't want to repeat the discussion.) > But, if the artist assumes a fixed-spaced font, then there is absolutely no > question as to what the viewer must use - any fixed spaced font that renders > standard characters according to the ASCII code set. That is a good solution that is slowly, but surely becoming a bad solution in an increasingly proportional world. If the portability of ascii pics has dropped to 50% (i.e. without asking 50% of the world to change their settings) then we need different (and good) solutions. (I don't want to repeat the discussion>) > The ASCII art form prescribes one typography, as you put it - the > fixed-spaced font. Plain and simple. Please provide a quote from the ascii standard showing this prescription, I don't see it. > It's more along the lines that other formats (like HTML) support ASCII. > GIFs support ASCII attachments. Java supports ASCII. Most word processors > support ASCII (indeed, I suppose most are based around the ASCII standard). > Terminal programs support ASCII. Aha, that's what I have been saying all along! The decisive point is that the ascii community has all of these media at its disposal and myriads more! (Saying that "ascii supports html" is different from "html supports ascii" is to me irrelevant play of words, decisive is that the ascii community has this medium (and a myriad others) at its disposal.) At this point, I wonder what is left to discuss? If you agree that a myriads of media support ascii, i.e. the ascii community has therefore a myriads of media at its disposal, then that's really a key point that I wanted to make. And if (see further above) you agree that a myriads of typography support ascii, i.e. the ascii community has a myriads of typography at its disposal, then that's really the other key point that I wanted to make. Oh well, the preceding discussions may still remain interesting! :-) ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> Your logic is irrefutable and suggests that you might indeed be Thank you for recognizing that I have indeed a point behind my eyes. > Perhaps Matthew Thomas can arrange for you to visit the University Thank you again, but I already had to decline a couple of Nobel prizes. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> Please provide a quote from the ascii standard prescribing this one medium, I > don't see it. There is no text I can quote - like many common-sense issues, the problem of proper formatting/use of ASCII is an assumed standard. In other words, virtually everyone who has worked with ASCII will agree with what I (and everyone else who has hesitated to command) am saying. > The gif is also ascii art if it made with ascii code. If the gif is not made > with ascii code, it is not ascii art. In other words , what classifies the gif > is NOT whether it can be easily manipulated or not, what classifies the gif is > whether ascii code is used or not, just like in the printout case. The problem is, the GIF is not made with ASCII code. Once it is in the form of a GIF, it no longer uses ascii code. It doesn't matter what the picture was originally created from (ASCII art, a scan from a digital camera, or a hand-painted image for example). > I think it is a simple matter to retrieve the ascii code from a gif by feeding > it into a character recognition program, but that's not the point. This could possibly be done, I didn't consider OCR as an option here. > The point is that the ascii standard does not prescribe any medium, let alone > prescribe code retrieval from any specified medium. How you retrieve or generate the ASCII code doesn't matter (it could be typed, received from some random-fractal generator, or whatever). As I said, ASCII assumes the criteria I mentioned several times, because of simple, common sense. It's an unwritten rule that ASCII art is supposed to be fixed-spaced monochrome 7-bit text in the form of a text file that can be displayed on virtually any computer or printer. You wouldn't send an image of some kind (regardless of it's format) to a friend if you knew he couldn't display it, would you? But you know that if it is ASCII (according to the criteria I mentioned), the receiver can easily view it no matter how little software they have. > What you said about manipulation and code retrieval does not provide any basis > for classifying pieces as ascii art or not, since it is outside the ascii > standard altogether. Exactly, as is the storage of an image as a GIF - it is outside the ASCII standard because the image is not stored as a stream of ASCII codes. It is stored as a bitmap. The part about paper versus another format is a little different, in that the image being printed is ascii art, even if the resultant printout can't be manipulated. The GI created from an ASCII file is not ASCII art, if only because it is an active storage medium that isn't even needed (you should have just sent the ASCII picture, not the GIF conversion of it). > If you disagree, please post quotes from the ascii standard on prescribed > manipulation and code retrieval methods, I don't see them. Like I said , they don't exist because this is an unwritten rule - an understood principle, upon which this newsgroup is based. > > The ASCII standard doesn't allow for anything except some simple formatting > > codes (like linefeed or horizontal tab). > > Please provide a quote from the ascii standard spelling out the prohibition, I > don't see it. Sure, if you want me to type up a copy of an ASCII chart. Here are the codes from 0 to 31, which define the ASCII control code set. Note that using these codes is of course not allowed in this newsgroup. From the manual to my Panasonic KX-P2123 printer (which has of course been retired): 0 Null 1-6 are undefined 7 = Bell 8 = Backspace 9 = Tab 10 = Line feed 11 = Vertical Tab 12 = Form Feed (Clear Screen) 13 = Carriage Return 14 = Shift-Out 15 = Shift-In 16 is undefined 17 = Device Control 1 (X-On) 18 = Device Control 2 19 = Device Control 3 (X-Off) 20 = Device Control 4 21-23 are undefined 24 = Cancel 25 = EM (?) 26 is undefined 27 = Escape 28-31 are undefined As far as I know, this is the standard code set. Some printers (including this one) can replace the undefined codes with a standardized set of symbols (from the IBM Character set). You'll find there are no codes in any standard ASCII chart (by standard I mean that it must follow the official ASCII standard to the letter) that can specify any of these, unless such codes are acted upon by a viewer program to mean something other than thier intended purpose. Perhaps someone can shed som light on those undefined codes above. If I am wrong, I'd appreciate seeing the full code set. > Font, type-size, color are typographical parameters outside the ascii > standard. Non-inclusion of these typographical parameters do not constitute a > prohibition. On the contrary, the ascii standard is supported by myriads of > typography in the real world. I didn't say the ASCII standard PROHIBITS the use of these options, I only said it doesn't directly support them! This newsgroup, however, does prohibit the use of the various typographical settings we've discussed, because they just are not very portable. > By the same token, please prohibit ascii art websites to use the word ascii > art. They violate your definition of ascii art by using html tags. No they don't - they display ASCII art pictures in thier entirety, unaltered. They are simply surrounded by <PRE></PRE> tags to force the user's browser to render the images as preformatted text. The data contained between those tags is usuall not altered in any way. The exception to that rule is the use of the < and > symbols - because these are used by a browser to trigger tags and such, one must replace these with special tags so that the browser knows the difference between an arbitary < or > symbol, and a <> pair that indicated a tag. When the image is rendered to the user's screen, it is still rendered in 7-bit, monochrome, fixed-spaced, ASCII, including the < and > symbols. The user could highlight the text and save it to a text file, displayable any time they choose to, and these special codes (which are < and > respectively) will not become part of the file. If it doesn't match those criteria after rendering, the image is not ASCII art by definition (because it probably contains one or more codes to cause some display change, making it fail the above criteria) > I have (ironically) suggested that before, but not surprisingly, all of them > still call their html enhanced pieces ascii art, and justifyably so. They probably call them ASCII art for lack of a better term. The term can be used loosely of course, but in this newsgroup it generally refers to the aforementioned criteria. > Please provide a quote from the ascii standard stating the above viewing and > translation requirements, I don't see them. Alright. Please provide me a quote from the ASCII standard stating that the above requirements do not matter. > Please prohibit the naming our parallel newsgroup alt.ascii-art.animation > I think the name is justified, for the same reason as in the above. Since I don't read that newsgroup, I can't suggest what criteria they follow. If my guess is right, they probably follow the above criteria - a series of drawings spaced far enough apart that one need only hit thier page-down key to watch the animation. > 20% of newsreaders are set to proportional, damaging ascii pics. It is > unrealistic to expect everyone of them to change to non-proportional, > and over and above that, the trend goes the other way, i.e. the world > goes to proportional. It is just as iunrealistic to expect everyone to conform to some porportional standard, when there simply IS NO STANDARD! But given that this newsgroup is intended for ASCII artwork drawn using the already established criteria (fixed-spaced 7-bit monochrome), whether those users want to change thier font is irrelevant. If they don't, they can't see the artwork correctly. But the point is, they can - everyone has a fixed spaced font of some kind, that can be used to view normal ASCII artwork. But not everyone can change thier browser/newsreader to use some special font designed to be the official font for Porportional ASCII art. That is, as soon as someone sets such a standard, someone else will immediately complain because thir computer can't use this special font. > There are better solutions available, based on html and more advanced > techniques (that will be become imminent only in several years to come > or even later.) Of course there are, but in this newsgroup, we are not interested in thise media, because they are not standard, and in many cases, those media may not even be able to be sent over the Usenet. You forget that much of the Usenet is still 7-bit only! Why do you think the recommendation to use UUENCODE or MIME exists, for sending something that contains characters outside the 32-127 range? Because many systems will munge the data, rendering the extended (8-bit or higher) image as garbage. And to do this, like I just said you have to use UUENCODE or MIME or some other similar format. That means converting your image for transmission, and converting it back at the other end for display. Not such a bad thing, but certainly not very convenient. > The portability is not 100%, but at around 80% and declining, because 20% of > email and newsreader software is set to proportional and the trend is towards proportional. The portability is 100%, period. Name one internet-capable computer that cannot display ASCII artwork using fixed-spaced font, as dictated by this newsgroup. Go ahead. Name just ONE. > Why is it ascii art if your finger does the paging, and why is it all of a > sudden not ascii art if the paging is automated? Because that automated paging requires some sort of code. It might be a series of ESCAPE codes, or it might just be a special string of characters in the image. But regardless of what kind of code specifies the frame size (the amount to page down from frame to frame), one still has to load a secondary program on top of thier newsreader to see this modified artwork. > If the viewer is the stumbling block, please post a quote from the ascii > standard prescribing some viewers and prohibiting others, I don't see > any such words. You keep asking me to do the impossible - the ASCII standard, like I said, is an assumed standard - a standard agreed upon by the vast majority of people out there, who have knowledge of the subject. The viewer is part of that assumed standard - one is not supposed to need to load some special program other than the operating system's default viewing method (the TYPE command in DOS, or the MORE command in Unix, for example). > Aha! That's a key point that I want to get across! The ascii community has > myriads of typography at its disposal! No, those myriads of typograyhave ASCII at thier disposal. You appear to be confusing which of the two (the various typographical settings/methods, versus the ASCII code structure and standard itself) is the base item and which is secondary. To most of us, ASCII is the base item. And the standard ASCII format doesn't support anything beyond the assumed standard of fixed-spaced 7-bit monochrome text and artwork. > I think you keep missing the message that about 20% of newsreaders see garbage > instead of ascii art. Because the user who keeps complaining about the garbage is either unaware of how to change the font, or is too damned lazy to change it. Name one newsreader that uses loadable fonts, that cannot use a fixed-spaced font. Not a single one. > Unfortunately, this newsgroup is not the center of the universe. On the No, but this newsgroup is the center of it's own world - that world which you enter by reading this newsgroup. > pics (And we need to do so without asking the rest of the world to change > their settings.) No we don't. The rest of the world needs to stop going crazy over pretty pictures and fancy fonts. And for that "small" part of the world interested in ASCII artwork, most of those people will be quite happy to (even temporarily) change thier normal font, to view standard artwork. > We don't turn them off with those words, we turn them off because they can't > get their settings right, even after receiving instructions, or they simply > prefer proportional settings for the other stuff that they do. If the user can't get thier settings right, then they need to find a newsreader they can more easily adapt to. If they prefer thier pretty little porportional font, tough. This newsgroup is supposed to be viewed with a fixed spaced font, and that's all there is to it. > Those are bad solutions, if you can call them solutions at all. There are > better solutions available (I don't want to repeat the discussion.) I suggest you repeat the "discussion" then - because I seem to have forgotten what the better solution is. The way I see it, the system you are proposing requires the user to have a computer which can load fonts for display on demand, without the user's intervention. Further, your proposal requires that the user's computer be capable of displaying these fonts with the *EXACT* same porportions as the font that has been chosen for the artwork. Finally, that proposal requires that the user's computer be capable of displaying a wide enough image to accommodate these fonts (if you're gonna go porportional you may as well go for a larger viewing area too, right?) That pretty much rules out all but the most modern computers - those that can run a GUI capable of using little applets or sub-programs to do all of the above tasks. Those same computers had sure as hell better be fast too, otherwise the user isn't going to be very happy wading through tons of messages at a pace slower than a snail. > That is a good solution that is slowly, but surely becoming a bad solution in > an increasingly proportional world. If the portability of ascii pics has > dropped to 50% (i.e. without asking 50% of the world to change their settings) > then we need different (and good) solutions. (I don't want to repeat the discussion>) You seem to have lost the definition of portability by this statement. According to the New American Webster Handy College Dictionary: portable, adj. capable of being carried; easily conveyed. Also, portative, adj. -- portability, n. In other words, portability means being able to move something (either it be an object or a piece of data) from one place to another without a great deal of effort. Editing, transmitting, receiving, and vewing an ASCII art picture using the widely accepted standard (of fixed space 7-bit monochrome text) is a no brainer. What can be easier than displaying plain text??? > (Saying that "ascii supports html" is different from "html supports ascii" is > to me irrelevant play of words, decisive is that the ascii community has this > medium (and a myriad others) at its disposal.) These are not plays on words. These are entirely different ideas. By saying "HTML Supports ASCII" you are saying this: "The HTML (Hyper Text Markup Language) format, which consists of markup tags, attached image files, and so on, can and does use the ASCII format as a basis for the language." Of course that statement is true in all respects. By saying "ASCII Supports HTML" you are saying: "The ASCII standard inherently supports the use of HTML - There are specific markup codes in the ASCII format which specify that an HTML document is contained within." Of course, the above statement is completely false. There isn't a single code in the ASCII standard that can specifically indicate an encoding format, unless said codes are redefined by an external viewer program. If you're going to mince words, you had better make sure you're conveying your ideas clearly. > If you agree that a myriads of media support ascii, i.e. the ascii community > has therefore a myriads of media at its disposal, then that's really a key > point that I wanted to make. I agree that myriads of media support ASCII. I do not agree that the ASCII community has these media at it's disposal, in such a broad range as you are indicating. > And if (see further above) you agree that a myriads of typography support > ascii, i.e. the ascii community has a myriads of typography at its disposal, > then that's really the other key point that I wanted to make. There is no typography setting of any kind (that I am aware of) that requires the data to be in ASCII format. In other words, typographical settings do not support ASCII. The phrase "typographical setting" only means a setting or condition set by the editor and viewer software, to enable such things as fonts, colors, and attibutes like bold or italics. Again, if you're going to throw words out in the open, you need to watch what you're saying. Various media support ASCII as well as typographical settings - a good example of course is HTML. That format supports the ASCII standard of course, and it lso supports the use of typographical setting commands (such as <FONT> and <SIZE> tags). Just because some medium supports one method or format, doesn't necessarily mean it supports another. To use another Commodore related example: The program Screen magic (as well as most any other related program) fully supports the use of the PETSCII (a derivitive of ASCII), as well as commands to change colors, display block graphics characters, and switch between the two system default fonts. Those are typographical settings. That program doesn't in any way, shape, or form, allow the use of the ASCII code set. On the other hand, this newsgroup is exactly the opposite: It supports ASCII in it's standard form. It does not support color changes or PETSCII (or any other non-standard code set), or the use of more than one font. This lack of support can mostly be blamed on the fact that many newsreaders weren't capable of anything more than 7-bit text, and that many systems still in use today will not pass more than a 7-bit stream (the 8th bit us either dropped or replaced with a parity bit, screwing up the original data). -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Both printout and gif show ascii art. You conceded that printout show ascii > art, but you try to deny that the gif show ascii art by tossing up alleged > prescriptions on medium, typography, storage methods, viewing methods, code > retrieval methods, etc., all prescriptions that the ascii standard simply does > not have! It would seem that you are now changing your story slightly. Instead of GIF actually BEING ASCII art, you now say it SHOWS ASCII art. With that statement, I agree. > You have already failed to provide a quote from the ascii standard on a > prescription on medium. I think you will fail too in providing quotes on the And you have failed to provide any quotes from this same standard for your side of this argument. > If you disagree, please provide the pertinent quotes. You seem to toss up more > and more alleged prescriptions as the discussion goes on. In case you want to Alleged? What I have been saying all along are the same set of statements, worded in a number of ways. Those are (for the record): The ASCII standard is, by nature of the original use and intent of display of text including ASCII artwork, a seven-bit code set describing a series of characters in the range of 32 to 127, and a series of control codes in the range of 0 to 31. ASCII artwork, as first created on university computers and mainfraimes (which were about all that existed back in the day), was meant to be displayed with a fixed-spaced font. In those days, there really wasn't much of a choice in fonts, since one simply had to live with whatever the default was on any given computer or printer. The ASCII standard does not contain a single code of any kind that was intended to change colors, set text size, change the typeface, or alter any other typographical setting being used by the application in question (that is, by the program being used to display the text and art). Programs such as Netscape use the HTML standard (among others), which requires altering the very meaning of certain characters in the ASCII set, for use by the media involved. In the case of HTML, that means redefining the meanings of the < and > characters so that they are used to indicate HTML tags. Special escape sequences are used to allow the browser to display an actual < or > symbol. > To me that's the decisive and ONLY criterion for ascii art. That is, if ascii > code is used, then that's ascii art. If ascii code is not used, then that's > not ascii art. This is why I keep saying that a GIF or other graphical image medium is no longer ASCII art. It is no longer using the ASCII code set in any shape or form. The question of the printout on paper can be solved simply by assuming what most people already agree on anyways - the printout is simply a hardcopy of the actual ASCII artwork. It is defined as ASCII art possibly because there really is no code system in use once the ink hits the paper (unless you want to dig into molecular theories and such). Of course, one can argue that the printout is not ASCII art, but that's not the issue here. Let's put one thing straight now, for the paper analogy: Regardless of the format that some piece of artwork exists in, once it becomes ink on paper (a hardcopy), it can no longer be referred to accurately as the media from which the picture originated. In other words a hardcopy of a GIF image is no longer a GIF. A hardcopy of an ASCII drawing probably isn't technically ASCII art either, but again that's not the issue. > > simple, common sense. It's an unwritten rule that ASCII art is supposed to > > I suggest you go by the ascii standard rather than by (your own) common sense > or unwritten rules. My friend, I am going by the standard. If I weren't, I'd be posting HTML, GIF, and other non-ASCII images and claiming them to be ASCII artwork. > There is about 80% easiness and declining. > > Try sending an ascii rose to your new found love at aol and she can't view it > correctly. That's 10% of the Internet. Another 10% comes from proportional > settings in the rest of the Internet. Well if it'S a one-liner, it won't matter anyways, the size of the rose will change a little, but that's about it. But, that first 10% of the internet, being AOL, is indeed a stumbling block. I've heard of a patch one can do that would allow the use of a custom font in the AOL newsreader, but I can't verify this. In other words, I won't argue for or against AOL since I don't have any experience in that area. That second 10%, those users with porportional fonts, is a matter of pure and simple laziness. That is, unless the user simply doesn't know how to change the font. But if they do, and they still complain, then it's a matter of laziness - too damned lazy to move a mouse around and click a few icons to change fonts. > And the stored pic is ascii art, because it is made with ascii code. The ascii > standard does not prescribe any storage methods, .txt and .gif and myriads > more storage methods are perfectly legitimite. The stored image is NOT made with ASCII code. It was created from ASCII code, yes. But it is no longer in the form of ASCII code. Like I said, don't mince words - just choose what you are tryin to say carefully to avoid potential grammatical or syntax mistakes. > You did not provide a quote on the prohibition, since the ascii standard > contains no such prohibition. What you provided is something else. What I provided was the control code set for the ASCII standard. The very set of codes in that list should speak for itself. If it does not, I suggest you grab a reference guide and do some reading. It's obvious you don't know the ASCII set. (I don't claim to be an expert, but I'm pretty confident that what I7ve written is accurate) > Ah, indeed, the ascii standard does not prohibit any of these options, and > they are supported by myriads and myriads and myriads of resources in the real > world! But remember - it is not the ASCII standard itself that dictates what typographical settings one can apply to the text they have created. That is a function of the word processor (or other editor) used to create the text or artwork. If it were a function of the ASCII format itself, then there would be no issue to argue about here - every word processor would support the exact same set of typographical settings, and every computer that uses the ASCII standard would have all of these fonts and settings available. > And of course, this newsgroup currently sticks with non-proportional, because > it still provides a high portability of 80%. Compared to using html for > example, then the portability is only 20%. One point in this discussion is The portability of ASCII over HTML is an entirely different discussion. Besides, since HTML is an extension of ASCII, the portability of HTML will more than likely follow the portability of ASCII. > So some time in the future (at least a few years from now on) there will be a > cross-over point, and from then on html has the higher portability. And so what if it does (which i won't because of the simple need for basic, ordinary plain text)? > > If it doesn't match those criteria after rendering, the image is not ASCII > > art by definition (because it probably contains one or more codes to cause > > some display change, making it fail the above criteria) > > Please provide a quote from the ascii standard spelling out those rendering > criteria, I don't see them. I did provide the closest thing to a quote, which you happily ignored and deleted (the list of ASCII control codes). That list spells out what ASCII is designed to do, and where it's limits were originally. > > > Please provide a quote from the ascii standard stating the above viewing and > > > translation requirements, I don't see them. > > > > Alright. Please provide me a quote from the ASCII standard stating that the > > above requirements do not matter. > > The burden of proof rests on you, not me. You alleged that the ascii standard > has viewing and translation requirements that are not there. No my friend, the burden of proof lies with YOU. You started this argument by insisting that any form of artwork created from an ASCII picture qualifies as ASCII art. You provide me a quote from any standard that has been around as long as ASCII art has (30 or more years?). > Well, the point was that you said that Javascript animations were not ascii > art. However, that's exactly the topic of that newsgroup and it has > nevertheless the words ascii art in its name. I think that the name is > justified because ascii code is used to make those animations. ASCII code is used to create the frames user in those animations, for sure. But assembling them into an animation goes beyond the definition of ASCII art, as there must be some way for the viewer program to know when one frame ends and another begins. > Ah, but I did not suggest that at all, on the contrary, I denoted solutions > like that "brute force" type of solutions, and that does not sound very > complimentary, does it? You also suggested that at some point, HTML will become the more portable standard right? So by that definition, you surely must include all aspects of HTML, right? Do those aspects of HTML not include FONT settings, color changes, and the like? So how is this going to become a solution, when not all computers will be able to meet the hardware or software requirements to display in this new standard? > If you start asking people to fiddle with their settings, you might as well > ask them to change to Arial, and then claim that aol pics have a portability > of 80% or so. I proposed using a non-porportional font. Every single computer ever built that has some method of text display has a non-porportional font. Relatively few computers have the Arial font, for example. > Whereas in reality (i.e. without making those changes) aol pics have a > portability of only 10% or so, i.e. limited to within aol only. So what? If the standard used on AOL is the Arial font, so be it. A person receiving that picture can change thier font accordingly if they are interested in seeing the artwork, just as the other 90% of the internet can change thier font settings to be compatible with the majority of ASCII artwork. > > You forget that much of the Usenet is still 7-bit only! Why do you think > > the recommendation to use UUENCODE or MIME exists, for sending something > > that contains characters outside the 32-127 range? > > I did not suggest any of those bandaid solutions, I did mention that more and > more email and newsgroup software are becoming html aware. More and more > people want to their email and newsgroup articles to look as webpages, I guess! Not the CLIENT software (the newsreaders and Email programs). I'm talking about the very guts of the internet. The SERVER software. I'm sure at least half of it (if not more) is still restricted to 7-bits only. > > The portability is 100%, period. Name one internet-capable computer that > > cannot display ASCII artwork using fixed-spaced font, as dictated by this > > newsgroup. Go ahead. Name just ONE. > > I think you try to deny that the world is now 20% proportional which limits > the portability to 80%. Just answer the damn question. Regardless of the how large the "porportional" population is, virtually every one of them can go non- porportional if the need arises (in other words, they can find some way to properly view this newsgroup and any other standard, fixed-spaced, 7-bit ASCII art. > And I call it a decisive issue, since the ascii art community is perhaps just > 1/1000 of 1% of the Internet. Therefore, it is this little community that has > the burden of finding good solutions, not the 20%. Ok, this little community tak say, 1/1000 of 1%. For the purposes of thos whole argument, that means we need to throw out the other 99.999 percent of the Internet. Something is a bit wrong with at least one of these numbers. (Considering that I am not the world's best mathematician, perhaps it would help if you provide some numerical answers, i.e. X number of people in the net, Y number using ASCII art, Z number being porportional-ready, etc) > And finding good solutions means to ensure that ascii pics are displayed > correctly in the email and newsgroup software that these 20% are using anyway, > without asking them to change settings, without asking them to change their > Internet software, etc. But you are asking them to change thier software by promoting standards that aren't fully adopted by the majority of the Internet community yet! "This page uses (such and such code) - You must have Netscape Navigator vx.xx or higher to see it properly" I can't say how many times I've seen that statement in a web page. Even the Web is asking people to upgrade thier software. Fortunately, that upgrade is of course compatible with the older formats and methods, but it still means upgrading and replacing older software. > > Because that automated paging requires some sort of code. It might be a > > series of ESCAPE codes, or it might just be a special string of characters > > in the image. > > Please provide a quote from the ascii standard prohibiting the addition of > codes, I don't see any. I already did, by providing a standard list of control codes. Some of them are undefined, which means a software program might be able to make use of them for some purpose (such as separating frames in an animation). But by assigning some definition to a code that is not defined by whatever standard committee originally drew up the ASCII standard, is going outside that standard. You wouldn't expect me to write some program that changes the meaning of some of the standard control characters, and claim it to follow the ASCII standard, would you? Hell no, I've redefined a few characters, and thus have gone outside the standard. Sure I'm using ASCII codes for the base of it all, but I'm changing thier meanings! > So, there is no viewing requirement in the ascii standard. > > (I do not want to deliberately exasperate you, but we do need to stick with > the actual ascii standard, not with an assumed ascii standard.) The assumed standard *IS* the actual standard. There's no way to actually prove this without contacting one or more members of the committee that drew up the ASCII standard, except to quote from one reference manual after another, those that have charts of the standard ASCII set. If I obtained a chart from International Business Machines describing the ASCII standard (sure they didn't invent it, but they sure as hell should know what the exact standard is), would you still argue that that chart is only the assumed standard and not the actual one? If not, they why dismiss the chart that I posted earlier? This chart is more than likely the same thing (perhaps it is a sub-set of the official ASCII code set). > OK, my friend, that's what I wanted to get across! Words matter less than the > message that the ascii community has those myriads of typography at their > disposal, see further below also. Words matter less than the message, as long as you are getting the message across. > > portable, adj. capable of being carried; easily conveyed. Also, portative, > > adj. -- portability, n. > > > > In other words, portability means being able to move something (either it be > > an object or a piece of data) from one place to another without a great deal > > of effort. > > How about zero effort? > > No settings to change, no nothing at all, and still having the ascii pic > correctly displayed, even in a 100% proportional world? I didn't say "effortlessly conveyed", I said "easily conveyed". Or more correctly, Webster said it. And having it work to where a 100% porportional world will still display ASCIi art no matter what the actual format, typographical settings, or code set in use are, will take a great deal of effort. 1) Someone has to propose an official standard that supports everything (Sorry, HTML still isn't the best out there, I can name a number of popular methods/formats that HTML doesn't support). 2) Someone has to write the ultimate program to display all of these media. 3) Someone has to publish or distribute this program or suite of programs. 4) The *ENTIRE* ASCII community (which I am sure is quite a lot larger than 0.001% as you seem to believe) must aquire and install this software. That fourth step is where you're going to lose a LOT of people - I'm sorry but regardless of what language you use or what software development tools you use, the resultant program simply will not be able to run on every platform that's out there. * What about those VAX machines? * How about college workstations and LAN systems? * What about the small (but significant) percentage of people who don't even use the same platform as those who write this monster program? * What about the simple and undeniable fact that people are stubborn and may very well refuse to "upgrade" to this new super program? * What about those users who don't have enough hardware (such as RAM and video display capabilities) to use this new program? These are all important questions, many of which will probably still be at issue when your "breakover" point is reached, regarding ASCII vs. HTML vs. Java. > > requires the data to be in ASCII format. In other words, typographical > > settings do not support ASCII. > > Now I copy and paste a quote from you from further above. > > > No, those myriads of typograyhave ASCII at thier disposal. > > Looks like play of words to me. Actually more of a tired person writing the wrong words at some point. The first quote above is the more accurate and intended one. > But again, decisive is that the ascii community has myriads of typography (and > media) at its disposal. Again, we do, but the point of the matter is the simple fact that not everyone can or will be able to use these typography and media. See my above list of questions regarding your porposal of being able to view ASCII in a 100% porportional world, with "zero effort" as you put it. Why don't you sit behind the keyboard of a computer that uses a real programming language (such as assembly), and write programs they way they were written back in the days when 64K was enough for anyone. That'S the only way such a "super" program will be able to make it, is by being written in such a way that it doesn't require hundreds of megs of RAM and HD space to do the simple job of converting and displaying various ASCII and other art formats. My guess is, you probably had in mind that someone would use C++ or VBASIC, or some sort of program-creating software (i.e. a dedicated development system), rather than an actual lower level programming language that doesn't hold your hand through every step of the process. -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|||||
|||( o|
|| > .--- I`m now going to stick my nose in with
| '-| ---' my views and my own direction on this arguement.
\___/
.----- On Tue, 15 Sep 1998 23:09:45 GMT, Pete Casso posted:
|Matthew Thomas wrote:
|> > > First: typographical parameters are NOT `absolutely vital for the
|> > > correct rendition of any ascii pic'.
|> >
|> > Wrong #1. Typographical parameters such as proportional or
|> > non-proportional font ARE absolutely vital for the correct rendition
|> > of any ascii pic.
|>
|> All you have done here is simply say `you are wrong', without giving any
|> reasons.
|
|I have given you all the reasons why you are wrong, but you fail to
|acknowledge those reasons.
|
|For example, in the above exchange, the reason given for making or breaking
|ascii pics are typographical parameters (proportional/non-proportional fonts)
|which is a clear rebuttal of your statement that typographical parameters are
|not needed for rendering ascii pics.
c
Pete has indirectly given reasons for his comments... he just didn`t say
'You are wrong BECAUSE blah blah blah....'
.-------------------------
|> Here are mine (again): ASCII art assumes a fixed-width font,
|
|This assumption is exactly the fatal flaw at the root of your arguments: the
|ascii standard has no provision whatsoever for fixed-width or proportional
|font.
|
|Fixed width and proportional are in the realm of typography, outside of the
|ascii standard. For example, Arial and proportional are both ascii, just with
|different typography.
'-------------------------
Pete is right. ASCII is simply a code that defines a standard number for
each displayable character on a screen. ASCII Art in this group assumes a
fixed-width font and I accept that *most* ascii art is in a
monospaced/fixed-width/non-proportional font however any picture formed from
ascii characters can be called 'ascii art' regardless of which font it`s
in... It just might not be viewable on any other system.
.-------------------------
|> Yes, HTML (<PRE></PRE> in particular) can be used to tell HTML-readers
|> not to mess with ASCII art.
|
|Ah, and this is perhaps a fist understanding that ascii is supported in a
|different medium than a .txt medium. In this case ascii is supported in a
|.html medium! Moreover ...
|
|... the html medium has more potential than the .txt medium
|... there are many other media with even more potential which support ascii
|
|... and surprise, surprise, in spite of all the different media,
| that's all ascii art!
'-------------------------
As long as it`s a picture formed from ascii characters, it`s ascii art... in
my opinion. Regardless of what format it is represented in.
.-------------------------
|> Note that the FONT tag, used to specify
|> typeface, color, and size, is `deprecated' in HTML 4.0. To explain in a
|> buzzword-free fashion, that means that the tag is on its way to becoming
|> obsolete in a few years.
|
|Don't worry about the details, better typographical tags will become
|available, the web design community will demand those!
'-------------------------
Stylesheets can do this nicely, and although it is difficult to specify a
font for all systems, you can choose those that are best on all systems and
on non-stylesheet browsers they`ll just use their own monospaced fonts.
PRE {
font-family: "Lucida Console", FixedSys, "Courier New",
Monaco, Courier, Terminal, monospaced;
font-height: 110%;
line-height: 100%;
font-style: normal;
font-weight: medium;
font-variant: normal;
text-decoration: none;
}
Nice snippet there... my nice long font list and other settings from my
ascii site at http://voices.vossnet.co.uk/a/atkins/ascii.htm.
.------------------------
|> Name one. Go on, I dare you to. Name a single font that is available on
|> all platforms. Perhaps then you'll get my point.
|
|Well, don't ask me for my word, ask a multi-platform professional for a better
|word. On top of those fonts, these professionals are also using font
|substitution maps for the other fonts. These maps are part and parcel of the
|files that they send to service bureaus and the like. I think, in the long
|run, these maps are a very good solution for ascii pics as well. (WHOOOOOAH,
|that's even further out than typographical tags!)
.------------------------
Well, there are a lot of systems that only have one font available. Courier,
however, is available on many systems and it looks very similar. (I`m not
saying it`s on every system)
Anyway, see above about using multiple fonts.
.------------------------
|> Yes, Pete, I am fighting for the future. In this case, I am unashamedly
|> a member of the anti-HTML-in-e-mail-or-Usenet brigade, because I
|> recognize the waste of time and bandwidth that HTML represents in these
|> media.
|
|I don't think you are fighting for the future at all, on the contrary, you are
|fighting to maintain the status quo. For example, you like ascii to live
|within the constraints of a .txt medium.
|
|Whereas I am pushing the envelope, for example, I like to use other media that
|support ascii.
|
|(FWIW, I have already left html behind me and moved on to better media)
'------------------------
I use HTML in Email when I know the recipient will recieve and display it
correctly, but I know there`s no point using it for newsgroups as there will
always be someone, somewhere who doesn`t have an HTML newsreader (like
me!)... and it`s a horrible waste of space on news servers which remove all
articles when the disk fills.
.------------------------
|> If they are clearly observable, why are you wasting your (and our) time
|> stating them?
|
|Well, clearly observable with wide open eyes, that is. I am beginning to open
|some eyes, and that's good use of bandwidth!
'------------------------
Er, yes! :o)
.------------------------
|> > So the numbers are growing, and if more than half the people on the
|> > Internet use proportional fonts, then html tags will not only work, it
|> > becomes an absolute necessity for ascii pics to be correctly displayed
|> > to the majority of Internet users.
|> You seem to assume that all e-mail/Usenet software which uses
|> proportional fonts also recognizes HTML. Not so.
|
|I did not say that either.
|
|What I said is that html tags will become a necessity in an increasingly
|proportional world (to correctly display ascii pics.)
|
|But indeed (and perhaps to your dismay) more and more email and newsgroup
|software will progress and will be html aware.
'------------------------
Sad, but true.
HTML and proportional fonts will gradually creep into most newsreaders -
especially since Outlook Express now comes with Win98 (I think ... ?) which
is what a lot of users will be seeing when they buy their 'first pc'.
.------------------------
|> ... Well, Pete, on the subject of whether or not `art form' and `medium'
|> mean much the same thing, either Webster's dictionary is right, or you
|> are. I'm siding with Webster on this one.
|
|Well, you are just quoting generic definitions from a dictionary. You did not
|even make an attempt to apply those generic definitions to ascii specifically.
|
|Whereas I did apply the words artform and medium to ascii specifically, and
|using my pathologically enlarge ego ;-)) I can even point to my website where
|I have shown how the ascii artform can be practised in a variety of media!
|
'-------------------------
Again, I`m not getting involved in this particular debate.
Bye,
Martin
<Insert disclaimer from some previous message! :o)>
|\/| _..__|_o._ /\_|_| o._ _ mart.atkins@--
| |(_|| |_|| | /--\|_|<|| |_> --bigfoot.com
.----- On Mon, 14 Sep 1998 21:14:29 -0400, sgt pinback posted: | |and just so there's some ascii art here can anybody id the artist on this |garfield? | | ##### | ####### #**#!!### | #**#!!!!## #****#!!!!# | #****###!!!# #*****#!!!!# | #*******#!!!# #******#!!!!# | #*********#!###!*!*!*#!!!!!# -- | #!*!*!*!*!*!#!##########!!!!# /_ | ###########!##!!!!!!!!!!#!!!# //__ | ###!!!!!!!!!!!#!!!!!!!!!!!!!#!!!####/// \ | \ ##!#!!!!!!!!!!!#!!!!!!!!!!!!!!!#!!!!!!!# | _\ ##!!#!!!!!!!!!!!#!!!!!!!!!!!######!!!!!!!*# | \\ ##!!#!!!!!!!!!!!!#!!!!####### #!!!!!!***# | ___\\#!!!###################***** #...!!*****# | / \#!!!.# ***** # *** #....*******# | #*....# *** # #.......*****# | #**.....## ***** ##........!!****# | #!........## *******#########......#...!!!!!*# | #!...........#######.*****...............#.#..!!!!**# | #*.....##.............#..#...............#...#.!!****# | #*....#.#............#....#............##......!*****# | #*.......##.......###......###........#.......!!!****# | #*.........#######......!!....########.......!!!!!***# | #!!!.................!!!!!!!!.............!!!*******# | #!!!!............!!!!!!!!!!!!!!!!!!!!!!!!!!!******# | #*******!!!!!!!!!!!!!!!!!!!!!!!!!!!!***!!!!*****# | #******!!!!!!!!!!!!!!!!!!!!!!!!!********!!****# | ##*****!!!!!!!!!!!!!!!!!!!!!#*************### | ##****!!!!!!!!!!!!!!!!!!!!!###******#### | ####!!!!!!!!!!!!!!!!!!!!!!!!######!# | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*# | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!***## | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!******# | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*******# | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*****# | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!**# | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!## | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*## | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!***# | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!####!!!!!!****## | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!###****##!!!!******## | #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!##**!!*****#!!!********# | #!!!!!!!!#!!!!!!!!!!!#!!!!!!!#***!!!!***!!!!**********# | #!!!!!!!!!!#!!!!!!!!!#!!!!!!!#****!!!!!*!!!!!!!!!!*****# | #!!!!!!!!!!!#!!!!!!!#!!!!!!!#*!!***!!!!!!!!!!!!!!!!!***# | #!!!!!!!!!!!!#!!!!!!#!!!!!!#*!!!!!*!!!!!!!!!!!!!!!*****# | #!!!!!!!!!!!!#!!!!!!#!!!!!#***!!!!!!!!!!!!!!!!!********# | #!!!!!!!!!!!!!#!!!!!!#!!!!!#****!!!!!!!!!!!!!!**********# | #!!!!!!!!!!!!!#!!!!!!#!!!!!#*****!!!!!!!!!!!!!!*********# | '----------------------- Looks like the Dutch Dude`s style... but don`t hold be to that. :o) A lot of TDD`s pics look stretched out vertically to me, but this one isn`t so perhaps it was someone else! |\/| _..__|_o._ /\_|_| o._ _ mart.atkins@-- | |(_|| |_|| | /--\|_|<|| |_> --bigfoot.com
> Instead of GIF actually BEING ASCII art, you now say it SHOWS ASCII art. > With that statement, I agree. Good, good, printout and gif are both showing ascii art and they are both ascii art. Without play of words, that's the same, i.e. printout and gif are/show ascii art. And that's what I have said all the time, no change on my part here. Otherwise, by the same token, you would have to say that "the printout shows ascii art, but it is not ascii art" which sounds pretty weird. Well, I certainly will use the terms "is" and "show" interchangably. > Alleged? What I have been saying all along are the same set of statements, > worded in a number of ways. > > Those are (for the record): <snip> You repeated your statements without being able to quote the actual standard. Where are those prescriptions on medium, code retrieval methods, etc? > The question of the printout on paper can be solved simply by assuming what > most people already agree on anyways - the printout is simply a hardcopy of > the actual ASCII artwork. Well, the printout is a hardcopy of the actual ascii artwork, the gif is a softcopy of the actual ascii artwork, what's the difference? Whether it is a hardcopy or a softcopy, that does not justify a different classification. That is, both hardcopy and softcopy are/show ascii art. > It is defined as ASCII art possibly because there > really is no code system in use once the ink hits the paper (unless you want > to dig into molecular theories and such). No need for such theorems, both hardcopy and softcopy are/show ascii art. > Let's put one thing straight now, for the paper analogy: Regardless of the > format that some piece of artwork exists in, once it becomes ink on paper (a > hardcopy), it can no longer be referred to accurately as the media from > which the picture originated. In other words a hardcopy of a GIF image is > no longer a GIF. A hardcopy of an ASCII drawing probably isn't technically > ASCII art either, but again that's not the issue. That's exactly the issue at hand here. I keep things simple and say that both hardcopy and softcopy are/show ascii art. If you want to change your mind and say that hardcopy is not/does not show ascii art, then that's a new direction in this discussion. > > > simple, common sense. It's an unwritten rule that ASCII art is supposed to > > I suggest you go by the ascii standard rather than by (your own) common sense > > or unwritten rules. > My friend, I am going by the standard. If I weren't, I'd be posting HTML, > GIF, and other non-ASCII images and claiming them to be ASCII artwork. Your response is out of context. The context of this exchange is that you wanted to go by simple, common sense and unwritten rules. I suggested that you stick with the actual ascii standard. > > There is about 80% easiness and declining. > > > > Try sending an ascii rose to your new found love at aol and she can't view it > > correctly. That's 10% of the Internet. Another 10% comes from proportional > > settings in the rest of the Internet. > > Well if it'S a one-liner, it won't matter anyways, the size of the rose will > change a little, but that's about it. We need to devise solutions not just for one-liners though, the majority of ascii pics is multi-line, e.g. there is only a few ascii roses, but there are many multi-line ascii roses. > But, that first 10% of the internet, being AOL, is indeed a stumbling block. > I've heard of a patch one can do that would allow the use of a custom font > in the AOL newsreader, but I can't verify this. > > In other words, I won't argue for or against AOL since I don't have any > experience in that area. > > That second 10%, those users with porportional fonts, is a matter of pure > and simple laziness. That is, unless the user simply doesn't know how to > change the font. But if they do, and they still complain, then it's a > matter of laziness - too damned lazy to move a mouse around and click a few > icons to change fonts. Those are brute force type of solutions, a better solution would be if the recipient spends zero effort and the ascii pic is nevertheless displayed correctly. > The stored image is NOT made with ASCII code. It was created from ASCII > code, yes. But it is no longer in the form of ASCII code. The printout stores the image not with ascii code either, and nevertheless, the printout is/shows ascii art (unless you want to change your mind.) > > You did not provide a quote on the prohibition, since the ascii standard > > contains no such prohibition. What you provided is something else. > > What I provided was the control code set for the ASCII standard. The very > set of codes in that list should speak for itself. If it does not, I > suggest you grab a reference guide and do some reading. It's obvious you > don't know the ASCII set. (I don't claim to be an expert, but I'm pretty > confident that what I7ve written is accurate) That exactly what I said, you provided something else (the code set) rather than a quote on the (non-existing) prohibitions. Thank you for the suggestion on doing some reading on ascii, I have done that a long time ago and I am now routinely using ascii codes to create ascii art in a variety of media. > The portability of ASCII over HTML is an entirely different discussion. > Besides, since HTML is an extension of ASCII, the portability of HTML will > more than likely follow the portability of ASCII. > > > So some time in the future (at least a few years from now on) there will be a > > cross-over point, and from then on html has the higher portability. > > And so what if it does (which i won't because of the simple need for basic, > ordinary plain text)? In the above exhange, you seem to miss the theme of this thread, which is about the correct rendition of ascii pics, and about the best solutions to achieve this objective, i.e. without requiring any effort on the side of the recipient. > > > If it doesn't match those criteria after rendering, the image is not ASCII > > > art by definition (because it probably contains one or more codes to cause > > > some display change, making it fail the above criteria) > > > > Please provide a quote from the ascii standard spelling out those rendering > > criteria, I don't see them. > > I did provide the closest thing to a quote, which you happily ignored and > deleted (the list of ASCII control codes). That list spells out what ASCII > is designed to do, and where it's limits were originally. I did not happily ignore your response, I disagreed with it. Let me try an analogy. You crank one of those old movies on celluloid tape by hand and you want to call it a movie. Now you add a little motor to move the celluloid tape automatically, and you don't want to call it a movie. I would call both arrangement movies, with or without automation. The context of the above was ascii pics being paged down manually or automatically. By the same token as in the above, I would call both arrangement ascii movies, with or without automation. > > > > Please provide a quote from the ascii standard stating the above viewing and > > > > translation requirements, I don't see them. > > > > > > Alright. Please provide me a quote from the ASCII standard stating that the > > > above requirements do not matter. > > > > The burden of proof rests on you, not me. You alleged that the ascii standard > > has viewing and translation requirements that are not there. > > No my friend, the burden of proof lies with YOU. You started this argument > by insisting that any form of artwork created from an ASCII picture > qualifies as ASCII art. In the above exchange, you suddenly sidestepped from a specific topic to a generic topic. Let me respond to the generic topic first and then respond to the specific topic. On the generic topic: If I had used paint I would call my work painting, since I use ascii code, I call my work ascii art, simple! On the specific topic: I can not post a quote that is not there. But if you say the quote is in the ascii standard, please post. (I think the paint analogy can be taken further. After making a painting, the paint will dry and become a quite different material than the liquid that came in a can, the liquid that you dipped your paintbrush in, etc. But even after the paint material has changed, the painting is still a painting! The same with ascii art. After making a piece of ascii art with ascii code, the ascii code may then change to something different but the ascii art is still ascii art!) > You provide me a quote from any standard that has been around as long as > ASCII art has (30 or more years?). Get a copy of the ascii standard from the ANSI archives (and see for yourself that the document contains very little, it basically contains only those tables that everyone already know about.) > ASCII code is used to create the frames user in those animations, for sure. > But assembling them into an animation goes beyond the definition of ASCII > art, as there must be some way for the viewer program to know when one frame > ends and another begins. And nevertheless, the newsgroup calls itself alt.ascii-art.animation > So how is this going to become a solution, when not all computers will be > able to meet the hardware or software requirements to display in this new > standard? See the portability curves in my previous posting. Those curves quantify my guestimates over time. > > If you start asking people to fiddle with their settings, you might as well > > ask them to change to Arial, and then claim that aol pics have a portability > > of 80% or so. > > I proposed using a non-porportional font. Every single computer ever built > that has some method of text display has a non-porportional font. Even if you use non-proportional font, only about 80% of the recipients will see the ascii pic correctly. Again, don't ask recipients for any special effort, i.e. no brute force solutions, please! > So what? If the standard used on AOL is the Arial font, so be it. A person > receiving that picture can change thier font accordingly if they are > interested in seeing the artwork, just as the other 90% of the internet can > change thier font settings to be compatible with the majority of ASCII > artwork. No brute force solutions, please! > Not the CLIENT software (the newsreaders and Email programs). I'm talking > about the very guts of the internet. The SERVER software. I'm sure at > least half of it (if not more) is still restricted to 7-bits only. Server software too is moving towards supporting html aware clients. This is a mainstream development for both server and clients that necessarily has to go hand in hand. > Just answer the damn question. Regardless of the how large the > "porportional" population is, virtually every one of them can go non- > porportional if the need arises (in other words, they can find some way to > properly view this newsgroup and any other standard, fixed-spaced, 7-bit > ASCII art. The answer to the damn question is: "It does not matter at all whether you can set to non-proportional. What matters is whether the settings are actually non-proportional." Again, no brute force solutions, please! > Something is a bit wrong with at least one of these numbers. (Considering > that I am not the world's best mathematician, perhaps it would help if you > provide some numerical answers, i.e. X number of people in the net, Y number > using ASCII art, Z number being porportional-ready, etc) Since we are all not the world's best mathematicians, let's take round numbers. There are 100 million people on the net. 10 million of them are on aol. 10 million have proportional settings (That is actual setting, not jut proportional- ready) 1,000 ascii artists in the ascii community who should be interested in recipients receiving undamaged pics, no matter what email and newsgroup software the recipient uses, and without asking recipients for extra effort for changing settings, etc And what I said was that it is the 1/1000 of 1% who need to approach the 20% rather than the other way around! > But you are asking them to change thier software by promoting standards that > aren't fully adopted by the majority of the Internet community yet! No, I did not ask for anything. What I have been saying are clearly observable trends, mainstream developments will run its own course. > I can't say how many times I've seen that statement in a web page. Even the > Web is asking people to upgrade thier software. Fortunately, that upgrade > is of course compatible with the older formats and methods, but it still > means upgrading and replacing older software. Yes, and those are clearly brute force too. The worst offenders in this case are web page designers who want to show off their capabilities on their homepages and in so doing, do themselves a big disservice. Very view web surfers have the patience to download a 200K page. And as a virtual storefront, such mammoth homepages are counter-productive in the sense that they chase potential customers away. But again, bad examples say nothing. (Although in this case, I couldn't resist commenting, since that is one of my pet peeves too!) > The assumed standard *IS* the actual standard. There's no way to actually > prove this without contacting one or more members of the committee that Get a copy of the ascii standard from the ANSI archives, and you will be amazed how very little it contains, and very wisely so. It contains none of the prohibitions, none of the prescriptions, none of the code retrieval requirements, and what have you, that I asked you to provide a quote for. It is exactly the fact that this common denominator is so small, that it became one of the most widely supported vehicles in the computer world. That is what you are referring to with 100% portability, etc. But those refer to the ascii code ONLY! Correct rendering of ascii pics is a different issue altogether! Things like proportional/non-proportional, which are in the realm of typography rather than ascii code, play decisive roles here! > > OK, my friend, that's what I wanted to get across! Words matter less than the > > message that the ascii community has those myriads of typography at their > > disposal, see further below also. > > Words matter less than the message, as long as you are getting the message > across. Well, I sure hope I got the message across in this case. > And having it work to where a 100% porportional world will still display > ASCIi art no matter what the actual format, typographical settings, or code > set in use are, will take a great deal of effort. <snip> > These are all important questions, many of which will probably still be at > issue when your "breakover" point is reached, regarding ASCII vs. HTML vs. > Java. <snip> > My guess is, you probably had in mind that someone would use C++ or VBASIC, > or some sort of program-creating software (i.e. a dedicated development > system), rather than an actual lower level programming language that doesn't > hold your hand through every step of the process. I agree with the identification of the issues. I disagree that it is the ascii community that has to address the issues. What will happen in all likelyhood anyway, is that mainstream developments will address the issues with general usage in mind. Mainstream developments will definitly NOT care the least about special usage such as ascii pics. What I basically said, was that the ascii community can piggyback in certain ways on mainstream solutions (and provided those portability curves of ascii pics in .txt, .html, .java media, plotted over time. And FWIW, I have posted many, many, lengthy, lengthy articles in the past as well on how to piggyback.) I don't give any of those "super" proposals the least chance for success. Pushing such proposals through mainstream for the sake of a special purpose will simply not work. Even the advanced idea of using applets for ascii art that I described in a previous posting is basically piggybacking on mainstream developments in Java. Well, so much some people in the ascii art community will bristle, only some form of piggybacking on mainstream developments will have realistic chances for success in the long run. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> > Please provide a quote from the ascii standard prescribing this one medium, I > > don't see it. > > There is no text I can quote - Therefore, the ascii standard does not prescribe any medium. > The problem is, the GIF is not made with ASCII code. > Once it is in the form of a GIF, it no longer uses ascii code. Both printout and gif show ascii art. You conceded that printout show ascii art, but you try to deny that the gif show ascii art by tossing up alleged prescriptions on medium, typography, storage methods, viewing methods, code retrieval methods, etc., all prescriptions that the ascii standard simply does not have! You have already failed to provide a quote from the ascii standard on a prescription on medium. I think you will fail too in providing quotes on the other alleged prescriptions. Then it is time to concede that the gif shows ascii art as well, just like the printout. If you disagree, please provide the pertinent quotes. You seem to toss up more and more alleged prescriptions as the discussion goes on. In case you want to add other alleged prescriptions, please provide the pertinent quote from the ascii standard on the additional alleged prescription. > It doesn't matter what the picture was originally created from (ASCII art, To me that's the decisive and ONLY criterion for ascii art. That is, if ascii code is used, then that's ascii art. If ascii code is not used, then that's not ascii art. > simple, common sense. It's an unwritten rule that ASCII art is supposed to I suggest you go by the ascii standard rather than by (your own) common sense or unwritten rules. > You wouldn't send an image of some kind (regardless of it's format) to a > friend if you knew he couldn't display it, would you? But you know that if > it is ASCII (according to the criteria I mentioned), the receiver can easily > view it no matter how little software they have. There is about 80% easiness and declining. Try sending an ascii rose to your new found love at aol and she can't view it correctly. That's 10% of the Internet. Another 10% comes from proportional settings in the rest of the Internet. > Exactly, as is the storage of an image as a GIF - it is outside the ASCII > standard because the image is not stored as a stream of ASCII codes. It is > stored as a bitmap. And the stored pic is ascii art, because it is made with ascii code. The ascii standard does not prescribe any storage methods, .txt and .gif and myriads more storage methods are perfectly legitimite. If you disagree, please post a quote from the ascii standard prescribing storage methods. > > If you disagree, please post quotes from the ascii standard on prescribed > > manipulation and code retrieval methods, I don't see them. So, there are no prescriptions in the ascii standard on manipulation and code retrieval methods. > Like I said , they don't exist because this is an unwritten rule - an > understood principle, upon which this newsgroup is based. Again, please stick with the ascii standard, not by unwritten rules or understood principles. And should you not have noticed, I have pointed at the self-limiting views of this newsgroup as well ;-) > > > The ASCII standard doesn't allow for anything except some simple formatting > > > codes (like linefeed or horizontal tab). > > > > Please provide a quote from the ascii standard spelling out the prohibition, I > > don't see it. > > Sure, if you want me to type up a copy of an ASCII chart. Here are the > codes from 0 to 31, which define the ASCII control code set. Note that > using these codes is of course not allowed in this newsgroup. From the > manual to my Panasonic KX-P2123 printer (which has of course been retired): > > 0 Null <snip list> You did not provide a quote on the prohibition, since the ascii standard contains no such prohibition. What you provided is something else. > I didn't say the ASCII standard PROHIBITS the use of these options, I only > said it doesn't directly support them! This newsgroup, however, does > prohibit the use of the various typographical settings we've discussed, > because they just are not very portable. Ah, indeed, the ascii standard does not prohibit any of these options, and they are supported by myriads and myriads and myriads of resources in the real world! And of course, this newsgroup currently sticks with non-proportional, because it still provides a high portability of 80%. Compared to using html for example, then the portability is only 20%. One point in this discussion is that the 80% portability is coming down and the 20% portability is going up. So some time in the future (at least a few years from now on) there will be a cross-over point, and from then on html has the higher portability. > If it doesn't match those criteria after rendering, the image is not ASCII > art by definition (because it probably contains one or more codes to cause > some display change, making it fail the above criteria) Please provide a quote from the ascii standard spelling out those rendering criteria, I don't see them. > > Please provide a quote from the ascii standard stating the above viewing and > > translation requirements, I don't see them. > > Alright. Please provide me a quote from the ASCII standard stating that the > above requirements do not matter. The burden of proof rests on you, not me. You alleged that the ascii standard has viewing and translation requirements that are not there. > > Please prohibit the naming our parallel newsgroup alt.ascii-art.animation > > I think the name is justified, for the same reason as in the above. > > Since I don't read that newsgroup, I can't suggest what criteria they > follow. Well, the point was that you said that Javascript animations were not ascii art. However, that's exactly the topic of that newsgroup and it has nevertheless the words ascii art in its name. I think that the name is justified because ascii code is used to make those animations. > > 20% of newsreaders are set to proportional, damaging ascii pics. It is > > unrealistic to expect everyone of them to change to non-proportional, > > and over and above that, the trend goes the other way, i.e. the world > > goes to proportional. > It is just as iunrealistic to expect everyone to conform to some > porportional standard, when there simply IS NO STANDARD! Ah, but I did not suggest that at all, on the contrary, I denoted solutions like that "brute force" type of solutions, and that does not sound very complimentary, does it? > But the point is, they can - everyone has a fixed spaced font of some kind, > that can be used to view normal ASCII artwork. If you start asking people to fiddle with their settings, you might as well ask them to change to Arial, and then claim that aol pics have a portability of 80% or so. Whereas in reality (i.e. without making those changes) aol pics have a portability of only 10% or so, i.e. limited to within aol only. > You forget that much of the Usenet is still 7-bit only! Why do you think > the recommendation to use UUENCODE or MIME exists, for sending something > that contains characters outside the 32-127 range? I did not suggest any of those bandaid solutions, I did mention that more and more email and newsgroup software are becoming html aware. More and more people want to their email and newsgroup articles to look as webpages, I guess! > > The portability is not 100%, but at around 80% and declining, because 20% of > > email and newsreader software is set to proportional and the trend is towards proportional. > The portability is 100%, period. Name one internet-capable computer that > cannot display ASCII artwork using fixed-spaced font, as dictated by this > newsgroup. Go ahead. Name just ONE. I think you try to deny that the world is now 20% proportional which limits the portability to 80%. The decisive issue here is not whether the computer can be set to display ascii pics correctly, the decisive issue here is whether the computer has been actually set to display ascii pics correctly. Big difference! And I call it a decisive issue, since the ascii art community is perhaps just 1/1000 of 1% of the Internet. Therefore, it is this little community that has the burden of finding good solutions, not the 20%. And finding good solutions means to ensure that ascii pics are displayed correctly in the email and newsgroup software that these 20% are using anyway, without asking them to change settings, without asking them to change their Internet software, etc. (Good solutions exclude "brute force" type of solutions too.) > > Why is it ascii art if your finger does the paging, and why is it all of a > > sudden not ascii art if the paging is automated? > > Because that automated paging requires some sort of code. It might be a > series of ESCAPE codes, or it might just be a special string of characters > in the image. Please provide a quote from the ascii standard prohibiting the addition of codes, I don't see any. > You keep asking me to do the impossible - the ASCII standard, like I said, > is an assumed standard - a standard agreed upon by the vast majority of > people out there, who have knowledge of the subject. > The viewer is part of that assumed standard - one is not supposed to need So, there is no viewing requirement in the ascii standard. (I do not want to deliberately exasperate you, but we do need to stick with the actual ascii standard, not with an assumed ascii standard.) > No, those myriads of typograyhave ASCII at thier disposal. OK, my friend, that's what I wanted to get across! Words matter less than the message that the ascii community has those myriads of typography at their disposal, see further below also. > I suggest you repeat the "discussion" then - because I seem to have > forgotten what the better solution is. Well, I suggest you to reread the previous articles in this thread. I rather add the following info/diagram. Portability of ascii pics in various media. t = .txt medium h = .html medium j = .java medium ^ 80%|t h | t h | t h | t h | t h j | t j | h t j | h j t | h j t | h j t 20%|h j t | | ===================================================> Time now several years from now The diagram says that .txt provides less and less protection for ascii pics, from a good 80% today declining over time. The .html medium provides good protection for ascii pics, but portability is at a low 20% today, due to the level of html aware email and newsgroup software, but increasing. Similar for java, although at even slower ramp-up. > You seem to have lost the definition of portability by this statement. > > According to the New American Webster Handy College Dictionary: > > portable, adj. capable of being carried; easily conveyed. Also, portative, > adj. -- portability, n. > > In other words, portability means being able to move something (either it be > an object or a piece of data) from one place to another without a great deal > of effort. How about zero effort? No settings to change, no nothing at all, and still having the ascii pic correctly displayed, even in a 100% proportional world? On the "xxx supports yyy" vs "yyy supports xxx" debate, here is a quote from that section. > requires the data to be in ASCII format. In other words, typographical > settings do not support ASCII. Now I copy and paste a quote from you from further above. > No, those myriads of typograyhave ASCII at thier disposal. Looks like play of words to me. But again, decisive is that the ascii community has myriads of typography (and media) at its disposal. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
alt.ascii-whine
--
____ Time : Tue Sep 22 17:03:03 1998
.X+. .
.Xx+-. . The two highest achievements of the human mind are the
XXx++-.. twin concepts of "loyalty" and "duty". Whenever these
XXxx++--.. twin concepts fall into disrepute -- get out of there
`XXXxx+++--' fast! You may possibly save yourself, but it is too late
`XXXxxx' to save that society. It is doomed. Lazarus Long (59)
""
In article <360...@sympatico.ca>, you write:
|> > Instead of GIF actually BEING ASCII art, you now say it SHOWS ASCII art.
|> > With that statement, I agree.
|>
|> Good, good, printout and gif are both showing ascii art and they are both
|> ascii art. Without play of words, that's the same, i.e. printout and gif
|> are/show ascii art. And that's what I have said all the time, no change on my
|> part here.
You don't seem to notice that he
|>
|> Otherwise, by the same token, you would have to say that "the printout shows
|> ascii art, but it is not ascii art" which sounds pretty weird. Well, I
|> certainly will use the terms "is" and "show" interchangably.
|>
|> > Alleged? What I have been saying all along are the same set of statements,
|> > worded in a number of ways.
|> >
|> > Those are (for the record):
|> <snip>
|>
|> You repeated your statements without being able to quote the actual standard.
|> Where are those prescriptions on medium, code retrieval methods, etc?
|>
|> > The question of the printout on paper can be solved simply by assuming what
|> > most people already agree on anyways - the printout is simply a hardcopy of
|> > the actual ASCII artwork.
|>
|> Well, the printout is a hardcopy of the actual ascii artwork, the gif is a
|> softcopy of the actual ascii artwork, what's the difference?
|>
|> Whether it is a hardcopy or a softcopy, that does not justify a different
|> classification. That is, both hardcopy and softcopy are/show ascii art.
|>
|> > It is defined as ASCII art possibly because there
|> > really is no code system in use once the ink hits the paper (unless you want
|> > to dig into molecular theories and such).
|>
|> No need for such theorems, both hardcopy and softcopy are/show ascii art.
|>
|> > Let's put one thing straight now, for the paper analogy: Regardless of the
|> > format that some piece of artwork exists in, once it becomes ink on paper (a
|> > hardcopy), it can no longer be referred to accurately as the media from
|> > which the picture originated. In other words a hardcopy of a GIF image is
|> > no longer a GIF. A hardcopy of an ASCII drawing probably isn't technically
|> > ASCII art either, but again that's not the issue.
|>
|> That's exactly the issue at hand here. I keep things simple and say that both
|> hardcopy and softcopy are/show ascii art. If you want to change your mind and
|> say that hardcopy is not/does not show ascii art, then that's a new direction
|> in this discussion.
|>
|> > > > simple, common sense. It's an unwritten rule that ASCII art is supposed to
|> > > I suggest you go by the ascii standard rather than by (your own) common sense
|> > > or unwritten rules.
|> > My friend, I am going by the standard. If I weren't, I'd be posting HTML,
|> > GIF, and other non-ASCII images and claiming them to be ASCII artwork.
|>
|> Your response is out of context. The context of this exchange is that you
|> wanted to go by simple, common sense and unwritten rules. I suggested that you
|> stick with the actual ascii standard.
|>
|> > > There is about 80% easiness and declining.
|> > >
|> > > Try sending an ascii rose to your new found love at aol and she can't view it
|> > > correctly. That's 10% of the Internet. Another 10% comes from proportional
|> > > settings in the rest of the Internet.
|> >
|> > Well if it'S a one-liner, it won't matter anyways, the size of the rose will
|> > change a little, but that's about it.
|>
|> We need to devise solutions not just for one-liners though, the majority of
|> ascii pics is multi-line, e.g. there is only a few ascii roses, but there are
|> many multi-line ascii roses.
|>
|> > But, that first 10% of the internet, being AOL, is indeed a stumbling block.
|> > I've heard of a patch one can do that would allow the use of a custom font
|> > in the AOL newsreader, but I can't verify this.
|> >
|> > In other words, I won't argue for or against AOL since I don't have any
|> > experience in that area.
|> >
|> > That second 10%, those users with porportional fonts, is a matter of pure
|> > and simple laziness. That is, unless the user simply doesn't know how to
|> > change the font. But if they do, and they still complain, then it's a
|> > matter of laziness - too damned lazy to move a mouse around and click a few
|> > icons to change fonts.
|>
|> Those are brute force type of solutions, a better solution would be if the
|> recipient spends zero effort and the ascii pic is nevertheless displayed correctly.
|>
|> > The stored image is NOT made with ASCII code. It was created from ASCII
|> > code, yes. But it is no longer in the form of ASCII code.
|>
|> The printout stores the image not with ascii code either, and nevertheless,
|> the printout is/shows ascii art (unless you want to change your mind.)
|>
|> > > You did not provide a quote on the prohibition, since the ascii standard
|> > > contains no such prohibition. What you provided is something else.
|> >
|> > What I provided was the control code set for the ASCII standard. The very
|> > set of codes in that list should speak for itself. If it does not, I
|> > suggest you grab a reference guide and do some reading. It's obvious you
|> > don't know the ASCII set. (I don't claim to be an expert, but I'm pretty
|> > confident that what I7ve written is accurate)
|>
|> That exactly what I said, you provided something else (the code set) rather
|> than a quote on the (non-existing) prohibitions.
|>
|> Thank you for the suggestion on doing some reading on ascii, I have done that
|> a long time ago and I am now routinely using ascii codes to create ascii art
|> in a variety of media.
|>
|> > The portability of ASCII over HTML is an entirely different discussion.
|> > Besides, since HTML is an extension of ASCII, the portability of HTML will
|> > more than likely follow the portability of ASCII.
|> >
|> > > So some time in the future (at least a few years from now on) there will be a
|> > > cross-over point, and from then on html has the higher portability.
|> >
|> > And so what if it does (which i won't because of the simple need for basic,
|> > ordinary plain text)?
|>
|> In the above exhange, you seem to miss the theme of this thread, which is
|> about the correct rendition of ascii pics, and about the best solutions to
|> achieve this objective, i.e. without requiring any effort on the side of the recipient.
|>
|> > > > If it doesn't match those criteria after rendering, the image is not ASCII
|> > > > art by definition (because it probably contains one or more codes to cause
|> > > > some display change, making it fail the above criteria)
|> > >
|> > > Please provide a quote from the ascii standard spelling out those rendering
|> > > criteria, I don't see them.
|> >
|> > I did provide the closest thing to a quote, which you happily ignored and
|> > deleted (the list of ASCII control codes). That list spells out what ASCII
|> > is designed to do, and where it's limits were originally.
|>
|> I did not happily ignore your response, I disagreed with it.
|>
|> Let me try an analogy. You crank one of those old movies on celluloid tape by
|> hand and you want to call it a movie. Now you add a little motor to move the
|> celluloid tape automatically, and you don't want to call it a movie.
|>
|> I would call both arrangement movies, with or without automation.
|>
|> The context of the above was ascii pics being paged down manually or
|> automatically. By the same token as in the above, I would call both
|> arrangement ascii movies, with or without automation.
|>
|> > > > > Please provide a quote from the ascii standard stating the above viewing and
|> > > > > translation requirements, I don't see them.
|> > > >
|> > > > Alright. Please provide me a quote from the ASCII standard stating that the
|> > > > above requirements do not matter.
|> > >
|> > > The burden of proof rests on you, not me. You alleged that the ascii standard
|> > > has viewing and translation requirements that are not there.
|> >
|> > No my friend, the burden of proof lies with YOU. You started this argument
|> > by insisting that any form of artwork created from an ASCII picture
|> > qualifies as ASCII art.
|>
|> In the above exchange, you suddenly sidestepped from a specific topic to a
|> generic topic. Let me respond to the generic topic first and then respond to
|> the specific topic.
|>
|> On the generic topic: If I had used paint I would call my work painting, since
|> I use ascii code, I call my work ascii art, simple!
|>
|> On the specific topic: I can not post a quote that is not there. But if you
|> say the quote is in the ascii standard, please post.
|>
|> (I think the paint analogy can be taken further.
|>
|> After making a painting, the paint will dry and become a quite different
|> material than the liquid that came in a can, the liquid that you dipped your
|> paintbrush in, etc. But even after the paint material has changed, the
|> painting is still a painting!
|>
|> The same with ascii art. After making a piece of ascii art with ascii code,
|> the ascii code may then change to something different but the ascii art is
|> still ascii art!)
|>
|> > You provide me a quote from any standard that has been around as long as
|> > ASCII art has (30 or more years?).
|>
|> Get a copy of the ascii standard from the ANSI archives (and see for yourself
|> that the document contains very little, it basically contains only those
|> tables that everyone already know about.)
|>
|> > ASCII code is used to create the frames user in those animations, for sure.
|> > But assembling them into an animation goes beyond the definition of ASCII
|> > art, as there must be some way for the viewer program to know when one frame
|> > ends and another begins.
|>
|> And nevertheless, the newsgroup calls itself alt.ascii-art.animation
|>
|> > So how is this going to become a solution, when not all computers will be
|> > able to meet the hardware or software requirements to display in this new
|> > standard?
|>
|> See the portability curves in my previous posting. Those curves quantify my
|> guestimates over time.
|>
|> > > If you start asking people to fiddle with their settings, you might as well
|> > > ask them to change to Arial, and then claim that aol pics have a portability
|> > > of 80% or so.
|> >
|> > I proposed using a non-porportional font. Every single computer ever built
|> > that has some method of text display has a non-porportional font.
|>
|> Even if you use non-proportional font, only about 80% of the recipients will
|> see the ascii pic correctly. Again, don't ask recipients for any special
|> effort, i.e. no brute force solutions, please!
|>
|> > So what? If the standard used on AOL is the Arial font, so be it. A person
|> > receiving that picture can change thier font accordingly if they are
|> > interested in seeing the artwork, just as the other 90% of the internet can
|> > change thier font settings to be compatible with the majority of ASCII
|> > artwork.
|>
|> No brute force solutions, please!
|>
|> > Not the CLIENT software (the newsreaders and Email programs). I'm talking
|> > about the very guts of the internet. The SERVER software. I'm sure at
|> > least half of it (if not more) is still restricted to 7-bits only.
|>
|> Server software too is moving towards supporting html aware clients. This is a
|> mainstream development for both server and clients that necessarily has to go
|> hand in hand.
|>
|> > Just answer the damn question. Regardless of the how large the
|> > "porportional" population is, virtually every one of them can go non-
|> > porportional if the need arises (in other words, they can find some way to
|> > properly view this newsgroup and any other standard, fixed-spaced, 7-bit
|> > ASCII art.
|>
|> The answer to the damn question is: "It does not matter at all whether you can
|> set to non-proportional. What matters is whether the settings are actually non-proportional."
|>
|> Again, no brute force solutions, please!
|>
|> > Something is a bit wrong with at least one of these numbers. (Considering
|> > that I am not the world's best mathematician, perhaps it would help if you
|> > provide some numerical answers, i.e. X number of people in the net, Y number
|> > using ASCII art, Z number being porportional-ready, etc)
|>
|> Since we are all not the world's best mathematicians, let's take round numbers.
|>
|> There are 100 million people on the net.
|> 10 million of them are on aol.
|> 10 million have proportional settings (That is actual setting, not jut
|> proportional- ready)
|> 1,000 ascii artists in the ascii community who should be interested in
|> recipients receiving undamaged pics, no matter what email and newsgroup
|> software the recipient uses, and without asking recipients for extra effort
|> for changing settings, etc
|>
|> And what I said was that it is the 1/1000 of 1% who need to approach the 20%
|> rather than the other way around!
|>
|> > But you are asking them to change thier software by promoting standards that
|> > aren't fully adopted by the majority of the Internet community yet!
|>
|> No, I did not ask for anything. What I have been saying are clearly observable
|> trends, mainstream developments will run its own course.
|>
|> > I can't say how many times I've seen that statement in a web page. Even the
|> > Web is asking people to upgrade thier software. Fortunately, that upgrade
|> > is of course compatible with the older formats and methods, but it still
|> > means upgrading and replacing older software.
|>
|> Yes, and those are clearly brute force too. The worst offenders in this case
|> are web page designers who want to show off their capabilities on their
|> homepages and in so doing, do themselves a big disservice. Very view web
|> surfers have the patience to download a 200K page. And as a virtual
|> storefront, such mammoth homepages are counter-productive in the sense that
|> they chase potential customers away.
|>
|> But again, bad examples say nothing. (Although in this case, I couldn't resist
|> commenting, since that is one of my pet peeves too!)
|>
|> > The assumed standard *IS* the actual standard. There's no way to actually
|> > prove this without contacting one or more members of the committee that
|>
|> Get a copy of the ascii standard from the ANSI archives, and you will be
|> amazed how very little it contains, and very wisely so. It contains none of
|> the prohibitions, none of the prescriptions, none of the code retrieval
|> requirements, and what have you, that I asked you to provide a quote for.
|>
|> It is exactly the fact that this common denominator is so small, that it
|> became one of the most widely supported vehicles in the computer world. That
|> is what you are referring to with 100% portability, etc. But those refer to
|> the ascii code ONLY!
|>
|> Correct rendering of ascii pics is a different issue altogether! Things like
|> proportional/non-proportional, which are in the realm of typography rather
|> than ascii code, play decisive roles here!
|>
|> > > OK, my friend, that's what I wanted to get across! Words matter less than the
|> > > message that the ascii community has those myriads of typography at their
|> > > disposal, see further below also.
|> >
|> > Words matter less than the message, as long as you are getting the message
|> > across.
|>
|> Well, I sure hope I got the message across in this case.
|>
|> > And having it work to where a 100% porportional world will still display
|> > ASCIi art no matter what the actual format, typographical settings, or code
|> > set in use are, will take a great deal of effort.
|> <snip>
|> > These are all important questions, many of which will probably still be at
|> > issue when your "breakover" point is reached, regarding ASCII vs. HTML vs.
|> > Java.
|> <snip>
|> > My guess is, you probably had in mind that someone would use C++ or VBASIC,
|> > or some sort of program-creating software (i.e. a dedicated development
|> > system), rather than an actual lower level programming language that doesn't
|> > hold your hand through every step of the process.
|>
|> I agree with the identification of the issues. I disagree that it is the ascii
|> community that has to address the issues.
|>
|> What will happen in all likelyhood anyway, is that mainstream developments
|> will address the issues with general usage in mind. Mainstream developments
|> will definitly NOT care the least about special usage such as ascii pics.
|>
|> What I basically said, was that the ascii community can piggyback in certain
|> ways on mainstream solutions (and provided those portability curves of ascii
|> pics in .txt, .html, .java media, plotted over time. And FWIW, I have posted
|> many, many, lengthy, lengthy articles in the past as well on how to piggyback.)
|>
|> I don't give any of those "super" proposals the least chance for success.
|> Pushing such proposals through mainstream for the sake of a special purpose
|> will simply not work. Even the advanced idea of using applets for ascii art
|> that I described in a previous posting is basically piggybacking on mainstream
|> developments in Java.
|>
|> Well, so much some people in the ascii art community will bristle, only some
|> form of piggybacking on mainstream developments will have realistic chances
|> for success in the long run.
|>
|> =========================================================
|> [] .oo Visit the Gallery of the 'steins! []
|> [] ( -) http://www3.sympatico.ca/petecasso/ []
|> [] " " Frogstein, who has a point behind his eyes []
|> =========================================================
--
Ben Goldberg
--
"We don't care. We don't have to. We're the Phone Company."
From goldbb Tue Sep 22 20:10:06 1998
X-newsreader: xrn 7.04-beta-11
From: gol...@vccsouth-21.rcs.rpi.edu (Benjamin Goldberg)
Subject: Re: About rendering ascii code in a .txt medium
Newsgroups: alt.ascii-art
Distribution:
Followup-To:
References: <35F...@sympatico.ca> <35F...@spamfree.land> <35F...@sympatico.ca> <6tp9as$1ek$2...@tron.sci.fi> <360...@sympatico.ca> <Pin...@onyx.southwind.net> <360...@sympatico.ca> <Pin...@onyx.southwind.net> <360...@sympatico.ca> <Pin...@onyx.southwind.net> <360...@sympatico.ca> <Pin...@onyx.southwind.net> <360...@sympatico.ca>
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Keywords:
In article <360...@sympatico.ca>, Pete Casso <pet...@sympatico.ca> writes:
|> > Instead of GIF actually BEING ASCII art, you now say it SHOWS ASCII art.
|> > With that statement, I agree.
|>
|> Good, good, printout and gif are both showing ascii art and they are both
|> ascii art. Without play of words, that's the same, i.e. printout and gif
|> are/show ascii art. And that's what I have said all the time, no change on my
|> part here.
hmm, you seem to miss his point. Simply because something SHOWS ascii art has
little to do with it BEING ascii art. The mirror shows your reflection, but
is the mirror you?
|>
|> Otherwise, by the same token, you would have to say that "the printout shows
|> ascii art, but it is not ascii art" which sounds pretty weird. Well, I
|> certainly will use the terms "is" and "show" interchangably.
Now that's uttery stupid, [see my example above] but we'll play along.
|>
|> > Alleged? What I have been saying all along are the same set of statements,
|> > worded in a number of ways.
|> >
|> > Those are (for the record):
|> <snip>
|>
|> You repeated your statements without being able to quote the actual standard.
|> Where are those prescriptions on medium, code retrieval methods, etc?
The standard is in rfc 20.
|>
|> > The question of the printout on paper can be solved simply by assuming what
|> > most people already agree on anyways - the printout is simply a hardcopy of
|> > the actual ASCII artwork.
|>
|> Well, the printout is a hardcopy of the actual ascii artwork, the gif is a
|> softcopy of the actual ascii artwork, what's the difference?
The gif is a series of arbitrary bytes, ourside of the range described by rfc20,
and is therefor not ascii, and by not being ascii, cannot be ascii art.
To be ascii art, I should be able to open it up in my text editor and see the
shape of the drawing - if I open up a gif with my text editor, I see garbage.
|>
|> Whether it is a hardcopy or a softcopy, that does not justify a different
|> classification. That is, both hardcopy and softcopy are/show ascii art.
Again you confuse "show" with "are". A paper that has numerous logical fallacies
SHOWS the stupidity of it's author, but it's not the paper that's stupid.
|>
|> > It is defined as ASCII art possibly because there
|> > really is no code system in use once the ink hits the paper (unless you want
|> > to dig into molecular theories and such).
I'm not so sure that printed ascii art qualifies as ascii art - that could
possibly lead to some silly person then claiming that a printout of a gif which
was a screen dump of ascii art is *also* ascii art - possibly implying that the
intermediate stage, a gif image, was also ascii art.
Once you've opened yourself up to this argument, what about, for instance, taking
that gif and changing the colors of the letters, applying distortion filters, etc
and calling *that* ascii art, too?
Of course, you could have a restriction that printed text that was directly
calculated from ascii input is ascii art - this would make a printout of a
text file a candidate for ascii art, but a printout of a gif image not ascii
art.
|>
|> No need for such theorems, both hardcopy and softcopy are/show ascii art.
Back to that stilly confusion ....
|>
|> > Let's put one thing straight now, for the paper analogy: Regardless of the
|> > format that some piece of artwork exists in, once it becomes ink on paper (a
|> > hardcopy), it can no longer be referred to accurately as the media from
|> > which the picture originated. In other words a hardcopy of a GIF image is
|> > no longer a GIF. A hardcopy of an ASCII drawing probably isn't technically
|> > ASCII art either, but again that's not the issue.
Quite right - a printout of ascii art isn't rightly ascii art, it's a copy of a
piece of ascii art. These news postings SHOW our thoughts on this subject, but
you can't say the words on the screen ARE our thoughts -- our thoughts are still
inside our heads where they should be.
|>
|> That's exactly the issue at hand here. I keep things simple and say that both
|> hardcopy and softcopy are/show ascii art.
That's the problem, you're making the issue more complex by calling two different
things by the same name.
|> If you want to change your mind and
|> say that hardcopy is not/does not show ascii art, then that's a new direction
|> in this discussion.
Again with the confusion of IS and SHOWS - although you're right that he seems to
have changed his mind on weather a printout of ascii art is still ascii art.
|>
|> > > > simple, common sense. It's an unwritten rule that ASCII art is supposed to
|> > > I suggest you go by the ascii standard rather than by (your own) common sense
|> > > or unwritten rules.
|> > My friend, I am going by the standard. If I weren't, I'd be posting HTML,
|> > GIF, and other non-ASCII images and claiming them to be ASCII artwork.
|>
|> Your response is out of context. The context of this exchange is that you
|> wanted to go by simple, common sense and unwritten rules. I suggested that you
|> stick with the actual ascii standard.
What's wrong with common sense? Haven't got any?
Besides, he is sticking to the standard. Internet standards, rfcs, are written
after common sense has hammered out what is practical [or at least, what's been
implemented]. If it wasn't common sense, it wouldn't have become a standard.
[exceptions are rfc527, rfc748, and rfc1149]
|>
|> > > There is about 80% easiness and declining.
|> > >
|> > > Try sending an ascii rose to your new found love at aol and she can't view it
|> > > correctly. That's 10% of the Internet. Another 10% comes from proportional
|> > > settings in the rest of the Internet.
|> >
|> > Well if it'S a one-liner, it won't matter anyways, the size of the rose will
|> > change a little, but that's about it.
|>
|> We need to devise solutions not just for one-liners though, the majority of
|> ascii pics is multi-line, e.g. there is only a few ascii roses, but there are
|> many multi-line ascii roses.
Who needs to 'devise' a solution? We have one already - use fixed width ascii text.
|>
|> > But, that first 10% of the internet, being AOL, is indeed a stumbling block.
|> > I've heard of a patch one can do that would allow the use of a custom font
|> > in the AOL newsreader, but I can't verify this.
|> >
|> > In other words, I won't argue for or against AOL since I don't have any
|> > experience in that area.
|> >
|> > That second 10%, those users with porportional fonts, is a matter of pure
|> > and simple laziness. That is, unless the user simply doesn't know how to
|> > change the font. But if they do, and they still complain, then it's a
|> > matter of laziness - too damned lazy to move a mouse around and click a few
|> > icons to change fonts.
|>
|> Those are brute force type of solutions, a better solution would be if the
|> recipient spends zero effort and the ascii pic is nevertheless displayed correctly.
Hmm - require 10% of the internet to get a fixed width font is brute force,
but require the other 90% of the internet, who already have fixed width fonts
to get copies of that 10%'s proprotional font, that's not? Methinks you are
using a rather strange definition of brute force.
Your "better solution" requireing the recipient to spend zero effort to view the
data would in turn require unjustifyable effort in designing, distributing, and
installing software. Unjustifyable because the hassle and cost of having 100%
of the internet community purchase and install such software far outweighs the
"hassle" of the 2 extra mouse clicks need by 10% of the internet commununity
who don't have a fixed width font as the default.
|>
|> > The stored image is NOT made with ASCII code. It was created from ASCII
|> > code, yes. But it is no longer in the form of ASCII code.
|>
|> The printout stores the image not with ascii code either, and nevertheless,
|> the printout is/shows ascii art (unless you want to change your mind.)
To late, he did change his mind, saying:
|> > A hardcopy of an ASCII drawing probably isn't technically ASCII art either
As I said, and as he said, the printout is not ascii art.
The gif isn't ascii art either.
|>
|> > > You did not provide a quote on the prohibition, since the ascii standard
|> > > contains no such prohibition. What you provided is something else.
He listed the defined meanings of those ascii octets in the range 0x00 - 0x1f;
As the ascii standard [see rfc20] specifies that ascii characters are 7 bits,
and octets 0x20-0x7f are all defined as printable characters he shows that
there is no way to have color,font,style, or size information in standard ascii.
Where would you place it? As octets 0x80-0xff? Those have definitions in
extended ascii [such things as the 1/2 symbol, trademark, copywrite, and dozens
of assorted accented letters], and you can stick your new "change font" character
or whatever in that range either. Octets with a value of larger than 255 are not
possible, because you are limited to 8 bits per character.
|> >
|> > What I provided was the control code set for the ASCII standard. The very
|> > set of codes in that list should speak for itself. If it does not, I
|> > suggest you grab a reference guide and do some reading. It's obvious you
|> > don't know the ASCII set. (I don't claim to be an expert, but I'm pretty
|> > confident that what I've written is accurate)
|>
|> That exactly what I said, you provided something else (the code set) rather
|> than a quote on the (non-existing) prohibitions.
ASCII is defined by the code it is represented with.
|>
|> Thank you for the suggestion on doing some reading on ascii, I have done that
|> a long time ago and I am now routinely using ascii codes to create ascii art
|> in a variety of media.
|>
|> > The portability of ASCII over HTML is an entirely different discussion.
|> > Besides, since HTML is an extension of ASCII, the portability of HTML will
|> > more than likely follow the portability of ASCII.
|> >
|> > > So some time in the future (at least a few years from now on) there will be a
|> > > cross-over point, and from then on html has the higher portability.
|> >
|> > And so what if it does (which i won't because of the simple need for basic,
|> > ordinary plain text)?
|>
|> In the above exhange, you seem to miss the theme of this thread, which is
|> about the correct rendition of ascii pics, and about the best solutions to
|> achieve this objective, i.e. without requiring any effort on the side of the recipient.
I'm using xrn. To view a regular ascii pic requires no effort beyond that
of starting my newsreader, and certainly requires no more effort than reading
regular text. On the other hand, extracting an image from a news message,
opening up a shell, and starting up my image viewer would take a number of
steps. I could view the image inline using netscape, but I don't *like*
netscape's news interface.
If I *wanted* to view this newsgroup with netscape, I could, because netscape
has news and mail, by default [at least how it's installed on my system], set
to use fixed width fonts. It would *still* take an extra step to view your
gif image because I have auto-loading of images turned off to let web pages
load faster.
|>
|> > > > If it doesn't match those criteria after rendering, the image is not ASCII
|> > > > art by definition (because it probably contains one or more codes to cause
|> > > > some display change, making it fail the above criteria)
|> > >
|> > > Please provide a quote from the ascii standard spelling out those rendering
|> > > criteria, I don't see them.
|> >
|> > I did provide the closest thing to a quote, which you happily ignored and
|> > deleted (the list of ASCII control codes). That list spells out what ASCII
|> > is designed to do, and where it's limits were originally.
ascii(5) ascii(5)
NAME
ascii - map of ASCII character set
DESCRIPTION
The ASCII character set defines a 1-to-1 mapping of characters to 8-bit
values:
hexadecimal:
| 00 nul | 01 soh | 02 stx | 03 etx | 04 eot | 05 enq | 06 ack | 07 bel |
| 08 bs | 09 ht | 0a nl | 0b vt | 0c np | 0d cr | 0e so | 0f si |
| 10 dle | 11 dc1 | 12 dc2 | 13 dc3 | 14 dc4 | 15 nak | 16 syn | 17 etb |
| 18 can | 19 em | 1a sub | 1b esc | 1c fs | 1d gs | 1e rs | 1f us |
| 20 sp | 21 ! | 22 " | 23 # | 24 $ | 25 % | 26 & | 27 ' |
| 28 ( | 29 ) | 2a * | 2b + | 2c , | 2d - | 2e . | 2f / |
| 30 0 | 31 1 | 32 2 | 33 3 | 34 4 | 35 5 | 36 6 | 37 7 |
| 38 8 | 39 9 | 3a : | 3b ; | 3c < | 3d = | 3e > | 3f ? |
| 40 @ | 41 A | 42 B | 43 C | 44 D | 45 E | 46 F | 47 G |
| 48 H | 49 I | 4a J | 4b K | 4c L | 4d M | 4e N | 4f O |
| 50 P | 51 Q | 52 R | 53 S | 54 T | 55 U | 56 V | 57 W |
| 58 X | 59 Y | 5a Z | 5b [ | 5c \ | 5d ] | 5e ^ | 5f _ |
| 60 ` | 61 a | 62 b | 63 c | 64 d | 65 e | 66 f | 67 g |
| 68 h | 69 i | 6a j | 6b k | 6c l | 6d m | 6e n | 6f o |
| 70 p | 71 q | 72 r | 73 s | 74 t | 75 u | 76 v | 77 w |
| 78 x | 79 y | 7a z | 7b { | 7c | | 7d } | 7e ~ | 7f del |
decimal:
| 0 nul | 1 soh | 2 stx | 3 etx | 4 eot | 5 enq | 6 ack | 7 bel |
| 8 bs | 9 ht | 10 nl | 11 vt | 12 np | 13 cr | 14 so | 15 si |
| 16 dle | 17 dc1 | 18 dc2 | 19 dc3 | 20 dc4 | 21 nak | 22 syn | 23 etb |
| 24 can | 25 em | 26 sub | 27 esc | 28 fs | 29 gs | 30 rs | 31 us |
| 32 sp | 33 ! | 34 " | 35 # | 36 $ | 37 % | 38 & | 39 ' |
| 40 ( | 41 ) | 42 * | 43 + | 44 , | 45 - | 46 . | 47 / |
| 48 0 | 49 1 | 50 2 | 51 3 | 52 4 | 53 5 | 54 6 | 55 7 |
| 56 8 | 57 9 | 58 : | 59 ; | 60 < | 61 = | 62 > | 63 ? |
| 64 @ | 65 A | 66 B | 67 C | 68 D | 69 E | 70 F | 71 G |
| 72 H | 73 I | 74 J | 75 K | 76 L | 77 M | 78 N | 79 O |
| 80 P | 81 Q | 82 R | 83 S | 84 T | 85 U | 86 V | 87 W |
| 88 X | 89 Y | 90 Z | 91 [ | 92 \ | 93 ] | 94 ^ | 95 _ |
| 96 ` | 97 a | 98 b | 99 c |100 d |101 e |102 f |103 g |
|104 h |105 i |106 j |107 k |108 l |109 m |110 n |111 o |
|112 p |113 q |114 r |115 s |116 t |117 u |118 v |119 w |
|120 x |121 y |122 z |123 { |124 | |125 } |126 ~ |127 del |
And for a translation
0 is used for end-of-string
1 = ???
2 = start transmission
3 = end transmission
4 = end of transmission
5 = enquire
6 = acknowledgement [sent in response to enquire]
7 = Bell
8 = Backspace
9 = Tab
10 = Line feed
11 = Vertical Tab
12 = Form Feed (Clear Screen, or New Page for a printer)
13 = Carriage Return
14 = Shift-Out
15 = Shift-In
16 = ???
17 = Device Control 1 (X-On)
18 = Device Control 2
19 = Device Control 3 (X-Off)
20 = Device Control 4
21 = ??
22 = synchronize
23-26= ??
27 = escape [begin device dependent sequence of command characters]
27-31 = ???
32 = space
31-126 = letters
127 = delete
Now that I have here in front of me the list of all defined ascii codes,
I don't see how you can stick fonts, sizes, styles, or colors into ascii code,
nor, by extention, into ascii art.
|>
|> I did not happily ignore your response, I disagreed with it.
No, you ignored it while making a throw away comment to make it
look otherwise.
|>
|> Let me try an analogy. You crank one of those old movies on celluloid tape by
|> hand and you want to call it a movie. Now you add a little motor to move the
|> celluloid tape automatically, and you don't want to call it a movie.
Poor analogy.
He's showing a drawing made with ruler and compass, and calling it a drawing.
You're showing a printout of an image made with MacDraw, and calling it a drawing.
[It might be a very nice image, and very drawing-like, but that doesn't make
it a drawing]
or:
He's showing you a photograph, and calling it a photograph.
You're showing a movie that was made by scanning in photographs,
projecting it on a screen, and calling it a photograph.
|>
|> I would call both arrangement movies, with or without automation.
|>
|> The context of the above was ascii pics being paged down manually or
|> automatically. By the same token as in the above, I would call both
|> arrangement ascii movies, with or without automation.
An ascii movie is ascii text interspersed with vt100 control codes
to move the cursor and redraw a screenfull of text without scrolling.
I would not [for example] call the things on Llizard's web page
ascii movies, but javascript movies [not that llizard is calling them
"ascii movies"]
|>
|> > > > > Please provide a quote from the ascii standard stating the above viewing and
|> > > > > translation requirements, I don't see them.
|> > > >
|> > > > Alright. Please provide me a quote from the ASCII standard stating that the
|> > > > above requirements do not matter.
|> > >
|> > > The burden of proof rests on you, not me. You alleged that the ascii standard
|> > > has viewing and translation requirements that are not there.
|> >
|> > No my friend, the burden of proof lies with YOU. You started this argument
|> > by insisting that any form of artwork created from an ASCII picture
|> > qualifies as ASCII art.
|>
|> In the above exchange, you suddenly sidestepped from a specific topic to a
|> generic topic. Let me respond to the generic topic first and then respond to
|> the specific topic.
It seems that you're both sidestepping the obvious item that neither of you have
copies of the standard.
|>
|> On the generic topic: If I had used paint I would call my work painting, since
|> I use ascii code, I call my work ascii art, simple!
If make a painting, and then make a photocopy of it, is the photocopy a painting?
|>
|> On the specific topic: I can not post a quote that is not there. But if you
|> say the quote is in the ascii standard, please post.
|>
|> (I think the paint analogy can be taken further.
|>
|> After making a painting, the paint will dry and become a quite different
|> material than the liquid that came in a can, the liquid that you dipped your
|> paintbrush in, etc. But even after the paint material has changed, the
|> painting is still a painting!
When you type up your ascii image, it is ones and zeros in computer memory.
When you save it, it is ones and zeros on magnetic disk. The ones and zeros
are in the same sequence on disk as they were in memory, just as the now dry
paint is in the same pattern, and has the same colors as it had when wet.
The only difference it's not possible to make paint wet again for someone to
modify it, and the only way to make as exact a copy of a painting as you can
make of ascii art would be to hook up a robot arm to a computer with a camera,
and have it dip a brush in accurately mixed paint and it in the exact same way
as was done to make the original painting.
|>
|> The same with ascii art. After making a piece of ascii art with ascii code,
|> the ascii code may then change to something different but the ascii art is
|> still ascii art!)
When ascii code changes from a pattern of bits in memory to a sequence of bits
traveling through a wire or fiber-optic cable or to a sequence of bits on
a microdisk, the bits are in the same order, the letter 'a' is still ascii 97,
a space is still ascii 30, etc. If you take a screenshot of a piece of ascii
art, it is now different information that is stored - you've got info saying,
a pixel here, of this color, a pixel there, of that color, etc. You no longer
have information saying that <ascii letter 97 is at the ##th byte of the file>,
or for that matter, no information at all that the image was constructed from
ascii art. By not being in ascii, it ceases to be ascii art. It might still
be art, but not ascii art. A painting of a sculpture might be art, but it
isn't a sculpture.
|>
|> > You provide me a quote from any standard that has been around as long as
|> > ASCII art has (30 or more years?).
|>
|> Get a copy of the ascii standard from the ANSI archives (and see for yourself
|> that the document contains very little, it basically contains only those
|> tables that everyone already know about.)
It does indeed contain those tables - anything not in those tables isn't ascii.
gif images contain characters not in those tables, and are not ascii.
|>
|> > ASCII code is used to create the frames user in those animations, for sure.
|> > But assembling them into an animation goes beyond the definition of ASCII
|> > art, as there must be some way for the viewer program to know when one frame
|> > ends and another begins.
|>
|> And nevertheless, the newsgroup calls itself alt.ascii-art.animation
So? All that means is that the people who created the newsgroup couldn't think
of a more accurate name. You want we should call it ascii+vt100-animated-text?
|>
|> > So how is this going to become a solution, when not all computers will be
|> > able to meet the hardware or software requirements to display in this new
|> > standard?
|>
|> See the portability curves in my previous posting. Those curves quantify my
|> guestimates over time.
Looked at them. They're wrong.
Percentage viewability of ascii art went down slightly due to the large number
of people coming online with AOL, but the only people signing up with AOL are
new users - noone is switching FROM better, more complete services TO AOL, and
lots of people are getting online using regular services, all of which have
fixed width fonts available in their newsreaders, so the number of people who
can view standard ascii art is going up. Also, as AOL provides better services
at the demands of its customers, they'll be able to view ascii art properly.
While the availability of java and html will go up, they can at most result
in computers having equal ability to view those and plain text, because
noone [not even micro$oft] would be stupid enough to sell a computer that didn't
at least come with some sort of wordpad or simpletext or emacs text editor,
and browsers come with more and more and more fonts as time passes, not fewer.
|>
|> > > If you start asking people to fiddle with their settings, you might as well
|> > > ask them to change to Arial, and then claim that aol pics have a portability
|> > > of 80% or so.
|> >
|> > I proposed using a non-porportional font. Every single computer ever built
|> > that has some method of text display has a non-porportional font.
|>
|> Even if you use non-proportional font, only about 80% of the recipients will
|> see the ascii pic correctly. Again, don't ask recipients for any special
|> effort, i.e. no brute force solutions, please!
|>
|> > So what? If the standard used on AOL is the Arial font, so be it. A person
|> > receiving that picture can change thier font accordingly if they are
|> > interested in seeing the artwork, just as the other 90% of the internet can
|> > change thier font settings to be compatible with the majority of ASCII
|> > artwork.
|>
|> No brute force solutions, please!
How is getting 10% of the net to comply with the other 90% of the net
a "brute force" solution?
|>
|> > Not the CLIENT software (the newsreaders and Email programs). I'm talking
|> > about the very guts of the internet. The SERVER software. I'm sure at
|> > least half of it (if not more) is still restricted to 7-bits only.
|>
|> Server software too is moving towards supporting html aware clients. This is a
|> mainstream development for both server and clients that necessarily has to go
|> hand in hand.
Sure, *new* server software can handle 8 bit transmissions, but, as mentioned,
most of the server software out there is not new.
|>
|> > Just answer the damn question. Regardless of the how large the
|> > "porportional" population is, virtually every one of them can go non-
|> > porportional if the need arises (in other words, they can find some way to
|> > properly view this newsgroup and any other standard, fixed-spaced, 7-bit
|> > ASCII art.
|>
|> The answer to the damn question is: "It does not matter at all whether you can
|> set to non-proportional. What matters is whether the settings are actually non-proportional."
|>
|> Again, no brute force solutions, please!
HMM, ~4 clicks to set default font to fixed-width == brute force?
once again, you convince me you have a strange idea of brute force.
|>
|> > Something is a bit wrong with at least one of these numbers. (Considering
|> > that I am not the world's best mathematician, perhaps it would help if you
|> > provide some numerical answers, i.e. X number of people in the net, Y number
|> > using ASCII art, Z number being porportional-ready, etc)
|>
|> Since we are all not the world's best mathematicians, let's take round numbers.
|>
|> There are 100 million people on the net.
|> 10 million of them are on aol.
|> 10 million have proportional settings (That is actual setting, not jut
|> proportional- ready)
|> 1,000 ascii artists in the ascii community who should be interested in
|> recipients receiving undamaged pics, no matter what email and newsgroup
|> software the recipient uses, and without asking recipients for extra effort
|> for changing settings, etc
|>
|> And what I said was that it is the 1/1000 of 1% who need to approach the 20%
|> rather than the other way around!
Your description of those numbers is a bit cockeyed -
Lets pretend there are as few as 1000 ascii artists who want their viewers
to see their art properly, and lets pretend there are as few as 3 million
people who look at ascii art regularly, who of course will want all ascii
art to view properly without doing anything [including of course archived
ascii art, which is in ordinary ascii text format], but there are at least
60 million who occasionally view ascii art, and who will, at such time,
want to see it properly. I do not think that the overlap between the 10%
who have their browser/news reader set to proportional font, and the 60%
who want to see ascii art properly when they occasionally view it, is large
enough [ 60% x 10% = 6% ] to dictate to the rest of the internet to change to
proportional font!
|>
|> > But you are asking them to change thier software by promoting standards that
|> > aren't fully adopted by the majority of the Internet community yet!
|>
|> No, I did not ask for anything. What I have been saying are clearly observable
|> trends, mainstream developments will run its own course.
Trends: internet providers provide what their users demand, and no user demands
to have *less* functionality. Elimiating the ability to properly view
text that was meant to be fixed width would be a major loss of functionality.
|>
|> > I can't say how many times I've seen that statement in a web page. Even the
|> > Web is asking people to upgrade thier software. Fortunately, that upgrade
|> > is of course compatible with the older formats and methods, but it still
|> > means upgrading and replacing older software.
|>
|> Yes, and those are clearly brute force too. The worst offenders in this case
|> are web page designers who want to show off their capabilities on their
|> homepages and in so doing, do themselves a big disservice. Very view web
|> surfers have the patience to download a 200K page. And as a virtual
|> storefront, such mammoth homepages are counter-productive in the sense that
|> they chase potential customers away.
|>
|> But again, bad examples say nothing. (Although in this case, I couldn't resist
|> commenting, since that is one of my pet peeves too!)
|>
|> > The assumed standard *IS* the actual standard. There's no way to actually
|> > prove this without contacting one or more members of the committee that
|>
|> Get a copy of the ascii standard from the ANSI archives, and you will be
|> amazed how very little it contains, and very wisely so. It contains none of
|> the prohibitions, none of the prescriptions, none of the code retrieval
|> requirements, and what have you, that I asked you to provide a quote for.
Neither does it have any statement requiring, allowing, or even implying,
and of the extended abilities of font,color,width you asked for.
|>
|> It is exactly the fact that this common denominator is so small, that it
|> became one of the most widely supported vehicles in the computer world. That
|> is what you are referring to with 100% portability, etc. But those refer to
|> the ascii code ONLY!
It still is the most common denominator. Mac isn't dead yet, and there are more
and ever more variants of unix and linux, and there are still many old vaxen on the
net, plus neXt machine, plus a few PDPs, plus, ....
Need I mention that on most of these, fixed width fonts are the default [if not only]
fonts available?
|>
|> Correct rendering of ascii pics is a different issue altogether! Things like
|> proportional/non-proportional, which are in the realm of typography rather
|> than ascii code, play decisive roles here!
Almost right.
The reason ascii is so widely used is the same reason people use ascii art -
It works everywhere, and won't be harmed when internet news/mail servers truncate
it to 7bits per byte. The reason ascii-art is so widely used is because it's
underlying encodeing [ascii] is widely used, and because it is displayed
approximately the same everywhere.
A machine that displays ascii in a proportional font by default is like
Micro$oft's distribution of non-compliant java; It prevents the select
few that use that brain-dead product from viewing things created by
the rest of the world.
|>
|> > > OK, my friend, that's what I wanted to get across! Words matter less than the
|> > > message that the ascii community has those myriads of typography at their
|> > > disposal, see further below also.
|> >
|> > Words matter less than the message, as long as you are getting the message
|> > across.
|>
|> Well, I sure hope I got the message across in this case.
You got across that there are lots of ways of viewing ascii.
You also got across the [incorrect] idea that each particular individual has
lots of different ways of viewing ascii. Many have only one [fixedwidth]
or only a few fonts. Only people installing new software have dozens and
dozens of fonts.
|>
|> > And having it work to where a 100% porportional world will still display
|> > ASCIi art no matter what the actual format, typographical settings, or code
|> > set in use are, will take a great deal of effort.
|> <snip>
|> > These are all important questions, many of which will probably still be at
|> > issue when your "breakover" point is reached, regarding ASCII vs. HTML vs.
|> > Java.
|> <snip>
|> > My guess is, you probably had in mind that someone would use C++ or VBASIC,
|> > or some sort of program-creating software (i.e. a dedicated development
|> > system), rather than an actual lower level programming language that doesn't
|> > hold your hand through every step of the process.
|>
|> I agree with the identification of the issues. I disagree that it is the ascii
|> community that has to address the issues.
Hmm, you want a browser than can view anything, effortlessly, but don't want to
code it yourself?
|>
|> What will happen in all likelyhood anyway, is that mainstream developments
|> will address the issues with general usage in mind. Mainstream developments
|> will definitly NOT care the least about special usage such as ascii pics.
Of course they will. Of those postings you've seen that had sigs, and those
personal emails you've gotten that had sigs, what % of those sigs had some
bit of ascii art? Most, I'd expect.
|>
|> What I basically said, was that the ascii community can piggyback in certain
|> ways on mainstream solutions (and provided those portability curves of ascii
|> pics in .txt, .html, .java media, plotted over time. And FWIW, I have posted
|> many, many, lengthy, lengthy articles in the past as well on how to piggyback.)
Who wants to read lengthy articles? We just want to be able to open newsreader,
and read ascii art, or open reader, and *type* ascii art. We don't want to have
to deal with nonsense of detaching or attaching images.
|>
|> I don't give any of those "super" proposals the least chance for success.
Then why were you proposing one yourself?
|> Pushing such proposals through mainstream for the sake of a special purpose
|> will simply not work. Even the advanced idea of using applets for ascii art
|> that I described in a previous posting is basically piggybacking on mainstream
|> developments in Java.
|>
|> Well, so much some people in the ascii art community will bristle, only some
|> form of piggybacking on mainstream developments will have realistic chances
|> for success in the long run.
You're right that we'll bristle at the idea, and you're wrong that only
some form of piggybacking will have some form of success.
Sending ascii art as ordinary text will continue the main way of sending it
for many many decades [see rfc1149 for a possible future alternate method]
|>
|> =========================================================
|> [] .oo Visit the Gallery of the 'steins! []
|> [] ( -) http://www3.sympatico.ca/petecasso/ []
|> [] " " Frogstein, who has a point behind his eyes []
|> =========================================================
Aha! the only good thing on the note!
Even if I dislike your rhetoric, and disagree with you,
I still like your birdsteins!
--
Ben Goldberg
--
"We don't care. We don't have to. We're the Phone Company."
Wow! It seems at times that you were just out to contradict me just for the sake of it. Nevertheless, let me respond in a rational way to the main points and avoiding repetitions as much as possible. > hmm, you seem to miss his point. Simply because something SHOWS ascii art has > > little to do with it BEING ascii art. The mirror shows your reflection, but > is the mirror you? I did not miss any point, I am NOT talking about a reproduction either, neither in a mirror nor otherwise, and neither here nor further down in my previous article. And yes, indeed, mistaking a mirror image for the original is stupid ;-) MY point is that you always need to display the invisible ascii code to view ascii art. And to me, it doesn't matter whether you display it on the screen, or print it out, or through a .txt file, or through a gif file, etc. The decisive point here, is that the display actually shows what the ascii artist has created (with ascii code.) And that's the reason for me to say that they all are AND show ascii art (of course taken in this context.) > The standard is in rfc 20. Strange, I digged into the IETF archives, I did not find rfc 20. Further down, you referred to the following rfcs, but they have nothing to do with the ascii standard either. rfc 527 ARPAWOCKY rfc 748 Telnet Randomly-Lose Option rfc 1149 A Standard for the Transmission of IP Datagrams on Avian Carriers > The gif is a series of arbitrary bytes, ourside of the range described by rfc20, > and is therefor not ascii, and by not being ascii, cannot be ascii art. Well, rfc20 is apparently not in the IETF archives, but apart from that ascii art can be be stored as a gif or as a hardcopy, although both have lost the ascii code. So what? Decisive is only that the viewer sees the artwork as the artist has created it. > To be ascii art, I should be able to open it up in my text editor and see the > shape of the drawing - if I open up a gif with my text editor, I see garbage. Where is it written, for example, that ascii art has to be viewed with a text editor? Please provide quote from the ascii standard. > I'm not so sure that printed ascii art qualifies as ascii art - that could > possibly lead to some silly person then claiming that a printout of a gif which > was a screen dump of ascii art is *also* ascii art - possibly implying that the > intermediate stage, a gif image, was also ascii art. I take life easy and say that all that IS ascii art if it indeed shows what the ascii artist created. > Once you've opened yourself up to this argument, what about, for instance, taking > that gif and changing the colors of the letters, applying distortion filters, etc > and calling *that* ascii art, too? I take life easy and say that all that IS ascii art if it indeed shows what the ascii artist created. > Of course, you could have a restriction that printed text that was directly > calculated from ascii input is ascii art - this would make a printout of a > text file a candidate for ascii art, but a printout of a gif image not ascii > art. Please provide a quote on that restriction from the ascii standard. > Quite right - a printout of ascii art isn't rightly ascii art, it's a copy of a > piece of ascii art. Wow! Please show me the original! <sarcasm> You really make things complex. To me, a printout of ascii art is ascii art, simple! And that's using common sense too, ha ha ha! ;-) > Who needs to 'devise' a solution? We have one already - use fixed width ascii text. That's an 80% good solution that slowly, but surely becoming worse with the computing world going proportional. > Hmm - require 10% of the internet to get a fixed width font is brute force, > but require the other 90% of the internet, who already have fixed width fonts > to get copies of that 10%'s proprotional font, that's not? Methinks you are > using a rather strange definition of brute force. You missed my point completely. What I said was just the opposite: recipients should spend zero effort on viewing ascii pics correctly. Everything else, like forcing the recipient to install other fonts, change font settings (non-proportional or proportional,) etc is brute force. > Your "better solution" requireing the recipient to spend zero effort to view the > data would in turn require unjustifyable effort in designing, distributing, and > installing software. Unjustifyable because the hassle and cost of having 100% > of the internet community purchase and install such software far outweighs the > "hassle" of the 2 extra mouse clicks need by 10% of the internet commununity > who don't have a fixed width font as the default. Again, you missed my point completely. What I said was just the opposite: everyone, i.e. both makers and viewers of ascii art, use the Internet software they are using anyway. Please reread my previous postings carefully on how to do that by way of "piggybacking" as I call it. > there is no way to have color,font,style, or size information in standard ascii. > Now that I have here in front of me the list of all defined ascii codes, > I don't see how you can stick fonts, sizes, styles, or colors into ascii code, > nor, by extention, into ascii art. Aha, and this is a perfect opportunity to point out that ascii code alone is not sufficient to make ascii art. You need a font, a font color, a contrasting background color, etc that are in the realm of typography, outside the ascii standard. Or to say things the other way around, to make ascii art, you need ascii code AND ALWAYS things that are outside of the ascii standard. And you are free to choose from a myriad of resources. If you disagree, please post a quote on the prohibitions from the ascii standard. (And this is not a throw away comment as you put it further down, it is just a simple fact that ascii code is a necessary but not sufficient condition for making ascii art. I'm using this phrase from mathematics, because I sense that it will make sense to you.) > I'm using xrn. To view a regular ascii pic requires no effort beyond that <snip> > If I *wanted* to view this newsgroup with netscape, I could, because netscape I was not talking about you or anyone in specific for that matter. I was talking about 20% of people on the net (and increasing) who see garbage instead of ascii art. > It seems that you're both sidestepping the obvious item that neither of you > have copies of the standard. Thank you, thank you, I have the privilege of having access to an excellent library, but indeed I could not find rfc 20 ;-) > He's showing a drawing made with ruler and compass, and calling it a drawing. > You're showing a printout of an image made with MacDraw, and calling it a drawing. > [It might be a very nice image, and very drawing-like, but that doesn't make > it a drawing] I have indeed no objections to using good tools. Otherwise, we would all be drawing ascii art by hand, ha ha ha! > When you type up your ascii image, it is ones and zeros in computer memory. > When you save it, it is ones and zeros on magnetic disk. The ones and zeros > are in the same sequence on disk as they were in memory, just as the now dry > paint is in the same pattern, and has the same colors as it had when wet. > > The only difference it's not possible to make paint wet again for someone to > modify it, and the only way to make as exact a copy of a painting as you can > make of ascii art would be to hook up a robot arm to a computer with a camera, > and have it dip a brush in accurately mixed paint and it in the exact same way > as was done to make the original painting. I see no relevance of the above quotes to the discussion that we are having. > a space is still ascii 30, etc. If you take a screenshot of a piece of ascii > art, it is now different information that is stored - you've got info saying, > a pixel here, of this color, a pixel there, of that color, etc. You no longer > have information saying that <ascii letter 97 is at the ##th byte of the file>, Well, this is a repetition, and again, my contention is that it is ascii art if it indeed shows what the ascii artist created, the means for displaying the artwork does not matter. And again, please note that I am NOT talking about reproductions here. > It does indeed contain those tables - anything not in those tables isn't ascii. Hah, and now we can't make ascii art at all, since fonts, font color, background color, etc are not contained in those tables either! <sarcasm> (You need ascii code + typography for making ascii art, but we are becoming repetitive.) > |> And nevertheless, the newsgroup calls itself alt.ascii-art.animation > So? All that means is that the people who created the newsgroup couldn't think > of a more accurate name. You want we should call it ascii+vt100-animated-text? No, I think it is a perfect and accurate name. > |> See the portability curves in my previous posting. Those curves quantify my > |> guestimates over time. > Looked at them. They're wrong. Well, present your curves and we can discuss them > While the availability of java and html will go up, they can at most result > in computers having equal ability to view those and plain text, because Viewing plain text is not good enough for ensuring that ascii pics are rendered correctly, because the world is going proportional. > Sure, *new* server software can handle 8 bit transmissions, but, as mentioned, > most of the server software out there is not new. Well, that's the trend. > |> And what I said was that it is the 1/1000 of 1% who need to approach the 20% > |> rather than the other way around! > Your description of those numbers is a bit cockeyed - <snip> > enough [ 60% x 10% = 6% ] to dictate to the rest of the internet to change to > proportional font! Well, first of all, "dictate proportional" is brute force that I reject. Please read my articles carefully. I said the 1/1000 of 1% need to approach 20%, and you said it is not 20% but 6%. Well, in this kind of guestimates, that does not matter at all. What matters is the 4 orders of magnitude difference. > to have *less* functionality. Elimiating the ability to properly view > text that was meant to be fixed width would be a major loss of functionality. Well, I wonder why the world is going proportional? But kidding aside, I am pointing out that the world is going proportional NOT because I want to recommend the use of proportional, that's brute force. I am pointing out that the world is going proportional because that damages ascii pics (and we need to protect ascii pics, etc etc) Please read my articles carefully. > The reason ascii is so widely used is the same reason people use ascii art - > It works everywhere, and won't be harmed when internet news/mail servers truncate These days, ascii art is harmed 20% of the time and becoming worse, because of proportional, even if you call it brain-dead. But that does not mean that I want to force the use of proportional, etc etc ... please read my articles carefully. > You got across that there are lots of ways of viewing ascii. > You also got across the [incorrect] idea that each particular individual has > lots of different ways of viewing ascii. Many have only one [fixedwidth] > or only a few fonts. Only people installing new software have dozens and > dozens of fonts. Almost right, but not quite. What I said was that everyone on the net should be able to view ascii art correctly with his/her own Internet software, without any change of settings, etc. At the present time, only 80% view ascii art correctly and declining. > Who wants to read lengthy articles? We just want to be able to open newsreader, > and read ascii art, or open reader, and *type* ascii art. We don't want to have > to deal with nonsense of detaching or attaching images. You missed the point here. The point of those lengthy articles is on zero effort for the recipients and zero development efforts for the ascii community. Mainstream development will only care about ascii code for general usage, but will not care about ascii art which is a special purpose. But we can piggyback on mainstream, that's the point, please reread my articles carefully. > You're right that we'll bristle at the idea, and you're wrong that only > some form of piggybacking will have some form of success. I think that piggybacking on html will be a necessity to protect ascii art at least several years down the road, although I won't do anything to push things in this direction, mainstream development will run its own course. > Sending ascii art as ordinary text will continue the main way of sending it > for many many decades [see rfc1149 for a possible future alternate method] No, sending ascii code will continue as it has always had. But sending ascii art needs to change if we want to be sure that the viewer sees it correctly in this increasingly proportional world. rfc1149 does not seem to be pertinent at all for ascii art. Again, all those mainstream efforts will apply to ascii code, but unfortunately that's not good enough for ascii art. As I said in the above, we need typography too for ascii art, and at the moment, that's screwed up for 20% of the net. > Aha! the only good thing on the note! > Even if I dislike your rhetoric, and disagree with you, > I still like your birdsteins! Thank you, I am sure in time you will like my writing as well, because it is not rhetoric but good info. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> I did not miss any point, I am NOT talking about a reproduction either, Then what exactly do you call a GIF image of an ASCII art picture? It is a reproduction, as it is not the original art work created with a text editor by the original artist. It is now a converted/imported image derived from the original artwork. Thus, like a photo of a sculpture or painting, it is a reproduction. > And that's the reason for me to say that they all are AND show ascii art (of > course taken in this context.) Ok, an item can both BE ASCII art as well as SHOW it, only if the media involved directly supports the ASCII format (and is doing so to contain the picture). A GIF file does support ASCII/text attachments, but as long as you are representing that ASCII artwork in the form of a bitmapped image, you're only showing ASCII art. The GIF itself is not actually ASCII art, it's just a representation of it. > > The standard is in rfc 20. > > Strange, I digged into the IETF archives, I did not find rfc 20. Probably because the standard is so old - your archives may not necessarily go back far enough. > Well, rfc20 is apparently not in the IETF archives, but apart from that ascii > art can be be stored as a gif or as a hardcopy, although both have lost the > ascii code. So what? Decisive is only that the viewer sees the artwork as the > artist has created it. ASCII cannot be stored as a GIF unless you are using the actual ASCII attachment method (can someone post the info on what type of attachments GIF 89A supports?). ASCII artwork can be represented as a GIF, but it still qualifies only as a representation, not as actual ASCII art. > > To be ascii art, I should be able to open it up in my text editor and see the > > shape of the drawing - if I open up a gif with my text editor, I see garbage. > > Where is it written, for example, that ascii art has to be viewed with a text > editor? Please provide quote from the ascii standard. The standard itself (i.e. being a standard at all) is what defines that it be displayed on a text screen (or in a text editor, or on a printout, which was probably the common "display" method when RFC20 was proposed). Where is it wrttten that a GIF image has to be viewed with a GIF viewer? Just as the above person said (sorry, I missed his name?), view it with anything but a GIF viewer (or a program capable of displaying GIFs) and you see nothing but garbage. Do you see it written anywhere that GIFs have to be viewed with a GIF reader? :-) Of course not, it's pure common sense! > > Once you've opened yourself up to this argument, what about, for instance, taking > > that gif and changing the colors of the letters, applying distortion filters, etc > > and calling *that* ascii art, too? > > I take life easy and say that all that IS ascii art if it indeed shows what > the ascii artist created. But it isn't, if the colors have been changed, or if the picture has been altered in any way beyond a reasonable amount. The artist (most likely) created a black and white picture with ASCII code, and stored, transmitted, and edited that picture using nothing but ASCII code. It's colorized artwork, which has to now fit the definition of the media which makes those colors possible. Hence, it might be just "text art" or "HTML art". It isn't ASCII art anymore, not according to the standard which was just posted. > > text file a candi> > > Of course, you could have a restriction that printed text that was directly > > calculated from ascii input is ascii art - this would make a printout of a > > [file a candidate] for ascii art, but a printout of a gif image not ascii > > art. > > Please provide a quote on that restriction from the ascii standard. So you're saying that a GIF printed on paper is ASCII art because the GIF itself was created from an ASCII textfile, even though it's already established that the GIF is not ASCII art? (By the way, yes I did change my mind on the issue of printouts of ASCII art, as derives from an ASCII text file - I'll leave that to a separate thread) > > Who needs to 'devise' a solution? We have one already - use fixed width ascii text. > > That's an 80% good solution that slowly, but surely becoming worse with the > computing world going proportional. You seem to assume just because people are adding more and more porportional fonts to thier systems that non-porportional text will cease to be a solution. Without making any further assumptions on my part, I just ask that you either accept or deny the above statement. > You missed my point completely. What I said was just the opposite: recipients > should spend zero effort on viewing ascii pics correctly. Everything else, > like forcing the recipient to install other fonts, change font settings > (non-proportional or proportional,) etc is brute force. But that's exactly what the recipient must do, if for example, they are sent a piece of artwork drawn with any font other than the ones the recipient has installed. So, regardless of what software they're using they still must aquire this font to see the artwork correctly. To me, that's just another way of a "brute force" solution - unless you can think of some way to make ASCII art (in any form) display correctly, regardless of the font (porportional or not, of any specific typeface) it was drawn in, and regardless of the fonts the recipient has on hand. > Again, you missed my point completely. What I said was just the opposite: > everyone, i.e. both makers and viewers of ascii art, use the Internet software > they are using anyway. Please reread my previous postings carefully on how to > do that by way of "piggybacking" as I call it. But by this "piggybacking" idea, there must be some way to translate what is "piggybacked" onto the media in question. If that media is HTML, then there must be some program that will correctly use the new/modified tags to display the artwork. If that media were just a normal newsgroup like this one, there must be some program that will display the artwork from some standardized format (UUENCODE or MIME, perhaps, since both will easily transport binary files of any type you can imagine). So any way yo slice it, SOMETHING has to be added. A program of some type has to be loaded on every computer that isexpected to view this new form of artwork (or if you prefer, this existing form, with a myriad of new typeographical settings). So which is it going to be? Require 100% of the users interested in ASCII artwork to load this new program (assuming thier computer can even run it)? Require 100% of the users interested in this artwork to download a series of fonts to be used with the above program? Or require 100% of the users interested in ASCII artwork to use a standard, fixed-spaced font, which they already have on thier computer regardless of the software they're using? The solution, however "brute force" seems quite obvious to me. Now, what about the future: When the Internet has become, say, 90% porportional and 10% fixed-spaced... What is the solution then? I still see the same three choices above - either install some new program, or add a variety of fonts in hopes that you can find the right one, or just keep using the usual fixed-spaced method. > > there is no way to have color,font,style, or size information in standard ascii. > > Now that I have here in front of me the list of all defined ascii codes, > > I don't see how you can stick fonts, sizes, styles, or colors into ascii code, > > nor, by extention, into ascii art. > > Aha, and this is a perfect opportunity to point out that ascii code alone is > not sufficient to make ascii art. You need a font, a font color, a contrasting > background color, etc that are in the realm of typography, outside the ascii standard. True, it needs a few typographical settings, BUT - the RECIPIENT is the one who gets to choose these settings, and none will have any effect on the correct display of the artwork (as longas one uses a little common sense of course)... You can change foreground and background colors to a good combination - the art is still ASCII art, because the file has not been modified from it's original 7-bit monochrome, fixed-spaced format. You can install any fixed-spaced font you want, and the art won't change (as long as the font is ASCII compliant of course). You can adjust the size and porportion of the font, and the artwork won't change any (by "porportion" I only mean the ratio of height to width, applied to the predetermined cell size common to all characters in the font). So my little 8x8 font could be blown up to twice it's height and half it's width, but the artwork being displayed won't change any - it'll just look funky because of the settings I chose to use - that font is still an 8x8 font. The same would be true if the font were a True-Type or other vector-oriented, scalable, fixed-spaced font such as Courier or Pica. But what you are proposing is that the ARTIST be the one in control of the settings - i.e. the artist adds colors, different typefaces, various kinds of distortions, or even graphical or line art (perhaps to make borders or flood-fill areas of a picture). Now, the RECIPIENT's machine and/or software has to be upgraded to handle all this stuff, whereas with the standardised fixed-spaced fonts and such that we are using now, the recipient simply needs to select the fixed-spaced font that his machine came with, and the artwork will look right no matter who drew it or what fixed-spaced font was in use at the time (with the few exceptions I mentioned of course). > Or to say things the other way around, to make ascii art, you need ascii code > AND ALWAYS things that are outside of the ascii standard. And you are free to > choose from a myriad of resources. If you disagree, please post a quote on the > prohibitions from the ascii standard. The prohibitions were already quoted, by him having shown you the standard ASCII chart. From my Webster's dictionary: Prohibit, v.t. 1, forbid. 2, prevent; hinder -- prohibitory, adj. Prohibition, n. act or effect of forbidding; [Remainder relates to the 18th Amendment] Prohibitive, adj. tending to preclude or discourage, as a high price. -- prohibitiveness, n. Seems to me that at least the third one quite nicely fits this discussion - the ASCII charts that have been posted quite easily discourage the use of non-ASCII characters (and by extension, the misuse or re-defintion of existing ASCII characters). And certainly the first one (prohibit) fits this newsgroup to a T. > > It seems that you're both sidestepping the obvious item that neither of you > > have copies of the standard. > > Thank you, thank you, I have the privilege of having access to an excellent > library, but indeed I could not find rfc 20 ;-) Had I known what the RFC number was, I'd have looked it up and quoted the relevant text. Now tell me - do you consider the RFC's to be the de-facto standards, as the other 99% of the Internet community (who knows what RFC's are for) does/do? > > When you type up your ascii image, it is ones and zeros in computer memory. > > When you save it, it is ones and zeros on magnetic disk. The ones and zeros > > are in the same sequence on disk as they were in memory, just as the now dry > > paint is in the same pattern, and has the same colors as it had when wet. > > > > The only difference it's not possible to make paint wet again for someone to > > modify it, and the only way to make as exact a copy of a painting as you can > > make of ascii art would be to hook up a robot arm to a computer with a camera, > > and have it dip a brush in accurately mixed paint and it in the exact same way > > as was done to make the original painting. > > I see no relevance of the above quotes to the discussion that we are having. He's talking about the ability to edit an image using the same tools from which is was created, and to reproduce exactly using the same tools from which it was created. In other words, it'S just as I said before, you can't import an ASCII text file into some other media like a GIF, edit it there, and then expect to call it ASCII art (even if you don't edit it). But take that ASCII text file, load it into a text editor, and edit it - it's still ASCII art then, since it's still copiable and editable using the same tools (or the same media) from which it was created. > > a space is still ascii 30, etc. If you take a screenshot of a piece of ascii A space is ASCII 32 actually. > Well, this is a repetition, and again, my contention is that it is ascii art > if it indeed shows what the ascii artist created, the means for displaying the > artwork does not matter. And again, please note that I am NOT talking about > reproductions here. Yes you are, if you're talking about displaying anything other than the original text file or an exact duplicate of it. I suppose by extension that makes every ASCII artwork a reproduction or a copy, since one can't easily move a file from one place to another without leaving a copy behind somewhere (unless you always loaded and saved it to a floppy disk or something). > > It does indeed contain those tables - anything not in those tables isn't ascii. > > Hah, and now we can't make ascii art at all, since fonts, font color, > background color, etc are not contained in those tables either! <sarcasm> Sarcasm as this statement might be, you still left out one key element - COMMON SENSE. > Well, present your curves and we can discuss them If you want to win this argument, you had better start posting quotations of your own as well. That includes displaying a good representation of a chart taken from some other souce than your own. For crying out loud, go look it up and prove your trends to us to be accurate. Do make us prove them wrong to you. > Viewing plain text is not good enough for ensuring that ascii pics are > rendered correctly, because the world is going proportional. It has been good enough for the last 20 years or more, and it will continue to be good enough far, FAR into the future, regardless of what you think the world is doing. > > Sure, *new* server software can handle 8 bit transmissions, but, as mentioned, > > most of the server software out there is not new. > > Well, that's the trend. And how long do you think it's going to take before EVERY SINGLE computer, server, and mainfraime (as well as everything else in between) that helps operate the Internet, becomes capable of any and all things you are proposing? Probably another 20-30 years. It took some 20 years (since the first computers were linked together to form the first incarnation of the Internet, the ARPANET) to come up with the HTML standard, and it'll probably take just as long to refine that standard into something that every computer on the Internet is capable of using. > Well, first of all, "dictate proportional" is brute force that I reject. > Please read my articles carefully. This is exactly what you are proposing by expecting some form of software to handle all of the problems of porportional and non-porportional fonts being used in ASCII artwork. You want the other 80% of the Internet to go porportional like the first 20% have (or whatever your original numbers were). So how, EXACTLY, is this supposed to happen? Show us your proposed standard, and prove it to be capable of working on any computer, no matter what type it is, no matter what kinds of fonts it has available (if any). And prove that it doesn't require even a minimal program to be installed on said computers, to make this standard viewable. I said it requires an extension program of some kind, you seem to be saying this is as much a brute-force idea as expecting everyone to stick with fixed-spaced fonts for ASCII art. So show is an idea (with details!) that is NOT brute force. > > The reason ascii is so widely used is the same reason people use ascii > > art - It works everywhere, and won't be harmed when internet news/mail > > servers truncate [the data to 7-bits wide.] > > These days, ascii art is harmed 20% of the time and becoming worse, because of > proportional, even if you call it brain-dead. But that does not mean that I > want to force the use of proportional, etc etc ... please read my articles carefully. What has truncating the data stream (from 8 or more bits to 7 bits) got to do with those 20% who are too lazy (or not sure of how) to switch to a fixed-spaced font? > > or only a few fonts. Only people installing new software have dozens and > > dozens of fonts. > > Almost right, but not quite. What I said was that everyone on the net should > be able to view ascii art correctly with his/her own Internet software, ... which is impossible to do given the wide range of programs people use to view ASCII art. Your proposal still requires some program to make the computer able to view any ASCII art image regardless of the fonts the artist used, and regardless of the fonts that the recipient has. Not to mention the number of platforms in use, most of which can't make any sense of a program written for another platform (again, without loading some kind of program to emulate or translate the program or the machinefor which it was written). > > Who wants to read lengthy articles? We just want to be able to open newsreader, > > and read ascii art, or open reader, and *type* ascii art. We don't want to have > > to deal with nonsense of detaching or attaching images. > > You missed the point here. The point of those lengthy articles is on zero > effort for the recipients and zero development efforts for the ascii community. > > Mainstream development will only care about ascii code for general usage, but > will not care about ascii art which is a special purpose. But we can piggyback > on mainstream, that's the point, please reread my articles carefully. So show us your proposed standard, which you personally guarentee that 100% of the ASCII community can use with zero effort (I'll discount the fact that one must download and install the required software to view this piggybacked standard) > I think that piggybacking on html will be a necessity to protect ascii art at > least several years down the road, although I won't do anything to push things > in this direction, mainstream development will run its own course. It seems to me that this was established with the first version of the HTML standard - the <PRE></PRE> tags to be exact. They're all one needs to "protect" ASCII artwork, since browsers already switch to a fixed-spaced font when they encounter these tags. I think what you need to think about then, is getting 100% of the ASCII community to start using new newsreaders and Email programs that can display HTML (or whatever method becomes the standard if plain fixed-spaced textfiles get phased out) > No, sending ascii code will continue as it has always had. But sending ascii > art needs to change if we want to be sure that the viewer sees it correctly in > this increasingly proportional world. Ah, so you are proposing a new standard. Great, let's see it. But until the day comes when a Sinclair, a Sunsparc, a VAX, a CrayXMP2, Commodore, Apple, Macintosh, IBM/PC clones, Unix/Linux boxes, NeXT, and any others I can't think of, can all run the same program and view the same fonts from the same multi-font source file, plain text will indeed remain standard, and need only two words to protect it -- COMMON SENSE. > Again, all those mainstream efforts will apply to ascii code, but > unfortunately that's not good enough for ascii art. As I said in the above, we The problem you seem to be refusing to accept with all of this is that any standard that uses somthing in the ASCII code set to define some new meaning, is no longer ASCII. HTML is based on ASCII of course, but it is not ASCII. If it were, there would ben some character in the ASCII set that's reserved for starting/ending HTML sequences. Code sets like ANSI and VT102 are a little closer, since the code used to start these sequences (ESCAPE, code 0x1B), is "hardware defined," which implies that it's defintion is allowed to be changed for whatever task is at hand. I will not say that these are ASCII, but they are at least closer, since they don't redefine some characters in the ASCII standard as HTML does (HTML redefines several characters like < & and > which already have established meanings which are contrary to thier use in HTML) > Thank you, I am sure in time you will like my writing as well, because it is > not rhetoric but good info. Good info, yes. Highly biased against a 20-year old standard (plain, unaccented, no-HTML, 7-bit, fixed spaced, monochrome ASCII text), definitely. -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > I did not miss any point, I am NOT talking about a reproduction either, > > Then what exactly do you call a GIF image of an ASCII art picture? > > The question is asked in a biased and suggestive way, anyway it is not a > reproduction, let me try again. Biased how? You claim that a GIF isn't a reproduction, and I am asking you what you call it, if it is something other than a reproduction (a duplicate, a copy, a facsimile (sp)) > it is a paper medium (printout) of the computer code, etc > they are all first hand renderings, NO reproductions. They are reproductions, because you are not using the original artwork anymore, you are using a reproduction of it. I won't argue further on whether a GIF is ASCII art or not, it's getting us nowhere. I agree, however, that it can *SHOW* ASCII art. > Because of that, and if I understand your writing further down correctly, you > contemplated to call the computer code the original of the ascii art and all > renderings are then copies of that original. Which by the definition of "reproduction", is correct. From my dictionary: Reproduce, v.t. 1, to make a copy of; duplicate. 2, procreate. 3, produce again. -- v.i. 1, beget; generate offspring. 2, be capable of being copied, as by printing. Reproduction, n. 1, act, process, or result of reproducting. 2, a copy, picture, etc. > Also again, there are no editing requirements for qualifying or disqualifying > ascii art, that you alluded to further down, please provide quote if you disagree. > > Also again, I am not talking about attachments at all, that you alluded to > further down. That's begging the issue altogether. I never once said you were talking about attachments of any kind. I said specifically, that the GIF standard (which I later refined to mean 89A rather than the older 87A) supports ASCII attachments. I said further that those attachments in themselves are ASCII. I also said that you could use said attachments, but not that you specifically were. I stated a possibility, not a actual event (etc). > > > > The standard is in rfc 20. > > > Strange, I digged into the IETF archives, I did not find rfc 20. > > Probably because the standard is so old - your archives may not necessarily > > go back far enough. > > I searched the IETF archives on the web, which contains all active RFCs, if > the RFC is is not publicly accessible, it is not a standard. Note that I didn't say anything regarding RFC20 (Except the above saying the standard may be too old to locate on the 'net) - I'll leave that up to the other guy in this thread to shed some light on it's whereabouts. > Answering your question further down: yes, I do consider RFCs de-facto > standards, although as far as ascii art goes, the authorative standard should > be the ascii standard itself rather than an RFC. The RFC's are what *DEFINE* the standards in use today for the net, not the other way around. The RFC's do not simply follow some accepted standard or offer explainations for the standard. They *DEFINE* it. In the case of ASCII art, that would suggest that RFC-20 is the official definition of the ASCII code set and control code meanings. I believe these have already been posted and discussed by myself as well as another user here. > But the context here, is that a standard with all kinds of prescriptions, > prohibitions, code storage requirements, etc would never have achieved this > kind of widespread acceptance. Umm... The GIF format is defined by a set of standards (which I guess CompuServe used to own, now someone else does?). In fact you're supposed to purchase a license to write data into GIF format as I am told. So this makes the GIF format "a standard with all kinds of prescriptions, prohibitions, code storage requirements, etc." Yet, the GIF format is/was by far the most popular image format around (with JPG quickly catching up). How do you explain your statement in reference to this? Just because there is a standard, with certain limitations, doesn't mean that said standard won't become popular or even commonplace. > > The standard itself (i.e. being a standard at all) is what defines that it > > be displayed on a text screen (or in a text editor, or on a printout, which > > was probably the common "display" method when RFC20 was proposed). > > Are you now referring to rfc20 (and not to the ascii standard) because it is > not accessible? Sorry, could't resist. I am refering to the ASCII standard as most people see it. I am not referring to RFC-20 in this case, because I don't know anything about it. Instead, I am using simple common sense. > Anyway, I have asked several times for quotes, but you posted no quotes sofar. And I have asked you to post quotes refuting these observations, which you have so far REFUSED to (by stating the burden of proof incorrectly lies on me and others, when you are the one proposing things that are outside our capabilities or purposes). > Anyway again, the ascii standard does not prescribe you to render ascii code > with an elementary text editor, you are free to use the most advanced word > processor, the most advanced graphic software, etc. By this I meant that a text editor is more or less the least amount of software you need to create ASCII art and plaintext. > By the same token, there would be no ascii art at all, because ascii code > alone is not sufficient to generate pictures. You always need typographical > code to generate the pictures, such as font face, font size, font color, > background color, spacing between characters, spacing between lines, etc. This could be argued, but now you are talking about fighting simple common sense here. In other words, now you're nitpicking. > In other words, it is always absolutely essential that you add code that are > outside of the ascii standard, i.e. code that is NOT contained in the ascii > code table, to generate ascii art. You are not adding any code in any shape, form, or fashion, to your artwork by using some specoific typeface and color combination that suits your tastes. The artwork you create will still display right no matter what (provided it is still within the definitions we've already discussed). > Now, where do you draw the line with adding code? My answer is: draw no line. You draw the line when you add any non-ASCII code to the artwork that alters the appearence of the artwork itself. I don't see a problem with adding a clear-screen code to the top of a piece of artwork, for example. But, because of brain-dead software that runs half of the Internet, that code would probably not make it through anyways. > > You seem to assume just because people are adding more and more > > porportional fonts to thier systems that non-porportional text will cease > > to be a solution. > > No, what I said is that 20% are actually set to proportional and that damages > ascii art in a .txt medium. And the 20% is slowly, but surely growing. Please > note, that I said ascii art. NO, what you said was that the 20% of porportional users are growing, and the 80% is declining. There is a trend, and trends tend to continue if they are a good thing at all. By extension (and by not saying there is a likely stopping point), you were saying that non-porportional use would pretty much be phased out within some likely (and quite short) time period. This is especially the concern for ASCII art. Again, by extension (of those graphs you posted for examaple), ASCII art as a 100% portable media would be phased out. > There is no problem for non-proportional text (or proportional text, for that > matter.) Please note, that I said text. (This is also to respond to your > question further down.) Right, when it comes to ordinary text, formatting and other font-specific capabilities are not as much an issue. I doubt anyone will complain if you send a text file and it is displayed in a font other than intended. It still conveys the message. > > But that's exactly what the recipient must do, if for example, they are sent > > a piece of artwork drawn with any font other than the ones the recipient has > > installed. > > No, software can do that automatically (with typographical tags and the like), > that's what I meant with zero effort on the part of the recipient (in contrast > to a brute force solution.) And of course, a skillful ascii artist will > neither work with nor specify an obscure font. WHAT software???? I thought you said there was ZERO EFFORT? Doesn't the recipient have to install something? Unless you're proposing HTML (which you seem to lean away from I've noticed), you're creating a problem by requireing yet another piece of software to be installed on 100% of the machines and all of the dozens of platforms out there, for all who want to see your new form of artwork. > Aha, finally a visionary! The most likely scenario that I see, is that at that > time of 90% proportional and 10% fixed-spaced, html aware software will also > be widespread. HTML is already very widespread, and perhaps by the time this time rolls arond, news and email readers will have the capability as standard (Even the version of Pine I use now handles HTML just fine). But you are forgetting that there are doszens of platforms and (tens or even hundreds of) thousands of computers that would need to be upgraded. Who's going to write the needed HTMl software to read news and Email in HTML format on all of these platforms? What happened to ZERO EFFORT (by either the end users or the people who want the new standard to really be a standard)? > Initially, you could just use non-proportional font, etc although that would > not be taking advantage of the full potential of the html medium. I am pretty > sure that the ascii art community will soon add color, motion, and the like. > It is already doing that on webpages. Yeah, but on web pages, it's all fluff anyways. Most of the crap I've seen is just flashy stuff to get your attention, and detract from the overall usefullness of the page. (Yes, I've used graphical browsers on some very modern machines, and still prefer Lynx for most stuff - no distractions) > There you got it right, of course I want the artist in full control, and of > course I want to make sure that the recipient looks at what the artist > created, without any distortions! But there is simply NO WAY for this to happen, now or in the future, unless someone handles writing the needed software for every internet capable platform out there. I'm trying to tell you NO ONE will do it. Sure people will write stuff for PC's, Mac's, and maybe Linux/Unix - but what about the dozens of proprietary platforms out there? > But the broader context of the issue at hand is not that, I believe. The > broader context has to do with using ascii code in full compliance alright, > but then adding typographical and other code that you have to do anyway. And > very, very soon after the basics are covered, you want to pull the plug, > whereas I don't. The basics are covered and have been for 20 years. Like I said, you are NOT ading any kind of code to an ASCII picture when you set your default font and color settings - these are only used for your system to display what you are creating. When you save it, that artwork is ASCII art and contains no code of any kind specifying anything you are using on your computer. When that code reaches the recipient, it is displayed using his or her default settings (even if they are wrong). There's still nothing in the code saying to use this or that font, or switch to a specific set of colors (unless that ASCII artwork is imported into another format somewhere along the line, HTML perhaps) Specifying typographical settings like colors, or specific typefaces is not done from within the picture, it is done completely and totally outside the picture, for your viewer program only (well, perhaps for your whole system depending on the system you use). Those settings do not affect in any way, shape, or form, how the artwork will be displayed on the recipient's screen. What you are proposing (letting the artist specify fonts and color, and so on) does add stuff to the picture, in the form of font tags, color codes, or whatever the format in question is using. When that code reacies it's target (the recipient), it will be displayed, and will be displayed right only if the recipient has everything the artist has, in the way of typographical capabilities (this especially includes specific fonts at specific sizes). > > If you want to win this argument, you had better start posting quotations of > > your own as well. That includes displaying a good representation of a chart > > taken from some other souce than your own. > > Oh, I post my views based on their own merits, and it is up to you and others > to shoot them down, sofar they still stand. Your views do not stand in this newsgroup. Your views mave no merit at all, if you can't back them with proven facts or quotations. At least I've backed what I have to say with proven facts, and a few quotations (the except of the ASCII chart I posted, and the definitions I had to clarify from ym dictionary). My viewes aren't necessarily facts either, but they are supported by facts, and are accepted by this newsgroup and probably the rest of the ASCII community as well (I could just as easily say that I agree with everyone else, and that I am simply relating info that is and has been established for 20 years). > > I think what you need to think about then, is getting 100% of the ASCII > > community to start using new newsreaders and Email programs that can display > > HTML (or whatever method becomes the standard if plain fixed-spaced > > textfiles get phased out) > > Aha, almost true, only that it's not me, but mainstream development that will > take care that users will increasingly use html aware software running on html > capable platforms. And that in turn will increase the portability of ascii > pics in a .html medium. Yeah, but at this exact moment, it is *YOU* who are prescribing that the ASCII community try to take the leap forward now, by using HTML-aware newsreaders and Email programs. > > Ah, so you are proposing a new standard. Great, let's see it. > > No, I proposed piggybacking on mainstream developments, see above. You still have yet to define this piggybacking scheme. If my guess is right, you are actually poposing to simply take advantage of the mainstream developments. This isn't piggybacking. Piggybacking by definition (in the context here) means to add to some existing method in a way that will not disturb a recipient who cannot use the added data. Example: Color TV broadcasts. They add a 3.84 some MHz color carrier on top of the existing black and white signal, and yet even the oldest black and white TV will still show the black and white portion of the picture without the colors getting in the way. The format method that defines this is NTSC, and there are others as well, like PAL or HDTV. All are standard, none are 100% compatible with one another. > But ascii art has at least two components, ascii code and typographical code, ASCII art still requires only CODE element. The ASCII code standard (perhaps as defined by RFC-20? I'd like to see it just for the purpose of seeing it). Typographical settings not embedded into the picture are not code in any way or form (except with in the editor program); they are simply display settings that make it easier for the artist to see what he is doing. If he is sending a pure ASCII file with no font/color/etc codes, then the recipient has only one job, use the widely accepted standard to display that artwork - a 7-bit fixed-spaced font. In other words, the job lies with the recipient to select the font type (fixed-spaced) that 99.99% of ASCII artists use. > component is always OK, but the latter component is screwed up 20% of the time > at the recipient's end and getting worse. Well we are getting repetitive here. Yes we are, and I'll just end this little bit by stating this (you already disagree, but I refuse to argue this point anymore): If the user doesn't know how to change thier settings appropriately for this newsgroup (and for ASCII art in general), they they need to learn how. If they know how and wont, they're too damned lazy. It's just a few mouse clicks away for many, for others a single command at the command line to install the right font, will do. If you can't move your right hand around your desk and press a button a few times, you probably need to seek medical attention or get the hell away from your computer. > Ha ha ha, that sounds quite humorous to me, since I use that ancient standard > quite extensively. I think I know its capabilities well, and those are much > more tremendous than you may think. You know it's capabilities all right, but you are confusing them with the capabilities that other media (such as HTML) offer. ASCII alone, without all the markup tags and crap, is capable of displaying some very good artwork, and conveying most any idea you want, but not much beyond that. And it is that low amount of capability (compared to other media) that made ASCII so popular and so portable - you don't need anything fancy to use it. No special browsers, no custom fonts, nothing. Just your system's default fixed-spaced font and a command to view a text file. -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Because of that, and if I understand your writing further down correctly, you > > contemplated to call the computer code the original of the ascii art and all > > renderings are then copies of that original. > > Which by the definition of "reproduction", is correct. (Actually, you continued the discussion ...) By the same token, you would define a .txt rendering a reproduction also, I am not sure I agree with that. I myself have called them ascii art in gif format, ascii art in txt format, etc which is a lot simpler. No special designation for a gif rendering as an original or reproduction, no special designation for a txt rendering as an original or reproduction, etc. > The RFC's are what *DEFINE* the standards in use today for the net, not the > other way around. The RFC's do not simply follow some accepted standard or > offer explainations for the standard. They *DEFINE* it. Well, defining what standards to use is a standard in itself. It is quite common practice for standards to refer to other standards. > (perhaps as defined by RFC-20? I'd like to see it just for the purpose of > seeing it). The RFC 20 tossed up by someone in this thread is probably an invalid trial balloon. It can't be found in the IETF archives, and the other RFCs tossed up by that same someone are irrelevant to this discussion. Just to confirm, the good old ascii standard is still the authorative document for ascii art. > Just because there is a standard, with certain limitations, doesn't mean > that said standard won't become popular or even commonplace. I did not say that in this context. I said in the context of the ascii standard that it does not contain any of the prohibitions, etc that you tossed up (and that it indeed became popular exactly because of the lack of those prohibitions, etc) > > Anyway, I have asked several times for quotes, but you posted no quotes sofar. > > And I have asked you to post quotes refuting these observations, which you > have so far REFUSED to (by stating the burden of proof incorrectly lies on > me and others, when you are the one proposing things that are outside our > capabilities or purposes). It is not possible to post quotes on prohibitions, etc that do not exist. So the point is that I don't refuse, the point is that I can't post quotes that do not exist. It is you who tossed up prohibitions, etc so the onus is on you to post those pertinent quotes. This should be well within your capabilities if you did not grab those prohibitions, etc out of the blue sky. The motivation for asking for the quotes is not to aggravate you. It is a way for saying: don't take my word for it, but to look for yourself and convince yourself that those prohibitions, etc are not contained in the ascii standard at all. Now that you can't show that the ascii standard contain those prohibitions, etc you want to go by common sense. The fallacy to go by common sense it that everyone has a different definition on what common sense is. That's exactly the reason for having a standard. > By this I meant that a text editor is more or less the least amount of > software you need to create ASCII art and plaintext. True, but the ascii standard does not prohibit you from using more sophisticated tools either. The other extreme is to use no software at all and render ascii art by hand, the ascii standard does not prohibit you from doing that either, ha ha ha! I have (ironically) suggested that kind of extreme self-limiting behaviour before! (Just to get the point across at that time.) > > Now, where do you draw the line with adding code? My answer is: draw no line. > > You draw the line when you add any non-ASCII code to the artwork that alters > the appearence of the artwork itself. I don't see a problem with adding a > clear-screen code to the top of a piece of artwork, for example. But, > because of brain-dead software that runs half of the Internet, that code > would probably not make it through anyways. If you don't add any non-ascii code (in the form of typographical code,) the ascii artwork won't even appear! That's not nitpicking, that's a fact! And the brain-dead software is, like it or not, what enables you to view ascii art across the net with a good portability of 80% right now. > This is especially the concern for ASCII art. Again, by extension (of those > graphs you posted for examaple), ASCII art as a 100% portable media would be > phased out. You quoted me a couple of times in the above and in so doing, overstated what I said. Referring to the above quote for example, what I said was that ascii art in a .txt medium (I emphasize "in a .txt medium") is only 80% portable at the moment and declining. But I also said that ascii art can survive in other media, whose portability are at a low 20% (or even lower) right now, but improving with time. Wow! That was a central point! > I thought you said there was ZERO EFFORT? Doesn't the recipient have to > install something? Unless you're proposing HTML (which you seem to lean > away from I've noticed), you're creating a problem by requireing yet another > piece of software to be installed on 100% of the machines and all of the > dozens of platforms out there, for all who want to see your new form of > artwork. Yes, zero effort indeed. The recipient uses Internet software that s/he uses for all of his/her activities on the net anyway (i.e. by the time this rolls around as you put it further down,) and thus, zero effort for ascii art. And no, I am still html friendly, although I personally have already left it behind me in favor of other, even more capable media! > HTML is already very widespread, and perhaps by the time this time rolls > arond, news and email readers will have the capability as standard (Even the > version of Pine I use now handles HTML just fine). Good, good, and the time this rolls around for the majority of the net is at least several years from now on, no disagreement here. > But there is simply NO WAY for this to happen, now or in the future, unless I thought that you yourself suggested that the simple <pre> and </pre> tags already solve nearly all of the complications that you identified? > What you are proposing (letting the artist specify fonts and color, and so > on) does add stuff to the picture, in the form of font tags, color codes, or > whatever the format in question is using. When that code reacies it's > target (the recipient), it will be displayed, and will be displayed right > only if the recipient has everything the artist has, in the way of > typographical capabilities (this especially includes specific fonts at > specific sizes). Well, a skillful artist will not use obscure fonts or obscure anything, you can always produce bad things with good tools. Nevertheless, for other reasons I have guestimated the portability of ascii art in a .html medium at a low 20% right now, but improving. > Your views do not stand in this newsgroup. I contend they do, I am slowly, but surely opening eyes! Some people are beginning to recognize, that perceived limitations are in reality just barnacles from the past, due to historical and limited implementations. The ascii standard itself imposes no such limitations! Of course, as always in moving forward, there are people wanting to maintain the status quo. The best indicator that I am opening eyes, is that the adrenaline is running high in those status quo guys! ;-) > Your views mave no merit at all, if you can't back them with proven facts or > quotations. My views do have merit, because I did back them up with proven facts and clearly observable trends. (Although I indeed can't post quotes that don't exist ;-)) I even have a website where I have practised those views. Of course, the advanced implementations have only the 20% portability that I was talking about, for example, you do need a graphical browser, but the portability will improve :-))) > At least I've backed what I have to say with proven facts, and a few No, you did not back up the prohibitions, etc that you tossed up, you did not post quotes on the prohibitions, etc from the ascii standard! > My viewes aren't necessarily facts either, No, they aren't. In particular, there are no such prohibitions, etc in the ascii standard, my friend! > > Aha, almost true, only that it's not me, but mainstream development that will > > take care that users will increasingly use html aware software running on html > > capable platforms. And that in turn will increase the portability of ascii > > pics in a .html medium. > > Yeah, but at this exact moment, it is *YOU* who are prescribing that the > ASCII community try to take the leap forward now, by using HTML-aware > newsreaders and Email programs. Not true about me prescribing anything, read my quote in the above carefully. I have explicitly said that mainstream development will take care of that, not me, and mainstream will develop at its own pace, not set by me either. (Gosh, how could it possibly be that I have such great influence? Even my pathologically enlarged ego does not allow me to believe THAT!) > If my guess is right, you are actually poposing to simply take advantage of > the mainstream developments. This isn't piggybacking. Alright, use a different name if you like, I happen to use the name piggybacking. But I don't discuss names, I discuss concepts. What I meant with piggybacking is for example using the .html medium for protecting ascii art, whether you want to call that taking advantage of mainstream developments or otherwise (OK, what short name would you like to use?) > When that code reaches the recipient, it is displayed using his or her > default settings (even if they are wrong). Yes, and these days, that's wrong 20% of the time and getting worse. I wonder, sometimes you recognize this central issue, sometimes you want to discuss it away! See the following quote. > ASCII art still requires only CODE element. It is exactly the denial that the other (typographical) code element exist, that is like putting your head in the sand. It is exactly the other code element that causes 20% troubles and becoming worse. The ascii code element itself does not cause any problems. > Yes we are, and I'll just end this little bit by stating this (you already > disagree, but I refuse to argue this point anymore): > If the user doesn't know how to change thier settings appropriately for (Actuality, you continued to discuss ...) Well, what shall I say, you are probably not in a consumer friendly business, or else you would not ask the viewer to spend any effort, and if they refuse to do so, call them names! > You know it's capabilities all right, but you are confusing them with the > capabilities that other media (such as HTML) offer. ASCII alone, without > all the markup tags and crap, is capable of displaying some very good > artwork, and conveying most any idea you want, but not much beyond that. Almost right, but I am not confusing anything, I just don't pull the plug that quickly on ascii's capabilities. > And it is that low amount of capability (compared to other media) that Just don't pull the plug that quickly, and you too will see ascii's tremendous capabilities. Try it, you won't be disappointed as a pioneer, I can assure you! ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> > I did not miss any point, I am NOT talking about a reproduction either, > Then what exactly do you call a GIF image of an ASCII art picture? The question is asked in a biased and suggestive way, anyway it is not a reproduction, let me try again. It is a gif rendering of the computer code, it is a .txt rendering of the computer code, it is an any xyz medium rendering of the computer code, it is a paper medium (printout) of the computer code, etc they are all first hand renderings, NO reproductions. The rendering process may preserve the ascii code in the computer code such as in a .txt medium, the rendering process may change the ascii code in the computer code such as in a .gif medium, but both renderings show ascii art and are ascii art, and remain ascii art in much the same way that paint material changes from liquid to solid, but painting remains painting. And again, I use in this context the words "show" and "are" interchangeably, because the computer code itself is not visible, one always has to render it to make it visible. It is important that ascii art is visible, I guess :-) Because of that, and if I understand your writing further down correctly, you contemplated to call the computer code the original of the ascii art and all renderings are then copies of that original. It is perhaps possible to pull such a naming convention through on a logical basis, but I myself can't see the benefit of such a naming convention at all. ascii art (and I myself as well) almost always work at the visual level, rarely ever at the computer code level. Keeping things simple, I therefore call it ascii art in gif format, ascii art in txt format, an ascii art printout, etc. Also again, there are no editing requirements for qualifying or disqualifying ascii art, that you alluded to further down, please provide quote if you disagree. Also again, I am not talking about attachments at all, that you alluded to further down. That's begging the issue altogether. > > > The standard is in rfc 20. > > Strange, I digged into the IETF archives, I did not find rfc 20. > Probably because the standard is so old - your archives may not necessarily > go back far enough. I searched the IETF archives on the web, which contains all active RFCs, if the RFC is is not publicly accessible, it is not a standard. Answering your question further down: yes, I do consider RFCs de-facto standards, although as far as ascii art goes, the authorative standard should be the ascii standard itself rather than an RFC. But the context here, is that a standard with all kinds of prescriptions, prohibitions, code storage requirements, etc would never have achieved this kind of widespread acceptance. > The standard itself (i.e. being a standard at all) is what defines that it > be displayed on a text screen (or in a text editor, or on a printout, which > was probably the common "display" method when RFC20 was proposed). Are you now referring to rfc20 (and not to the ascii standard) because it is not accessible? Sorry, could't resist. Anyway, I have asked several times for quotes, but you posted no quotes sofar. Anyway again, the ascii standard does not prescribe you to render ascii code with an elementary text editor, you are free to use the most advanced word processor, the most advanced graphic software, etc. > Where is it wrttten that a GIF image has to be viewed with a GIF viewer? I realize that you meant the question to be rethoric, but that's exactly on one of my points, complementary to the above paragraph and I therefore take the question to be non-rethoric, and here is the answer: Nowhere is that written, you are free use the most sophisticated software, not just an elementary gif viewer. > But it isn't, if the colors have been changed, or if the picture has been > altered in any way beyond a reasonable amount. The artist (most likely) > created a black and white picture with ASCII code, and stored, transmitted, > and edited that picture using nothing but ASCII code. > > It's colorized artwork, which has to now fit the definition of the media > which makes those colors possible. Hence, it might be just "text art" or > "HTML art". It isn't ASCII art anymore, not according to the standard which > was just posted. By the same token, there would be no ascii art at all, because ascii code alone is not sufficient to generate pictures. You always need typographical code to generate the pictures, such as font face, font size, font color, background color, spacing between characters, spacing between lines, etc. In other words, it is always absolutely essential that you add code that are outside of the ascii standard, i.e. code that is NOT contained in the ascii code table, to generate ascii art. Now, where do you draw the line with adding code? My answer is: draw no line. > You seem to assume just because people are adding more and more > porportional fonts to thier systems that non-porportional text will cease > to be a solution. No, what I said is that 20% are actually set to proportional and that damages ascii art in a .txt medium. And the 20% is slowly, but surely growing. Please note, that I said ascii art. There is no problem for non-proportional text (or proportional text, for that matter.) Please note, that I said text. (This is also to respond to your question further down.) The above two paragraphs concern two entirely different topics. > But that's exactly what the recipient must do, if for example, they are sent > a piece of artwork drawn with any font other than the ones the recipient has > installed. No, software can do that automatically (with typographical tags and the like), that's what I meant with zero effort on the part of the recipient (in contrast to a brute force solution.) And of course, a skillful ascii artist will neither work with nor specify an obscure font. > Now, what about the future: When the Internet has become, say, 90% > porportional and 10% fixed-spaced... > > What is the solution then? I still see the same three choices above - > either install some new program, or add a variety of fonts in hopes that you > can find the right one, or just keep using the usual fixed-spaced method. Aha, finally a visionary! The most likely scenario that I see, is that at that time of 90% proportional and 10% fixed-spaced, html aware software will also be widespread. Initially, you could just use non-proportional font, etc although that would not be taking advantage of the full potential of the html medium. I am pretty sure that the ascii art community will soon add color, motion, and the like. It is already doing that on webpages. I hear people jumping up and down at this point, so let me quickly add that that will not happen on usenet for at least several years. Further down you suggested 20 to 30 years, that may get the adrenaline down a bit, but I personally think that the net will develop faster than that. > But what you are proposing is that the ARTIST be the one in control of the > settings - i.e. the artist adds colors, different typefaces, various kinds > of distortions, or even graphical or line art (perhaps to make borders or > flood-fill areas of a picture). There you got it right, of course I want the artist in full control, and of course I want to make sure that the recipient looks at what the artist created, without any distortions! (Although the initial driving force will not be the items that you mentioned. The initial driving force will be bare bones protection of ascii pics in an increasingly proportional world.) > The prohibitions were already quoted, by him having shown you the standard > ASCII chart. From my Webster's dictionary: A prohibition is worded like this: "It is prohibited ..." whereas the ascii chart is a prescription on the codes. Big difference! But the broader context of the issue at hand is not that, I believe. The broader context has to do with using ascii code in full compliance alright, but then adding typographical and other code that you have to do anyway. And very, very soon after the basics are covered, you want to pull the plug, whereas I don't. > If you want to win this argument, you had better start posting quotations of > your own as well. That includes displaying a good representation of a chart > taken from some other souce than your own. Oh, I post my views based on their own merits, and it is up to you and others to shoot them down, sofar they still stand. > You want the other 80% of the Internet to go porportional like the first 20% > have (or whatever your original numbers were). No, thanks, no brute force. > It seems to me that this was established with the first version of the HTML > standard - the <PRE></PRE> tags to be exact. They're all one needs to > "protect" ASCII artwork, since browsers already switch to a fixed-spaced > font when they encounter these tags. Yes, I indeed think that these two tags alone will cut through most of the complexities that you mentioned. > I think what you need to think about then, is getting 100% of the ASCII > community to start using new newsreaders and Email programs that can display > HTML (or whatever method becomes the standard if plain fixed-spaced > textfiles get phased out) Aha, almost true, only that it's not me, but mainstream development that will take care that users will increasingly use html aware software running on html capable platforms. And that in turn will increase the portability of ascii pics in a .html medium. Vice versa, the portability of ascii pics in a .txt medium will decrease, because more and more recipients will have their software actually set to proportional (please note, not *can* set, but *actually* set, and no, thanks, no brute force.) I don't think that you need 100% portability to switch. I think that the ascii community will begin to switch if the portability of ascii pics in the .txt medium falls below the portability in the .html medium. Or in plain English, if every other guest (not 100% of the guests) posts the question "I see garbage" then that's when the community will switch. > Ah, so you are proposing a new standard. Great, let's see it. No, I proposed piggybacking on mainstream developments, see above. > The problem you seem to be refusing to accept with all of this is that any > standard that uses somthing in the ASCII code set to define some new > meaning, is no longer ASCII. I am not proposing to change the coding table. I was referring to how ascii code is used for all kinds of computing applications and that mainstream efforts address their own issues. And I contend that they have the easier task, since all they have to deal with, is a single component, ascii code. But ascii art has at least two components, ascii code and typographical code, and that makes the task more difficult for the ascii art community. The former component is always OK, but the latter component is screwed up 20% of the time at the recipient's end and getting worse. Well we are getting repetitive here. > Good info, yes. Highly biased against a 20-year old standard (plain, > unaccented, no-HTML, 7-bit, fixed spaced, monochrome ASCII text), > definitely. Ha ha ha, that sounds quite humorous to me, since I use that ancient standard quite extensively. I think I know its capabilities well, and those are much more tremendous than you may think. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
> RFC20 is listed in the rfc-data.txt as having the title > "ASCII format for network interchange", and is the only RFC that I saw Even with the additional info, RFC20 could not be located on the IETF website. But that is to be expected, because if RFC20 were in the database at all, then typing "RFC20" into the search engine will undoubtly produce the document, just like the other RFC documents. I am positive now, that RFC20 has been phased out and has been taken off the public archives on the web. But the original ascii standard is the authorative document for ascii art anyway, we are in no way orphans. > As for the other RFCs I "tossed up", the were SARCASM. Tossing up irrelevant and phased out RFCs makes you look obtuse indeed. > The fact remains, regardless of what fonts the artist uses, the viewer will need > to have those fonts on their computer. Not if font substitution maps are used. > |> Some people are beginning to recognize, that perceived limitations are in > |> reality just barnacles from the past, due to historical and limited > |> implementations. The ascii standard itself imposes no such limitations! > Either give us a quote showing that there are no such limitations, > or concede the argument that the ascii standard limits ascii to the being > 7 or 8 bit text in the range 0x20 to 0xFF. The ascii standard does not contain any quotes along the lines of "It is limited to ..." If you disagree, please post quote, I can't post a quote that does not exist. The coding table merely defines ascii code. It does not define any limitations, no need to concede anything. The context of this exchange is that ascii code alone is not sufficient for ascii art. You need to add typographical code, or the artwork won't even appear! And since you must add code, there is no reason for pulling the plug so soon, there is no reason to inflict limitions on ourselves. > Hmm, I seem to have missed these so called "proven facts" - could you repost > them, along with names and references of who proved them? All my views were backed up with proven facts, if you disagree, please identify which view and we can discuss. > <PITY FOR OBTUSE PETE> > He obviously *meant* that his views were opinions, not facts, > whereas you seem to be claiming that you views are facts, not opinions. > </PITY> Thank you, thank you, for the pity, but I think you need the pity more than me. But indeed, I claim to state facts. > |> It is exactly the denial that the other (typographical) code element exist, > |> that is like putting your head in the sand. It is exactly the other code > |> element that causes 20% troubles and becoming worse. The ascii code element > |> itself does not cause any problems. > You are *partially* right - it is a denial that typographical code is part of > the ascii character set; There are no ascii characters to specify any sort > of typography. Any type of code that does so specify typography is not ascii. I have never said that typographical code is part of the ascii character set. What I said was that typographical code (such as font) is part and parcel of ascii art. Big difference! Try to apply the generic ascii knowledge base to ascii art specifically, or alternatively, reread my articles carefully, I have stated these things very explicitly, very clearly and quite often as well. > |> Well, what shall I say, you are probably not in a consumer friendly business, > |> or else you would not ask the viewer to spend any effort, and if they refuse > |> to do so, call them names! > He's not the one trying to promote some new definition of an old term, so he's > allowed to call lazy people "lazy" if he wants to. Well, the point is that it is utterly inconsequential whether 1 person asks the other 10,000 persons to spend effort to view their work. The ascii artist is still lucky that that represents only 20% of the net (prorated of course.) But the situation is worsening. > How is "ASCII alone ... is capable of displaying some very good artwork ..." > pulling the plug on ASCII's capabilities? Because it can do even more, much more! > You must be thinking of something other than ascii I am thinking of ascii art > - simply by writing his message > to usenet is a use of ascii. What is it that you want him [and the rest of us, I > assume] to do with ascii that we're not already doing? Please reread my articles carefully, I have said things again and again and again, such as me not wanting to do anyone to do anything, mainstream will take care of all those developments! (I have indeed invited him to be a pioneer, but that's something different) ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
In article <360...@sympatico.ca>, Pete Casso <pet...@sympatico.ca> writes: [snip] |> The RFC 20 tossed up by someone in this thread is probably an invalid trial |> balloon. It can't be found in the IETF archives, and the other RFCs tossed up |> by that same someone are irrelevant to this discussion. RFC20 is listed in the rfc-data.txt as having the title "ASCII format for network interchange", and is the only RFC that I saw listed as being relevant - Simply because you could not find the file does not mean that I made it up [Search for the title I mentioned in the "rfc-data.txt" file in the same directory as your rfcs are in, and you will indeed see that it is the title of RFC 20. If you cannot *find* RFC 20, then you aren't looking hard enough] As for the other RFCs I "tossed up", the were SARCASM. It is perhaps a bit saddening that you cannot recognize sarcasm without <SARCASM></SARCASM> tags around it. The point of mentioning the April Fools RFCs was to compare the absurd things you were describing with the absurd things in those RFCs. |> > What you are proposing (letting the artist specify fonts and color, and so |> > on) does add stuff to the picture, in the form of font tags, color codes, or |> > whatever the format in question is using. When that code reacies it's |> > target (the recipient), it will be displayed, and will be displayed right |> > only if the recipient has everything the artist has, in the way of |> > typographical capabilities (this especially includes specific fonts at |> > specific sizes). |> |> Well, a skillful artist will not use obscure fonts or obscure anything, you |> can always produce bad things with good tools. The fact remains, regardless of what fonts the artist uses, the viewer will need to have those fonts on their computer. |> Some people are beginning to recognize, that perceived limitations are in |> reality just barnacles from the past, due to historical and limited |> implementations. The ascii standard itself imposes no such limitations! Either give us a quote showing that there are no such limitations, or concede the argument that the ascii standard limits ascii to the being 7 or 8 bit text in the range 0x20 to 0xFF. |> > Your views mave no merit at all, if you can't back them with proven facts or |> > quotations. |> |> My views do have merit, because I did back them up with proven facts and |> clearly observable trends. (Although I indeed can't post quotes that don't |> exist ;-)) Hmm, I seem to have missed these so called "proven facts" - could you repost them, along with names and references of who proved them? |> No, you did not back up the prohibitions, etc that you tossed up, you did not |> post quotes on the prohibitions, etc from the ascii standard! And you didn't post a quote from the standard saying that there are no prohibitions. |> > My viewes aren't necessarily facts either, |> |> No, they aren't. In particular, there are no such prohibitions, etc in the |> ascii standard, my friend! <PITY FOR OBTUSE PETE> He obviously *meant* that his views were opinions, not facts, whereas you seem to be claiming that you views are facts, not opinions. </PITY> |> > When that code reaches the recipient, it is displayed using his or her |> > default settings (even if they are wrong). |> |> Yes, and these days, that's wrong 20% of the time and getting worse. I wonder, |> sometimes you recognize this central issue, sometimes you want to discuss it |> away! See the following quote. |> |> > ASCII art still requires only CODE element. |> |> It is exactly the denial that the other (typographical) code element exist, |> that is like putting your head in the sand. It is exactly the other code |> element that causes 20% troubles and becoming worse. The ascii code element |> itself does not cause any problems. You are *partially* right - it is a denial that typographical code is part of the ascii character set; There are no ascii characters to specify any sort of typography. Any type of code that does so specify typography is not ascii. |> Well, what shall I say, you are probably not in a consumer friendly business, |> or else you would not ask the viewer to spend any effort, and if they refuse |> to do so, call them names! He's not the one trying to promote some new definition of an old term, so he's allowed to call lazy people "lazy" if he wants to. |> > You know it's capabilities all right, but you are confusing them with the |> > capabilities that other media (such as HTML) offer. ASCII alone, without |> > all the markup tags and crap, is capable of displaying some very good |> > artwork, and conveying most any idea you want, but not much beyond that. |> |> Almost right, but I am not confusing anything, I just don't pull the plug that |> quickly on ascii's capabilities. How is "ASCII alone ... is capable of displaying some very good artwork ..." pulling the plug on ASCII's capabilities? |> |> > And it is that low amount of capability (compared to other media) that |> |> Just don't pull the plug that quickly, and you too will see ascii's tremendous |> capabilities. Try it, you won't be disappointed as a pioneer, I can assure you! You must be thinking of something other than ascii - simply by writing his message to usenet is a use of ascii. What is it that you want him [and the rest of us, I assume] to do with ascii that we're not already doing? |> |> ========================================================= |> [] .oo Visit the Gallery of the 'steins! [] |> [] ( -) http://www3.sympatico.ca/petecasso/ [] |> [] " " Frogstein, who has a point behind his eyes [] |> ========================================================= -- Ben Goldberg -- Trespassers will be shot. Survivors will be prosecuted.
In article <360...@sympatico.ca>, Pete Casso <pet...@sympatico.ca> writes: |> > The fact remains, regardless of what fonts the artist uses, the viewer will need |> > to have those fonts on their computer. |> |> Not if font substitution maps are used. What in the world is a "font substitution map" ??? |> > Either give us a quote showing that there are no such limitations, |> > or concede the argument that the ascii standard limits ascii to the being |> > 7 or 8 bit text in the range 0x20 to 0xFF. |> |> I can't post a quote |> The coding table merely defines ascii code. If the table defines ascii code, then that which is not in the table is not ascii. There are no gifs in the table, and hence gifs are not ascii. |> The context of this exchange is that ascii code alone is not sufficient for |> ascii art. You need to add typographical code, or the artwork won't even |> appear! That's like saying you need to add a computer to ascii art, or the art won't appear. |> > Hmm, I seem to have missed these so called "proven facts" - could you repost |> > them, along with names and references of who proved them? |> |> All my views were backed up with proven facts, if you disagree, please |> identify which view and we can discuss. Ya still haven't told me those "proven facts" which, as I mentioned, I seem to have missed. Where are they? [at the very least, which articles did you post them in?] |> > |> It is exactly the denial that the other (typographical) code element exist, |> > |> that is like putting your head in the sand. It is exactly the other code |> > |> element that causes 20% troubles and becoming worse. The ascii code element |> > |> itself does not cause any problems. |> > You are *partially* right - it is a denial that typographical code is part of |> > the ascii character set; There are no ascii characters to specify any sort |> > of typography. Any type of code that does so specify typography is not ascii. |> |> I have never said that typographical code is part of the ascii character set. |> |> What I said was that typographical code (such as font) is part and parcel of |> ascii art. Big difference! I will [temporarily, and only for the sake of argument] concede that typographical code might be part and parcel of ascii art. If so, what typographical code is there in a gif? |> Please reread my articles carefully, I have said things again and again and |> again, such as me not wanting to do anyone to do anything, mainstream will |> take care of all those developments! Hmm, I think I'd like to meet this Mr. Mainstream of yours... It must be great having a friendly programmer who will do everything you want him to do, and make copies that will run on every platform in existance. |> |> ========================================================= |> [] .oo Visit the Gallery of the 'steins! [] |> [] ( -) http://www3.sympatico.ca/petecasso/ [] |> [] " " Frogstein, who has a point behind his eyes [] |> ========================================================= -- Ben Goldberg -- Ben Goldberg -- Trespassers will be shot. Survivors will be prosecuted.
.----- On Wed, 23 Sep 1998 05:26:18 GMT, Pete Casso posted: |MY point is that you always need to display the invisible ascii code to view |ascii art. And to me, it doesn't matter whether you display it on the screen, |or print it out, or through a .txt file, or through a gif file, etc. The |decisive point here, is that the display actually shows what the ascii artist |has created (with ascii code.) | '------------------ Not with ascii *code*, but with ascii *characters*, or more precisely a particular font's interpretation of what image goes with that ascii number code. I believe that those who want to view ascii art will have to put up with a fixed width font, and those that don`t care can keep their Arial or Helvetica or whatever. In Free Agent (which is what I am using) a simple right-click on the message and you can choose between Fixed-Width and Propertional fonts. This is no difficult task, and most other newsreaders can do the same. Just because one or two mail/news clients choose to use proportional fonts, that does not mean that the older clients are now out of date and invalid. Many operating systems are still running on text-based screens and so they have a fixed-width font *only*. Just because Microshite made a mail client that thinks it knows everything about how people want their messages displayed, and assumes that that single-space at the start of the line was an accident, does not mean that we need to render our postings unweildingly large and unsuitable for 90% (I believe that was the figure this thread has been using) of users who have a 'proper' newsreader and not some 'idiot's guide to the internet' newsreader/email client combination that thinks it`s a web browser. Have fun! Martin |\/| _..__|_o._ /\_|_| o._ _ mart.atkins@-- | |(_|| |_|| | /--\|_|<|| |_> --bigfoot.com
Benjamin Goldberg wrote: > What in the world is a "font substitution map" ??? Please reread my past postings. > |> > Either give us a quote showing that there are no such limitations, > |> > or concede the argument that the ascii standard limits ascii to the being > |> > 7 or 8 bit text in the range 0x20 to 0xFF. > |> > |> I can't post a quote Here is an instance where you cut off my quote to bend its meaning. My full response from my previous posting is copied in the paragraph below. The ascii standard does not contain any quotes along the lines of "It is limited to ..." If you disagree, please post quote, I can't post a quote that does not exist. Now, where is YOUR quote showing a limitation, worded along the lines of "It is limited to ..." ? > |> The coding table merely defines ascii code. > If the table defines ascii code, then that which is not in the table > is not ascii. There are no gifs in the table, and hence gifs are not > ascii. There are no printouts in the coding table either, but there are obviously ascii art printouts, so you are missing the point here. The point is (again) that ascii code is not sufficient for making ascii art. You always need to add (at least) typographical code. The sum of ascii code and typographical code (which are not visible) then gets rendered (i.e. made visible) in gif format, in txt format, etc. So, there is ascii art in gif format, ascii art in txt format, ascii art printouts, etc. > That's like saying you need to add a computer to ascii art, or the art won't > appear. No, that's not correct, see the above. The context of this exchange is that you are free to use the most sophisticated software to render ascii art, you are not limited to using just basic software. > |> All my views were backed up with proven facts, if you disagree, please > |> identify which view and we can discuss. > Ya still haven't told me those "proven facts" which, as I mentioned, I seem > to have missed. Where are they? [at the very least, which articles did you post > them in?] And you did not identify which of my views you think I did not back up with proven facts. So I suggest you reread my past postings (in this and other threads) carefully and reopen specific items for further discussion. Bluff doesn't work, my friend, better is to the point discussion. > I will [temporarily, and only for the sake of argument] concede that typographical > code might be part and parcel of ascii art. If so, what typographical code is > there in a gif? Is this one of your trial balloons again? Please read a book on the basics of typography (just reading on font face, font size, font color, background color, character spacing, and line spacing should be adequate for the purpose of this discussion) and the gif89a specification document. > Hmm, I think I'd like to meet this Mr. Mainstream of yours... It must be great > having a friendly programmer who will do everything you want him to do, and make > copies that will run on every platform in existance. Mr. Mainstream is not an individual, it is the trend on the net. For example, in a short time, Mr. Mainstream has made 20% (or more) of net software html aware. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
Martin Atkins wrote: > Not with ascii *code*, but with ascii *characters*, or more precisely a > particular font's interpretation of what image goes with that ascii number > code. What I meant in the above context was that the ascii artist uses ascii code. As far as rendering ascii art is concerned, it is not just the ascii characters that determines the look of the artwork, but also font face, font size, font color, background color, character spacing, line spacing, etc. > I believe that those who want to view ascii art will have to put up with a > fixed width font, and those that don`t care can keep their Arial or > Helvetica or whatever. Well, not quite, counter example is indeed aol and Arial. This amounts to hardcoding the font, and as any other kind of hardcoding, it is inflexible. However, fixed-width too is a kind of hardcoding, and its inflexibility is becoming noticeable in a 20% proportional world. Better is softcoding the fonts (and other typographical parameters) like in html. > In Free Agent (which is what I am using) a simple right-click on the message > and you can choose between Fixed-Width and Propertional fonts. This is no > difficult task, and most other newsreaders can do the same. Just because The big issue here, is that people on the net generally do not know what is going on if they see "garbage" let alone choosing a font by name! Trying go give everyone on the net instructions is a heroic endeavour, but in the long run a more systemic approach is needed, like protecting ascii pics with typographical tags. > one or two mail/news clients choose to use proportional fonts, that does not > mean that the older clients are now out of date and invalid. Many operating > systems are still running on text-based screens and so they have a > fixed-width font *only*. Just because Microshite made a mail client that > thinks it knows everything about how people want their messages displayed, > and assumes that that single-space at the start of the line was an accident, Presently, txt rendering of ascii art gets things right 80% of the time which is not bad (and which is the reason why we are still using it) but things are (slowly) getting worse. The 20% damage is mostly due to proportional font. However, the deeper reason for that, is that email and newsgroup software are evolving from "simple built-in text editors" to "no longer simple built-in word processors." It is these "no longer simple built-in word processors" which have features that damage ascii art in a variety of ways, and the most damaging feature happens to be proportional font. But there are other damaging features as well, such as the "one space swallowing" feature by Outlook Express for Windows. More damaging features are sure to come with the increasing sophistication of the "no longer simple built-in word processors." There are of course precautions that one can take to circumvent those damaging features. I myself have written several pertinent articles on taking precautions and I practice what I preach in ascii art posting to this newsgroup. Nevertheless, these precautions are band-aids that will (slowly) lose their effectiveness with the proliferation of damaging features to come. The main reason for the loss of effectiveness is that different email and newsgroup software will not only require different precautions (there is no standard to follow) but that different email and newsgroup software will require contradictory precautions, making it impossible to formulate a generic set of precautions that will work with all email and newsgroup software. It is really recognizing this mainstream trend on "no longer simple built-in word processors" (and not just the proportional font issue only) that convinced me that in due time, we need to protect ascii pics with display instructions (perhaps typographical tags in a .html medium.) And that is not a band-aid! That is a systemic solution whose portability is increasing and whose portability will surpass the decreasing portability of txt rendering of ascii art, although that will take at least several years from now on. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
.----- On Fri, 25 Sep 1998 22:54:51 GMT, Pete Casso posted: | |The ascii standard does not contain any quotes along the lines of "It is |limited to ..." If you disagree, please post quote, I can't post a quote that |does not exist. | |The coding table merely defines ascii code. It does not define any |limitations, no need to concede anything. | '-------------------------- Pete, ASCII is at most an 8-bit character set. There are 8 bits to every byte of a file. Therefore it is not possible to increase the ascii character set to any more bits without severly changing several things in any operating system ever invented. |\/| _..__|_o._ /\_|_| o._ _ mart.atkins@-- | |(_|| |_|| | /--\|_|<|| |_> --bigfoot.com
Pete Casso <pet...@sympatico.ca> wrote:
>Please reread my past postings.
Yikes! Heaven forbid! Anything...ANYTHING but that! Mercy!
I see no one has been giving you your injections.
Help, Help...where are you Nursie?...we need you.
Bye,
> Actually, there is. On another medium called Fidonet it is > quite > common to use asteriks for bold *like this*, underscores for > underlining _like > this_ and slashes for italics /like this/. I don't think this > causes too > much annoyance to people who read it without a program that > converts the > asteriks for bold-style text. My newsreader is capable but > then again, > I'm using a superior Amiga newsreader ;-). I use Pine 4.02A for BSDI 3.1, via a dialup shell account that I call with my Commodore 128 and a high speed modem. Highlighting methods like these were in common use before Fidonet, and certainly before any programs were able to interpret them. These fall under the defintion of ASCII art, as the meanings of the characters (slashes, *'s and _'s) doesn't really change any - they just tell the user this word would normally appear highlighted on other media. Sorta like using ALL CAPS when you want to shout at someone. :) > Amiga?� Lordy, are those things still around!��� :) ...and one would think the Commodore64 was dead too :) -- ___________________________________________________________________ | . . | * http://www2.southwind.net/~natedac/ * | | _ _ _|_ _ _| _ _ |-----------------------------------------| | |/ \`_| | /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E | | | |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ | | at southwind dot net | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Colin Douthwaite wrote: > > Pete Casso <pet...@sympatico.ca> wrote: > > >Please reread my past postings. > > Yikes! Heaven forbid! Anything...ANYTHING but that! Mercy! > > I see no one has been giving you your injections. > > Help, Help...where are you Nursie?...we need you. P I am Cowlinstein! e I can't say anything meaningful! t / e Well, I can! C (__) / a ( "> oo. s (><) (- ) s ^^ " " o 980927 ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
Pete Casso <pet...@sympatico.ca> wrote: >Colin Douthwaite wrote: >> >> Pete Casso <pet...@sympatico.ca> wrote: >> >> >Please reread my past postings. >> >> Yikes! Heaven forbid! Anything...ANYTHING but that! Mercy! >> >> I see no one has been giving you your injections. >> >> Help, Help...where are you Nursie?...we need you. >P I am Cowlinstein! >e I can't say anything meaningful! >t / >e Well, I can! >C (__) / >a ( "> oo. >s (><) (- ) >s ^^ " " >o 980927 Well I can! What? Bye,
Martin Atkins wrote: > Pete, ASCII is at most an 8-bit character set. There are 8 bits to every > byte of a file. Therefore it is not possible to increase the ascii character > set to any more bits without severly changing several things in any > operating system ever invented. You overlooked that ascii art requires more than just the ascii code set. Even a simple text editor uses a typographical code set to render ascii art. The ascii standard did not pose any limitations on using ascii code in conjunction with other codes. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
Benjamin Goldberg wrote: > And you are overlooking that, while other things than the ascii file itself are > required to view the ascii art, there are limitations on the storage format of > that ascii file; No matter what kind of viewer you use, the underlying libraries > generally expect that one character is stored in one byte. > > Furthermore, while ascii might be more than just the code set, the code set is > an intrinsic part of ascii. If you store characters in any way other than > that specified by the ascii standard [which is, as we all know, is simply a > mapping between byte-values, numbers in the range 0x00..0x7f, and visual-glyphs, > letters which may be displayed in any font or style the viewer chooses], then it > is not ascii. I have not overlooked anything, I think I see more than you do :-) Contrary to what you said, the ascii standard contains no limitations or requirements on storage. As far as going forward with asii art is concerned, that's decisive. > We all agree that the ascii standard says nothing about typographical codes - > it only speaks of [if a written document can be said to "speak"] what letter of > the english alphabet, or what placement character [I speak of newlines and > carriage returns here] specific bytes should be displayed as. > This means that [as an example] text being displayed in Courier font and > text being displayed in Ariel are both ascii, because the data regarding the > font is not part of the file; it is stored in the editor. What you seem to > be missing is that if you insert special characters into the file to change > the font/style/whatever, the ascii standard will require that those octets > be interpreted as letters or placement characters. What you need to add are not special characters, but display instructions on the font/style/whatever, or else the artwork won't appear at all. Simple text editors make simple assumptions about the display instructions, and these days, the assumptions are wrong 20% of the time, damaging ascii art. Contrary to what you said, the ascii standard does not contain any requirements on any interpretations of those display instructions. ========================================================= [] .oo Visit the Gallery of the 'steins! [] [] ( -) http://www3.sympatico.ca/petecasso/ [] [] " " Frogstein, who has a point behind his eyes [] =========================================================
In article <361...@sympatico.ca>, Pete Casso <pet...@sympatico.ca> writes: |> Martin Atkins wrote: |> > Pete, ASCII is at most an 8-bit character set. There are 8 bits to every |> > byte of a file. Therefore it is not possible to increase the ascii character |> > set to any more bits without severly changing several things in any |> > operating system ever invented. |> |> You overlooked that ascii art requires more than just the ascii code set. Even |> a simple text editor uses a typographical code set to render ascii art. The |> ascii standard did not pose any limitations on using ascii code in conjunction |> with other codes. |> |> ========================================================= |> [] .oo Visit the Gallery of the 'steins! [] |> [] ( -) http://www3.sympatico.ca/petecasso/ [] |> [] " " Frogstein, who has a point behind his eyes [] |> ========================================================= And you are overlooking that, while other things than the ascii file itself are required to view the ascii art, there are limitations on the storage format of that ascii file; No matter what kind of viewer you use, the underlying libraries generally expect that one character is stored in one byte. Furthermore, while ascii might be more than just the code set, the code set is an intrinsic part of ascii. If you store characters in any way other than that specified by the ascii standard [which is, as we all know, is simply a mapping between byte-values, numbers in the range 0x00..0x7f, and visual-glyphs, letters which may be displayed in any font or style the viewer chooses], then it is not ascii. We all agree that the ascii standard says nothing about typographical codes - it only speaks of [if a written document can be said to "speak"] what letter of the english alphabet, or what placement character [I speak of newlines and carriage returns here] specific bytes should be displayed as. This means that [as an example] text being displayed in Courier font and text being displayed in Ariel are both ascii, because the data regarding the font is not part of the file; it is stored in the editor. What you seem to be missing is that if you insert special characters into the file to change the font/style/whatever, the ascii standard will require that those octets be interpreted as letters or placement characters. Ben Goldberg -- The first rule of intelligent tinkering is to save all the parts. - Paul Erlich -- Ben Goldberg -- The first rule of intelligent tinkering is to save all the parts. - Paul Erlich
Just some info... Nate / DAC wrote: <snipped> >ASCII art still requires only CODE element. The ASCII code standard >(perhaps as defined by RFC-20? The acronym ASCII refers to the ANSI-standard X3.4: "(American National Standard) code for information interchange". The first edition of that standard was released in 1968, the second in 1977 (see McGraw-Hill, "Compilation of datacommunication standards", 1982). The latest edition was released in 1986 (see <www.ansi.org>). Designation: ANSI X3.4-1986 (R1997) Title: Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII) Standard Type: Publisher: ITI Price: 32.00 >I'd like to see it (RFC20) just for the purpose of >seeing it). <snipped> Same here :) But no online version of RFC20 is available anymore. I looked here: <http://www.nexor.com/public/rfc/index/rfc.html> RFC20 "ASCII format for network interchange." V.G. Cerf (Not online) (Status: UNKNOWN) ... and here: <http://www.cis.ohio-state.edu/htbin/rfc/INDEX.rfc.html> RFC20, V. Cerf, "ASCII format for network interchange", 10/16/1969.(Pages=6) Even given this small amount of info on RFC20, it's highly unlikely Vint Cerf invented ASCII all by himself. Probably RFC20 was just one of the many implementations/modifications of ANSI X3.4. To put things in perspective: In october 1969 RFC20 just applied to the handful of nodes that made up the original ARPANET, whereas ANSI X3.4 was accepted nationwide to deal with all kinds of media... hth, mic
Related ASCII art in the Gallery
Explore these categories from our collection of 11,000+ artworks:
.---.
/ \
\.@-@./
/`\_/`\
// _ \\
| \ )|_
/`\_`> <_/ \
jgs\__/'---'\__/ _,--',
.--.--';_'-.',
.'--'. _.'
'-:_
) >
snd |/ _______ | | (| SFAfS |) | #X | \ / `---' _|_|_
.---------. |.-------.| ||>run# || || || |"-------'|etf .-^---------^-. | ---~ AMiGA| "-------------'
...___________..- | | | | | | || | | | | |'. .' .`.| ___|0oOO0oO0o|___ / ' '. ` ` \ Lester||||AMC
Make your own ASCII art
Turn images, text or 3D into ASCII, or draw your own – right in your browser.
About this thread.
These messages were posted publicly to the newsgroup
alt.ascii-art
in 1998 and are mirrored here unchanged as part of the Historic Archives – only email addresses are masked.
The artwork and text belong to their original authors: if you copy a piece, keep the artist's initials or signature intact and credit them where you can.
Are you one of the authors? Contact us to get your posts attributed, connected to your artist profile, or removed.
Report this message
Help us keep the archive clean and accurate. Reports are reviewed by a person – nothing is changed automatically.