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?

It is a reproduction, as it is not the original art work created with a text
editor by the original artist.  It is now a converted/imported image derived
from the original artwork.

Thus, like a photo of a sculpture or painting, it is a reproduction.

> And that's the reason for me to say that they all are AND show ascii art (of
> course taken in this context.)

Ok, an item can both BE ASCII art as well as SHOW it, only if the media
involved directly supports the ASCII format (and is doing so to contain the
picture).

A GIF file does support ASCII/text attachments, but as long as you are
representing that ASCII artwork in the form of a bitmapped image, you're
only showing ASCII art.  The GIF itself is not actually ASCII art, it's just
a representation of it.

> > The standard is in rfc 20.
> 
> Strange, I digged into the IETF archives, I did not find rfc 20.

Probably because the standard is so old - your archives may not necessarily
go back far enough.

> Well, rfc20 is apparently not in the IETF archives, but apart from that ascii
> art can be be stored as a gif or as a hardcopy, although both have lost the
> ascii code. So what? Decisive is only that the viewer sees the artwork as the
> artist has created it.

ASCII cannot be stored as a GIF unless you are using the actual ASCII
attachment method (can someone post the info on what type of attachments GIF
89A supports?).

ASCII artwork can be represented as a GIF, but it still qualifies only as a
representation, not as actual ASCII art.

> > To be ascii art, I should be able to open it up in my text editor and see the
> > shape of the drawing - if I open up a gif with my text editor, I see garbage.
> 
> Where is it written, for example, that ascii art has to be viewed with a text
> editor? Please provide quote from the ascii standard.

The standard itself (i.e. being a standard at all) is what defines that it
be displayed on a text screen (or in a text editor, or on a printout, which
was probably the common "display" method when RFC20 was proposed).

Where is it wrttten that a GIF image has to be viewed with a GIF viewer?
Just as the above person said (sorry, I missed his name?), view it with
anything but a GIF viewer (or a program capable of displaying GIFs) and you
see nothing but garbage.

Do you see it written anywhere that GIFs have to be viewed with a GIF
reader? :-)  Of course not, it's pure common sense!

> > Once you've opened yourself up to this argument, what about, for instance, taking
> > that gif and changing the colors of the letters, applying distortion filters, etc
> > and calling *that* ascii art, too?
> 
> I take life easy and say that all that IS ascii art if it indeed shows what
> the ascii artist created.

But it isn't, if the colors have been changed, or if the picture has been
altered in any way beyond a reasonable amount.  The artist (most likely)
created a black and white picture with ASCII code, and stored, transmitted,
and edited that picture using nothing but ASCII code.

It's colorized artwork, which has to now fit the definition of the media
which makes those colors possible.  Hence, it might be just "text art" or
"HTML art".  It isn't ASCII art anymore, not according to the standard which
was just posted.

> > text file a candi> 
> > Of course, you could have a restriction that printed text that was directly
> > calculated from ascii input is ascii art - this would make a printout of a
> > [file a candidate] for ascii art, but a printout of a gif image not ascii
> > art.
> 
> Please provide a quote on that restriction from the ascii standard.

So you're saying that a GIF printed on paper is ASCII art because the GIF
itself was created from an ASCII textfile, even though it's already
established that the GIF is not ASCII art?

(By the way, yes I did change my mind on the issue of printouts of ASCII
art, as derives from an ASCII text file - I'll leave that to a separate
thread)

> > Who needs to 'devise' a solution? We have one already - use fixed width ascii text.
> 
> That's an 80% good solution that slowly, but surely becoming worse with the
> computing world going proportional.

You seem to assume just because people are adding more and more
porportional fonts to thier systems that non-porportional text will cease
to be a solution.

Without making any further assumptions on my part, I just ask that you
either accept or deny the above statement.

> You missed my point completely. What I said was just the opposite: recipients
> should spend zero effort on viewing ascii pics correctly. Everything else,
> like forcing the recipient to install other fonts, change font settings
> (non-proportional or proportional,) etc is brute force.

But that's exactly what the recipient must do, if for example, they are sent
a piece of artwork drawn with any font other than the ones the recipient has
installed.

So, regardless of what software they're using they still must aquire this
font to see the artwork correctly.

To me, that's just another way of a "brute force" solution - unless you can
think of some way to make ASCII art (in any form) display correctly,
regardless of the font (porportional or not, of any specific typeface) it
was drawn in, and regardless of the fonts the recipient has on hand.

