Re: About rendering ascii code in a .txt medium

> Please provide a quote from the ascii standard prescribing this one medium, I
> don't see it.

There is no text I can quote - like many common-sense issues, the problem of
proper formatting/use of ASCII is an assumed standard.   In other words,
virtually everyone who has worked with ASCII will agree with what I (and
everyone else who has hesitated to command) am saying.

> The gif is also ascii art if it made with ascii code. If the gif is not made
> with ascii code, it is not ascii art. In other words , what classifies the gif
> is NOT whether it can be easily manipulated or not, what classifies the gif is
> whether ascii code is used or not, just like in the printout case.

The problem is, the GIF is not made with ASCII code.

Once it is in the form of a GIF, it no longer uses ascii code.

It doesn't matter what the picture was originally created from (ASCII art, a
scan from a digital camera, or a hand-painted image for example).

> I think it is a simple matter to retrieve the ascii code from a gif by feeding
> it into a character recognition program, but that's not the point.

This could possibly be done, I didn't consider OCR as an option here.

> The point is that the ascii standard does not prescribe any medium, let alone
> prescribe code retrieval from any specified medium. 

How you retrieve or generate the ASCII code doesn't matter (it could be
typed, received from some random-fractal generator, or whatever).

As I said, ASCII assumes the criteria I mentioned several times, because of
simple, common sense.  It's an unwritten rule that ASCII art is supposed to
be fixed-spaced monochrome 7-bit text in the form of a text file that can be
displayed on virtually any computer or printer.

You wouldn't send an image of some kind (regardless of it's format) to a
friend if you knew he couldn't display it, would you?  But you know that if
it is ASCII (according to the criteria I mentioned), the receiver can easily
view it no matter how little software they have.

> What you said about manipulation and code retrieval does not provide any basis
> for classifying pieces as ascii art or not, since it is outside the ascii
> standard altogether. 

Exactly, as is the storage of an image as a GIF - it is outside the ASCII
standard because the image is not stored as a stream of ASCII codes.  It is
stored as a bitmap.

The part about paper versus another format is a little different, in that
the image being printed is ascii art, even if the resultant printout can't
be manipulated.  The GI created from an ASCII file is not ASCII art, if only
because it is an active storage medium that isn't even needed (you should
have just sent the ASCII picture, not the GIF conversion of it).

> If you disagree, please post quotes from the ascii standard on prescribed
> manipulation and code retrieval methods, I don't see them.

Like I said , they don't exist because this is an unwritten rule - an
understood principle, upon which this newsgroup is based.

> > The ASCII standard doesn't allow for anything except some simple formatting
> > codes (like linefeed or horizontal tab).
> 
> Please provide a quote from the ascii standard spelling out the prohibition, I
> don't see it.

Sure, if you want me to type up a copy of an ASCII chart.  Here are the
codes from 0 to 31, which define the ASCII control code set.  Note that
using these codes is of course not allowed in this newsgroup.  From the
manual to my Panasonic KX-P2123 printer (which has of course been retired):

 0 Null
1-6 are undefined
 7 = Bell
 8 = Backspace
 9 = Tab
10 = Line feed
11 = Vertical Tab 
12 = Form Feed (Clear Screen)
13 = Carriage Return
14 = Shift-Out
15 = Shift-In
16 is undefined
17 = Device Control 1 (X-On)
18 = Device Control 2
19 = Device Control 3 (X-Off)
20 = Device Control 4
21-23 are undefined
24 = Cancel
25 = EM (?)
26 is undefined
27 = Escape
28-31 are undefined

As far as I know, this is the standard code set.  Some printers (including
this one) can replace the undefined codes with a standardized set of symbols
(from the IBM Character set).

You'll find there are no codes in any standard ASCII chart (by standard I
mean that it must follow the official ASCII standard to the letter) that can
specify any of these, unless such codes are acted upon by a viewer program
to mean something other than thier intended purpose.

Perhaps someone can shed som light on those undefined codes above.  If I am
wrong, I'd appreciate seeing the full code set.

> Font, type-size, color are typographical parameters outside the ascii
> standard. Non-inclusion of these typographical parameters do not constitute a
> prohibition. On the contrary, the ascii standard is supported by myriads of
> typography in the real world.

I didn't say the ASCII standard PROHIBITS the use of these options, I only
said it doesn't directly support them!  This newsgroup, however, does
prohibit the use of the various typographical settings we've discussed,
because they just are not very portable.

> By the same token, please prohibit ascii art websites to use the word ascii
> art. They violate your definition of ascii art by using html tags.

No they don't - they display ASCII art pictures in thier entirety,
unaltered.  They are simply surrounded by <PRE></PRE> tags to force the
user's browser to render the images as preformatted text.  The data
contained between those tags is usuall not altered in any way.

The exception to that rule is the use of the < and > symbols - because these
are used by a browser to trigger tags and such, one must replace these with
special tags so that the browser knows the difference between an arbitary <
or > symbol, and a <> pair that indicated a tag.

