Re: About rendering ascii code in a .txt medium

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  []
=========================================================

Related ASCII art in the Gallery

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

   _
 _(_)_
(_)@(_)
  (_)\
     |
    \|/
  \\\|//jgs
^^^^^^^^^^^

    \\__  o
|\/    o\  o
>       < o
|/\   __/
    //

 |\__/,|   (`\
 |_ _  |.--.) )
 ( T   )     /
(((^_(((/(((_/

  , _ ,
 ( o o )
/'` ' `'\
|'''''''|
|\\'''//|
   """

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

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

Make your own ASCII art

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