Re: About rendering ascii code in a .txt medium

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

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.