When the image is rendered to the user's screen, it is still rendered in
7-bit, monochrome, fixed-spaced, ASCII, including the < and > symbols.  The
user could highlight the text and save it to a text file, displayable any
time they choose to, and these special codes (which are &lt; and &gt;
respectively) will not become part of the file.

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)

> I have (ironically) suggested that before, but not surprisingly, all of them
> still call their html enhanced pieces ascii art, and justifyably so.

They probably call them ASCII art for lack of a better term.  The term can
be used loosely of course, but in this newsgroup it generally refers to the
aforementioned criteria.

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


> Please prohibit the naming our parallel newsgroup alt.ascii-art.animation
> I think the name is justified, for the same reason as in the above.

Since I don't read that newsgroup, I can't suggest what criteria they
follow.

If my guess is right, they probably follow the above criteria - a series of
drawings spaced far enough apart that one need only hit thier page-down key
to watch the animation.

> 20% of newsreaders are set to proportional, damaging ascii pics. It is
> unrealistic to expect everyone of them to change to non-proportional,
> and over and above that, the trend goes the other way, i.e. the world
> goes to proportional.

It is just as iunrealistic to expect everyone to conform to some
porportional standard, when there simply IS NO STANDARD!

But given that this newsgroup is intended for ASCII artwork drawn using the
already established criteria (fixed-spaced 7-bit monochrome), whether those
users want to change thier font is irrelevant.  If they don't, they can't
see the artwork correctly.

But the point is, they can - everyone has a fixed spaced font of some kind,
that can be used to view normal ASCII artwork.

But not everyone can change thier browser/newsreader to use some special
font designed to be the official font for Porportional ASCII art.  That is,
as soon as someone sets such a standard, someone else will immediately
complain because thir computer can't use this special font.

> There are better solutions available, based on html and more advanced
> techniques (that will be become imminent only in several years to come
> or even later.)

Of course there are, but in this newsgroup, we are not interested in thise
media, because they are not standard, and in many cases, those media may not
even be able to be sent over the Usenet.

You forget that much of the Usenet is still 7-bit only!  Why do you think
the recommendation to use UUENCODE or MIME exists, for sending something
that contains characters outside the 32-127 range?

Because many systems will munge the data, rendering the extended (8-bit or
higher) image as garbage.

And to do this, like I just said you have to use UUENCODE or MIME or some
other similar format.  That means converting your image for transmission,
and converting it back at the other end for display.  Not such a bad thing,
but certainly not very convenient.

> The portability is not 100%, but at around 80% and declining, because 20% of
> email and newsreader software is set to proportional and the trend is towards proportional.

The portability is 100%, period.  Name one internet-capable computer that
cannot display ASCII artwork using fixed-spaced font, as dictated by this
newsgroup.  Go ahead.  Name just ONE.

> Why is it ascii art if your finger does the paging, and why is it all of a
> sudden not ascii art if the paging is automated?

Because that automated paging requires some sort of code.  It might be a
series of ESCAPE codes, or it might just be a special string of characters
in the image.

But regardless of what kind of code specifies the frame size (the amount to
page down from frame to frame), one still has to load a secondary program on
top of thier newsreader to see this modified artwork.

> If the viewer is the stumbling block, please post a quote from the ascii
> standard prescribing some viewers and prohibiting others, I don't see
> any such words.

You keep asking me to do the impossible - the ASCII standard, like I said,
is an assumed standard - a standard agreed upon by the vast majority of
people out there, who have knowledge of the subject.

The viewer is part of that assumed standard - one is not supposed to need to
load some special program other than the operating system's default viewing
method (the TYPE command in DOS, or the MORE command in Unix, for example).

> Aha! That's a key point that I want to get across! The ascii community has
> myriads of typography at its disposal!

No, those myriads of typograyhave ASCII at thier disposal.

You appear to be confusing which of the two (the various typographical
settings/methods, versus the ASCII code structure and standard itself) is
the base item and which is secondary.

To most of us, ASCII is the base item.  And the standard ASCII format
doesn't support anything beyond the assumed standard of fixed-spaced 7-bit
monochrome text and artwork.

> I think you keep missing the message that about 20% of newsreaders see garbage
> instead of ascii art. 

Because the user who keeps complaining about the garbage is either unaware 
of how to change the font, or is too damned lazy to change it.

Name one newsreader that uses loadable fonts, that cannot use a fixed-spaced
font.  Not a single one.


> Unfortunately, this newsgroup is not the center of the universe. On the

No, but this newsgroup is the center of it's own world - that world which
you enter by reading this newsgroup.

> pics (And we need to do so without asking the rest of the world to change
> their settings.)

No we don't.  The rest of the world needs to stop going crazy over pretty
pictures and fancy fonts.  And for that "small" part of the world interested
in ASCII artwork, most of those people will be quite happy to (even
temporarily) change thier normal font, to view standard artwork.