> Again, you missed my point completely. What I said was just the opposite:
> everyone, i.e. both makers and viewers of ascii art, use the Internet software
> they are using anyway. Please reread my previous postings carefully on how to
> do that by way of "piggybacking" as I call it.

But by this "piggybacking" idea, there must be some way to translate what is
"piggybacked" onto the media in question.

If that media is HTML, then there must be some program that will correctly
use the new/modified tags to display the artwork.

If that media were just a normal newsgroup like this one, there must be some
program that will display the artwork from some standardized format
(UUENCODE or MIME, perhaps, since both will easily transport binary files
of any type you can imagine).

So any way yo slice it, SOMETHING has to be added.  A program of some type
has to be loaded on every computer that isexpected to view this new form of
artwork (or if you prefer, this existing form, with a myriad of new
typeographical settings).

So which is it going to be?

Require 100% of the users interested in ASCII artwork to load this new
program (assuming thier computer can even run it)?

Require 100% of the users interested in this artwork to download a series of
fonts to be used with the above program?

Or require 100% of the users interested in ASCII artwork to use a standard,
fixed-spaced font, which they already have on thier computer regardless of
the software they're using?

The solution, however "brute force" seems quite obvious to me.

Now, what about the future:  When the Internet has become, say, 90%
porportional and 10% fixed-spaced...

What is the solution then?  I still see the same three choices above -
either install some new program, or add a variety of fonts in hopes that you
can find the right one, or just keep using the usual fixed-spaced method.

> > there is no way to have color,font,style, or size information in standard ascii.
> > Now that I have here in front of me the list of all defined ascii codes,
> > I don't see how you can stick fonts, sizes, styles, or colors into ascii code,
> > nor, by extention, into ascii art.
> 
> Aha, and this is a perfect opportunity to point out that ascii code alone is
> not sufficient to make ascii art. You need a font, a font color, a contrasting
> background color, etc that are in the realm of typography, outside the ascii standard.

True, it needs a few typographical settings, BUT - the RECIPIENT is the one
who gets to choose these settings, and none will have any effect on the
correct display of the artwork (as longas one uses a little common sense of
course)...

You can change foreground and background colors to a good combination - the
art is still ASCII art, because the file has not been modified from it's
original 7-bit monochrome, fixed-spaced format.

You can install any fixed-spaced font you want, and the art won't change (as
long as the font is ASCII compliant of course).

You can adjust the size and porportion of the font, and the artwork won't
change any (by "porportion" I only mean the ratio of height to width,
applied to the predetermined cell size common to all characters in the
font).  So my little 8x8 font could be blown up to twice it's height and
half it's width, but the artwork being displayed won't change any - it'll
just look funky because of the settings I chose to use - that font is still
an 8x8 font.  The same would be true if the font were a True-Type or other
vector-oriented, scalable, fixed-spaced font such as Courier or Pica.

But what you are proposing is that the ARTIST be the one in control of the
settings - i.e. the artist adds colors, different typefaces, various kinds
of distortions, or even graphical or line art (perhaps to make borders or
flood-fill areas of a picture).

Now, the RECIPIENT's machine and/or software has to be upgraded to handle
all this stuff, whereas with the standardised fixed-spaced fonts and such
that we are using now, the recipient simply needs to select the fixed-spaced
font that his machine came with, and the artwork will look right no matter
who drew it or what fixed-spaced font was in use at the time (with the few
exceptions I mentioned of course).

> Or to say things the other way around, to make ascii art, you need ascii code
> AND ALWAYS things that are outside of the ascii standard. And you are free to
> choose from a myriad of resources. If you disagree, please post a quote on the
> prohibitions from the ascii standard.

The prohibitions were already quoted, by him having shown you the standard
ASCII chart.  From my Webster's dictionary:


Prohibit, v.t.  1, forbid.  2, prevent; hinder -- prohibitory, adj.

Prohibition, n.  act or effect of forbidding; [Remainder relates to the 18th
Amendment]

Prohibitive, adj.  tending to preclude or discourage, as a high price.  --
prohibitiveness, n.


Seems to me that at least the third one quite nicely fits this discussion -
the ASCII charts that have been posted quite easily discourage the use of
non-ASCII characters (and by extension, the misuse or re-defintion of
existing ASCII characters).

And certainly the first one (prohibit) fits this newsgroup to a T.

> > It seems that you're both sidestepping the obvious item that neither of you
> > have copies of the standard.
> 
> Thank you, thank you, I have the privilege of having access to an excellent
> library, but indeed I could not find rfc 20 ;-)

