X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f996b,de3737aab10fae64 X-Google-Attributes: gidf996b,public From: Nate / DAC Subject: Re: About rendering ascii code in a .txt medium Date: 1998/09/18 Message-ID: X-Deja-AN: 392465421 References: <35FC2BFC.59B50DAD@sympatico.ca> <35FC82F4.6A4949CE@spamfree.land> <35FDB3F6.7D0A358C@sympatico.ca> <6tp9as$1ek$2@tron.sci.fi> <36007DF2.596E9AB9@sympatico.ca> <3601B816.C9F4DD80@sympatico.ca> Content-Type: TEXT/PLAIN; charset=US-ASCII Organization: SouthWind Internet Access, Inc. Mime-Version: 1.0 Newsgroups: alt.ascii-art > 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 
 and
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 - 
 and
-- 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. 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- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~