Re: About rendering ascii code in a .txt medium

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."

Related ASCII art in the Gallery

Explore these categories from our collection of 11,000+ artworks:

 ,~~--~~-.
+      | |\
|| |~ |`,/-\
*\_) \_) `-'

 __
 \  \     _ _
  \**\ ___\/ \
X*#####*+^^\_\
  o/\  \
     \__\

.------------.
|\\//\\//\\//|
|//\\//\\//\\|
|\\//\\//\\//|
|//\\//\\//\\|
'------------'

   _______
 /` _____ `\;,
/__(^===^)__\';,
  /  :::  \   ,;
 |   :::   | ,;'
 '._______.'`jgs

 _  _
(o)(o)--.
 \../ (  )hjw
 m\/m--m'`--.

  _  _
/` \/ `\_  _
\     /` \/ `\
 '.  .\      /
   \/  '.  .'
         \/jgs

Make your own ASCII art

Turn images, text or 3D into ASCII, or draw your own – right in your browser.