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.

Biased how?  You claim that a GIF isn't a reproduction, and I am asking you
what you call it, if it is something other than a reproduction (a duplicate,
a copy, a facsimile (sp))

> it is a paper medium (printout) of the computer code, etc
> they are all first hand renderings, NO reproductions.

They are reproductions, because you are not using the original artwork
anymore, you are using a reproduction of it.  I won't argue further on
whether a GIF is ASCII art or not, it's getting us nowhere.  I agree,
however, that it can *SHOW* ASCII art.

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

Which by the definition of "reproduction", is correct.  From my dictionary:

Reproduce, v.t.  1, to make a copy of; duplicate.  2, procreate.  3, produce
again. -- v.i.  1, beget; generate offspring.  2, be capable of being
copied, as by printing.

Reproduction, n.  1, act, process, or result of reproducting.  2, a copy,
picture, 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.

I never once said you were talking about attachments of any kind.

I said specifically, that the GIF standard (which I later refined to mean
89A rather than the older 87A) supports ASCII attachments.  I said further
that those attachments in themselves are ASCII.

I also said that you could use said attachments, but not that you
specifically were.  I stated a possibility, not a actual event (etc).

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

Note that I didn't say anything regarding RFC20 (Except the above saying
the standard may be too old to locate on the 'net) - I'll leave that up to
the other guy in this thread to shed some light on it's whereabouts.

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

The RFC's are what *DEFINE* the standards in use today for the net, not the
other way around.  The RFC's do not simply follow some accepted standard or
offer explainations for the standard.  They *DEFINE* it.

In the case of ASCII art, that would suggest that RFC-20 is the official
definition of the ASCII code set and control code meanings.  I believe these
have already been posted and discussed by myself as well as another user
here.

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

Umm... The GIF format is defined by a set of standards (which I guess
CompuServe used to own, now someone else does?).  In fact you're supposed to
purchase a license to write data into GIF format as I am told.

So this makes the GIF format "a standard with all kinds of prescriptions,
prohibitions, code storage requirements, etc."  Yet, the GIF format is/was
by far the most popular image format around (with JPG quickly catching up).
How do you explain your statement in reference to this?

Just because there is a standard, with certain limitations, doesn't mean
that said standard won't become popular or even commonplace.

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

I am refering to the ASCII standard as most people see it.  I am not
referring to RFC-20 in this case, because I don't know anything about it.
Instead, I am using simple common sense.

> Anyway, I have asked several times for quotes, but you posted no quotes sofar. 

And I have asked you to post quotes refuting these observations, which you
have so far REFUSED to (by stating the burden of proof incorrectly lies on
me and others, when you are the one proposing things that are outside our
capabilities or purposes).

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

By this I meant that a text editor is more or less the least amount of
software you need to create ASCII art and plaintext.

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

This could be argued, but now you are talking about fighting simple common
sense here.  In other words, now you're nitpicking.

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