> We don't turn them off with those words, we turn them off because they can't
> get their settings right, even after receiving instructions, or they simply
> prefer proportional settings for the other stuff that they do.

If the user can't get thier settings right, then they need to find a
newsreader they can more easily adapt to.  

If they prefer thier pretty little porportional font, tough.  This newsgroup
is supposed to be viewed with a fixed spaced font, and that's all there is
to it.

> Those are bad solutions, if you can call them solutions at all. There are
> better solutions available (I don't want to repeat the discussion.)

I suggest you repeat the "discussion" then - because I seem to have
forgotten what the better solution is.

The way I see it, the system you are proposing requires the user to have a
computer which can load fonts for display on demand, without the user's
intervention.

Further, your proposal requires that the user's computer be capable of
displaying these fonts with the *EXACT* same porportions as the font that
has been chosen for the artwork.

Finally, that proposal requires that the user's computer be capable of
displaying a wide enough image to accommodate these fonts (if you're gonna
go porportional you may as well go for a larger viewing area too, right?)

That pretty much rules out all but the most modern computers - those that
can run a GUI capable of using little applets or sub-programs to do all of
the above tasks.  Those same computers had sure as hell better be fast too,
otherwise the user isn't going to be very happy wading through tons of
messages at a pace slower than a snail.

> That is a good solution that is slowly, but surely becoming a bad solution in
> an increasingly proportional world. If the portability of ascii pics has
> dropped to 50% (i.e. without asking 50% of the world to change their settings)
> then we need different (and good) solutions. (I don't want to repeat the discussion>)

You seem to have lost the definition of portability by this statement.

According to the New American Webster Handy College Dictionary:

portable, adj. capable of being carried; easily conveyed.  Also, portative,
adj. -- portability, n.

In other words, portability means being able to move something (either it be
an object or a piece of data) from one place to another without a great deal
of effort.

Editing, transmitting, receiving, and vewing an ASCII art picture using the
widely accepted standard (of fixed space 7-bit monochrome text) is a no
brainer.  What can be easier than displaying plain text???

> (Saying that "ascii supports html" is different from "html supports ascii" is
> to me irrelevant play of words, decisive is that the ascii community has this
> medium (and a myriad others) at its disposal.)

These are not plays on words.  These are entirely different ideas.

By saying "HTML Supports ASCII" you are saying this:

"The HTML (Hyper Text Markup Language) format, which consists of markup
tags, attached image files, and so on, can and does use the ASCII format as
a basis for the language."

Of course that statement is true in all respects.

By saying "ASCII Supports HTML" you are saying:

"The ASCII standard inherently supports the use of HTML - There are specific
markup codes in the ASCII format which specify that an HTML document is
contained within."

Of course, the above statement is completely false.  There isn't a single
code in the ASCII standard that can specifically indicate an encoding
format, unless said codes are redefined by an external viewer program.  If
you're going to mince words, you had better make sure you're conveying your
ideas clearly.

> If you agree that a myriads of media support ascii, i.e. the ascii community
> has therefore a myriads of media at its disposal, then that's really a key
> point that I wanted to make.

I agree that myriads of media support ASCII.

I do not agree that the ASCII community has these media at it's disposal, in
such a broad range as you are indicating.

> And if (see further above) you agree that a myriads of typography support
> ascii, i.e. the ascii community has a myriads of typography at its disposal,
> then that's really the other key point that I wanted to make.

There is no typography setting of any kind (that I am aware of) that
requires the data to be in ASCII format.  In other words, typographical
settings do not support ASCII.

The phrase "typographical setting" only means a setting or condition set by
the editor and viewer software, to enable such things as fonts, colors, and
attibutes like bold or italics.

Again, if you're going to throw words out in the open, you need to watch
what you're saying.

Various media support ASCII as well as typographical settings - a good
example of course is HTML.  That format supports the ASCII standard of
course, and it lso supports the use of typographical setting commands (such
as <FONT> and <SIZE> tags).

Just because some medium supports one method or format, doesn't necessarily
mean it supports another.

To use another Commodore related example:

The program Screen magic (as well as most any other related program) fully
supports the use of the PETSCII (a derivitive of ASCII), as well as commands
to change colors, display block graphics characters, and switch between the
two system default fonts.

Those are typographical settings.

That program doesn't in any way, shape, or form, allow the use of the ASCII
code set.

On the other hand, this newsgroup is exactly the opposite:

It supports ASCII in it's standard form.  It does not support color changes
or PETSCII (or any other non-standard code set), or the use of more than one
font.

This lack of support can mostly be blamed on the fact that many newsreaders
weren't capable of anything more than 7-bit text, and that many systems
still in use today will not pass more than a 7-bit stream (the 8th bit us
either dropped or replaced with a parity bit, screwing up the original
data).

-- 
 ___________________________________________________________________
|         .       .       | * 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:

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