Re: About rendering ascii code in a .txt medium

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

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

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

 __ .  . __
(o.\ \/ /.o)
 \__\/\/__/
 /O /==\ O\
(;O/ \/ \O;)

Make your own ASCII art

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