You are not adding any code in any shape, form, or fashion, to your artwork
by using some specoific typeface and color combination that suits your
tastes.  The artwork you create will still display right no matter what
(provided it is still within the definitions we've already discussed).

> Now, where do you draw the line with adding code? My answer is: draw no line.

You draw the line when you add any non-ASCII code to the artwork that alters
the appearence of the artwork itself.  I don't see a problem with adding a
clear-screen code to the top of a piece of artwork, for example.  But,
because of brain-dead software that runs half of the Internet, that code
would probably not make it through anyways.

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

NO, what you said was that the 20% of porportional users are growing, and
the 80% is declining.  There is a trend, and trends tend to continue if they
are a good thing at all.  By extension (and by not saying there is a likely
stopping point), you were saying that non-porportional use would pretty much
be phased out within some likely (and quite short) time period.

This is especially the concern for ASCII art.  Again, by extension (of those
graphs you posted for examaple), ASCII art as a 100% portable media would be
phased out.

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

Right, when it comes to ordinary text, formatting and other font-specific
capabilities are not as much an issue.  I doubt anyone will complain if you
send a text file and it is displayed in a font other than intended.  It
still conveys the message.

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

WHAT software????

I thought you said there was ZERO EFFORT?  Doesn't the recipient have to
install something?  Unless you're proposing HTML (which you seem to lean
away from I've noticed), you're creating a problem by requireing yet another
piece of software to be installed on 100% of the machines and all of the
dozens of platforms out there, for all who want to see your new form of
artwork.

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

HTML is already very widespread, and perhaps by the time this time rolls
arond, news and email readers will have the capability as standard (Even the
version of Pine I use now handles HTML just fine).

But you are forgetting that there are doszens of platforms and (tens or even
hundreds of) thousands of computers that would need to be upgraded.

Who's going to write the needed HTMl software to read news and Email in HTML
format on all of these platforms?

What happened to ZERO EFFORT (by either the end users or the people who want
the new standard to really be a standard)?

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

Yeah, but on web pages, it's all fluff anyways.  Most of the crap I've seen
is just flashy stuff to get your attention, and detract from the overall
usefullness of the page.

(Yes, I've used graphical browsers on some very modern machines, and still
prefer Lynx for most stuff - no distractions)

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

But there is simply NO WAY for this to happen, now or in the future, unless
someone handles writing the needed software for every internet capable
platform out there.

I'm trying to tell you NO ONE will do it.  Sure people will write stuff for
PC's, Mac's, and maybe Linux/Unix - but what about the dozens of proprietary
platforms out there?

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

The basics are covered and have been for 20 years.  Like I said, you are NOT
ading any kind of code to an ASCII picture when you set your default font
and color settings - these are only used for your system to display what you
are creating.

When you save it, that artwork is ASCII art and contains no code of any kind
specifying anything you are using on your computer.

When that code reaches the recipient, it is displayed using his or her
default settings (even if they are wrong).  There's still nothing in the
code saying to use this or that font, or switch to a specific set of colors
(unless that ASCII artwork is imported into another format somewhere along
the line, HTML perhaps)

Specifying typographical settings like colors, or specific typefaces is not
done from within the picture, it is done completely and totally outside the
picture, for your viewer program only (well, perhaps for your whole system
depending on the system you use).  Those settings do not affect in any way,
shape, or form, how the artwork will be displayed on the recipient's
screen.

What you are proposing (letting the artist specify fonts and color, and so
on) does add stuff to the picture, in the form of font tags, color codes, or
whatever the format in question is using.  When that code reacies it's
target (the recipient), it will be displayed, and will be displayed right
only if the recipient has everything the artist has, in the way of
typographical capabilities (this especially includes specific fonts at
specific sizes).

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

Your views do not stand in this newsgroup.

Your views mave no merit at all, if you can't back them with proven facts or
quotations.

At least I've backed what I have to say with proven facts, and a few
quotations (the except of the ASCII chart I posted, and the definitions I
had to clarify from ym dictionary).

My viewes aren't necessarily facts either, but they are supported by facts,
and are accepted by this newsgroup and probably the rest of the ASCII
community as well (I could just as easily say that I agree with everyone
else, and that I am simply relating info that is and has been established
for 20 years).

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

Yeah, but at this exact moment, it is *YOU* who are prescribing that the
ASCII community try to take the leap forward now, by using HTML-aware
newsreaders and Email programs.

> > Ah, so you are proposing a new standard.  Great, let's see it.
> 
> No, I proposed piggybacking on mainstream developments, see above.

You still have yet to define this piggybacking scheme.

If my guess is right, you are actually poposing to simply take advantage of
the mainstream developments.  This isn't piggybacking.

Piggybacking by definition (in the context here) means to add to some
existing method in  a way that will not disturb a recipient who cannot use
the added data.

Example:  Color TV broadcasts.  They add a 3.84 some MHz color carrier on
top of the existing black and white signal, and yet even the oldest black
and white TV will still show the black and white portion of the picture
without the colors getting in the way.  The format method that defines this
is NTSC, and there are others as well, like PAL or HDTV.  All are standard,
none are 100% compatible with one another.

> But ascii art has at least two components, ascii code and typographical code,

ASCII art still requires only CODE element.  The ASCII code standard
(perhaps as defined by RFC-20?  I'd like to see it just for the purpose of
seeing it).

Typographical settings not embedded into the picture are not code in any way
or form (except with in the editor program); they are simply display
settings that make it easier for the artist to see what he is doing.  If he
is sending a pure ASCII file with no font/color/etc codes, then the
recipient has only one job, use the widely accepted standard to display that
artwork - a 7-bit fixed-spaced font.

In other words, the job lies with the recipient to select the font type
(fixed-spaced) that 99.99% of ASCII artists use.

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

Yes we are, and I'll just end this little bit by stating this (you already
disagree, but I refuse to argue this point anymore):

If the user doesn't know how to change thier settings appropriately for this
newsgroup (and for ASCII art in general), they they need to learn how.  If
they know how and wont, they're too damned lazy.  It's just a few mouse
clicks away for many, for others a single command at the command line to
install the right font, will do.

If you can't move your right hand around your desk and press a button a few
times, you probably need to seek medical attention or get the hell away from
your computer.

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

You know it's capabilities all right, but you are confusing them with the
capabilities that other media (such as HTML) offer.  ASCII alone, without
all the markup tags and crap, is capable of displaying some very good
artwork, and conveying most any idea you want, but not much beyond that.

And it is that low amount of capability (compared to other media) that
made ASCII so popular and so portable - you don't need anything fancy to use
it.  No special browsers, no custom fonts, nothing.  Just your system's
default fixed-spaced font and a command to view a text file.


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

 __
 \  \     _ _
  \**\ ___\/ \
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.