Had I known what the RFC number was, I'd have looked it up and quoted the
relevant text.

Now tell me - do you consider the RFC's to be the de-facto standards, as the
other 99% of the Internet community (who knows what RFC's are for) does/do?


> > When you type up your ascii image, it is ones and zeros in computer memory.
> > When you save it, it is ones and zeros on magnetic disk.  The ones and zeros
> > are in the same sequence on disk as they were in memory, just as the now dry
> > paint is in the same pattern, and has the same colors as it had when wet.
> > 
> > The only difference it's not possible to make paint wet again for someone to
> > modify it, and the only way to make as exact a copy of a painting as you can
> > make of ascii art would be to hook up a robot arm to a computer with a camera,
> > and have it dip a brush in accurately mixed paint and it in the exact same way
> > as was done to make the original painting.
> 
> I see no relevance of the above quotes to the discussion that we are having.

He's talking about the ability to edit an image using the same tools from
which is was created, and to reproduce exactly using the same tools from
which it was created.

In other words, it'S just as I said before, you can't import an ASCII text
file into some other media like a GIF, edit it there, and then expect to
call it ASCII art (even if you don't edit it).

But take that ASCII text file, load it into a text editor, and edit it -
it's still ASCII art then, since it's still copiable and editable using the
same tools (or the same media) from which it was created.

> > a space is still ascii 30, etc.  If you take a screenshot of a piece of ascii

A space is ASCII 32 actually.

> Well, this is a repetition, and again, my contention is that it is ascii art
> if it indeed shows what the ascii artist created, the means for displaying the
> artwork does not matter. And again, please note that I am NOT talking about
> reproductions here.

Yes you are, if you're talking about displaying anything other than the
original text file or an exact duplicate of it.  I suppose by extension that
makes every ASCII artwork a reproduction or a copy, since one can't easily
move a file from one place to another without leaving a copy behind
somewhere (unless you always loaded and saved it to a floppy disk or
something).

> > It does indeed contain those tables - anything not in those tables isn't ascii.
> 
> Hah, and now we can't make ascii art at all, since fonts, font color,
> background color, etc are not contained in those tables either! <sarcasm>

Sarcasm as this statement might be, you still left out one key element -
COMMON SENSE.

> Well, present your curves and we can discuss them

If you want to win this argument, you had better start posting quotations of
your own as well.  That includes displaying a good representation of a chart
taken from some other souce than your own.

For crying out loud, go look it up and prove your trends to us to be
accurate. Do make us prove them wrong to you.

> Viewing plain text is not good enough for ensuring that ascii pics are
> rendered correctly, because the world is going proportional.

It has been good enough for the last 20 years or more, and it will continue
to be good enough far, FAR into the future, regardless of what you think the
world is doing.

> > Sure, *new* server software can handle 8 bit transmissions, but, as mentioned,
> > most of the server software out there is not new.
> 
> Well, that's the trend.

And how long do you think it's going to take before EVERY SINGLE computer,
server, and mainfraime (as well as everything else in between) that helps
operate the Internet, becomes capable of any and all things you are
proposing?  Probably another 20-30 years.  It took some 20 years (since the
first computers were linked together to form the first incarnation of the
Internet, the ARPANET) to come up with the HTML standard, and it'll probably
take just as long to refine that standard into something that every computer
on the Internet is capable of using.

> Well, first of all, "dictate proportional" is brute force that I reject.
> Please read my articles carefully.

This is exactly what you are proposing by expecting some form of software to
handle all of the problems of porportional and non-porportional fonts being
used in ASCII artwork.

You want the other 80% of the Internet to go porportional like the first 20%
have (or whatever your original numbers were).

So how, EXACTLY, is this supposed to happen?

Show us your proposed standard, and prove it to be capable of working on any
computer, no matter what type it is, no matter what kinds of fonts it has
available (if any).

And prove that it doesn't require even a minimal program to be installed on
said computers, to make this standard viewable.

I said it requires an extension program of some kind, you seem to be saying
this is as much a brute-force idea as expecting everyone to stick with
fixed-spaced fonts for ASCII art. So show is an idea (with details!) that
is NOT brute force.

> > The reason ascii is so widely used is the same reason people use ascii
> > art - It works everywhere, and won't be harmed when internet news/mail
> > servers truncate [the data to 7-bits wide.]
> 
> These days, ascii art is harmed 20% of the time and becoming worse, because of
> proportional, even if you call it brain-dead. But that does not mean that I
> want to force the use of proportional, etc etc ... please read my articles carefully.

What has truncating the data stream (from 8 or more bits to 7 bits) got to
do with those 20% who are too lazy (or not sure of how) to switch to a
fixed-spaced font?

> > or only a few fonts.  Only people installing new software have dozens and
> > dozens of fonts.
> 
> Almost right, but not quite. What I said was that everyone on the net should
> be able to view ascii art correctly with his/her own Internet software,

... which is impossible to do given the wide range of programs people use to
view ASCII art.  Your proposal still requires some program to make the
computer able to view any ASCII art image regardless of the fonts the artist
used, and regardless  of the fonts that the recipient has.

Not to mention the number of platforms in use, most of which can't make any
sense of a program written for another platform (again, without loading some
kind of program to emulate or translate the program or the machinefor which
it was written).

> > Who wants to read lengthy articles?  We just want to be able to open newsreader,
> > and read ascii art, or open reader, and *type* ascii art.  We don't want to have
> > to deal with nonsense of detaching or attaching images.
> 
> You missed the point here. The point of those lengthy articles is on zero
> effort for the recipients and zero development efforts for the ascii community.
> 
> Mainstream development will only care about ascii code for general usage, but
> will not care about ascii art which is a special purpose. But we can piggyback
> on mainstream, that's the point, please reread my articles carefully.

So show us your proposed standard, which you personally guarentee that 100%
of the ASCII community can use with zero effort (I'll discount the fact that
one must download and install the required software to view this piggybacked
standard)

> I think that piggybacking on html will be a necessity to protect ascii art at
> least several years down the road, although I won't do anything to push things
> in this direction, mainstream development will run its own course.

It seems to me that this was established with the first version of the HTML
standard - the <PRE></PRE> tags to be exact.  They're all one needs to
"protect" ASCII artwork, since browsers already switch to a fixed-spaced
font when they encounter these tags.

I think what you need to think about then, is getting 100% of the ASCII
community to start using new newsreaders and Email programs that can display
HTML (or whatever method becomes the standard if plain fixed-spaced
textfiles get phased out)

> No, sending ascii code will continue as it has always had. But sending ascii
> art needs to change if we want to be sure that the viewer sees it correctly in
> this increasingly proportional world.

Ah, so you are proposing a new standard.  Great, let's see it.

But until the day comes when a Sinclair, a Sunsparc, a VAX, a CrayXMP2,
Commodore, Apple, Macintosh, IBM/PC clones, Unix/Linux boxes, NeXT, and any
others I can't think of, can all run the same program and view the same
fonts from the same multi-font source file, plain text will indeed remain
standard, and need only two words to protect it -- COMMON SENSE.

> Again, all those mainstream efforts will apply to ascii code, but
> unfortunately that's not good enough for ascii art. As I said in the above, we

The problem you seem to be refusing to accept with all of this is that any
standard that uses somthing in the ASCII code set to define some new
meaning, is no longer ASCII.

HTML is based on ASCII of course, but it is not ASCII.  If it were, there
would ben some character in the ASCII set that's reserved for
starting/ending HTML sequences.

Code sets like ANSI and VT102 are a little closer, since the code used to
start these sequences (ESCAPE, code 0x1B), is "hardware defined," which
implies that it's defintion is allowed to be changed for whatever task is at
hand.

I will not say that these are ASCII, but they are at least closer, since
they don't redefine some characters in the ASCII standard as HTML does (HTML
redefines several characters like < & and > which already have established
meanings which are contrary to thier use in HTML)

> Thank you, I am sure in time you will like my writing as well, because it is
> not rhetoric but good info. 

Good info, yes.  Highly biased against a 20-year old standard (plain,
unaccented, no-HTML, 7-bit, fixed spaced, monochrome ASCII text),
definitely.


-- 
 ___________________________________________________________________
|         .       .       | * http://www2.southwind.net/~natedac/ * |
|   _  _ _|_  _  _| _  _  |-----------------------------------------|
| |/ \`_| |  /_)/ |`_|/ ` | GCS d- s++:++ a-- C++ UB>++ P+ L>++ !E  |
| |  |(_| \_ \_ \_|(_|\__ | W++ N++ K- w--- M- V? PS PE Y+ PGP- t++ |
|   at southwind dot net  | 5 X+ R tv@ b+ DI(++) D+ G++ e+ h+ r- y- |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Related ASCII art in the Gallery

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

     .
    /=\\
   /===\ \
  /=====\' \
 /=======\''/
/=========\/

Make your own ASCII art

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