Hello mark,

On 17 Feb 14 09:41, mark lewis wrote to Nicholas Boel:

 NB>> Can you point me to these specs you're speaking of?

 ml> the FILE_ID.DIZ spec? sure...

 ml> http://www.textfiles.con/computers/fileid.txt
 ml> http://www.wpusa.dynip.com/files/NEWFILES/fileid.txt
 ml> http://pcmicro.com/getdiz/file_id.html
 ml> http://en.wikipedia.org/wiki/FILE_ID.DIZ

Thank you for the links. Now tell me where in any of those I'm in the wrong 
with my file_id.diz for Agoranet? This is why this all started in the first 
place, correct?

While my .diz is exactly 45 lines wide, it is more than 10 lines long. Most 
BBS softwares I've encountered have added support for 99 line file_id.diz's, 
and anything that doesn't support it should just cut it off after the 10th 
line. With that being said (and planned on my part) you would still get the 
main description text on the 9th and 10th lines of the .diz, and the included 
files would be cut off, which if whatever software did so in displaying it, it 
wouldn't bother me any because the original file in the .zip would remain in 
tact the way it was created.

Those links mention "straight ascii text" quite a bit. Since when were 
characters like " /\~!{at}#$%^&*()-=_+:;"'`,. " NOT
straight ascii text?

Now here's a little discrepency for you, if you want to get all analitical 
about this:

From fileid.txt:

STRUCTURE:
----------

"The file consists of straight ASCII text, up to 10 lines of text, each line 
being no more than 45 characters long. It should *NOT* contain any blank 
lines, any form of centering or formatting, or any Hi-ASCII or ANSI 
characters. (i.e. it should ONLY contain alpha & numeric characters)."

Very well said, right? Now we'll take a look at the first line of the example 
under the same STRUCTURE header:

EXAMPLE:
--------
MY PROGRAM v1.23  - A program which will

[snip]

So it has already gone against it's "ONLY alpha & numeric
characters" rule, 
right (since it contains a period, and "" characters,
along with a hyphen)?
So where are we drawing the line here? Since the definition of alphanumeric 
characters don't include those characters, yet still have an alphanumeric 
value? How much are we puckering our assholes here, Mark?

And for what, so some outdated, unmaintained software doesn't become obsolete? 
I'm sorry, but I don't see a reason to stop hatching out someone's file(s) 
because the software someone chose to use (in such a position where better 
software is required) sucks. As I said, I'll gladly accept the fact that my 
infopack won't be hatched out in that echo anymore, since it's already 
available by plenty other means, but don't tell me how I should do things 
when your software doesn't work the way it should. I guarantee I've done the 
studying needed on the file_id.diz format, while the person hatching my file 
hasn't. The only reason something was said was because his software doesn't 
work the way it should and displayed the .diz like crap, which *I* am not to 
blame for.

 NB>> The specs that I've always  known have always been followed here.
 NB>> The fact that Tinytic (as well as  some other softwares) wrap the
 NB>> diz in places that it shouldn't.

 ml> how is that determined? does tinytic retain a diz's format when it is
 ml> less than 45 characters wide? all the software i'm aware of /will/
 ml> rewrap the description from the diz if it is longer than 45
 ml> characters... RemoteAccess' tools definitely do... the file database
 ml> editor even has a marker to show where the limit is when editing a
 ml> file's description...

That's the problem. Tinytic does NOT retain the .diz format when it's under 45 
characters wide. That has been a problem with Tinytic since I first tried it 
years ago. This is why I blamed software like that for the problem in the 
first place.

 NB>> Tinytic starts  a file's description at column 30 or something
 NB>> like that, and then wraps the  next line to the beginning of the
 NB>> line. Of course you're going to have messed  up looking diz's if
 NB>> you don't display it properly!

 ml> sounds like you're speaking of when it writes to files.bbs... does TT
 ml> not recognize the different forms of files.bbs when long descriptions
 ml> are in use? if not and if TT wraps the description all the time, then
 ml> it sounds like a problem with TT...

No. Not when it writes to files.bbs. When it outputs the file_id.diz into an 
announcement text file. I've already gone over this with the original Tinytic 
author, and his answer for me was something in the lines of "I'm pretty rusty 
at C++ these days, but here, try this fix: " 
and within a week disappeared once again. The software doesn't work as it 
should, and hasn't for quite some time (if it ever did at all).

If you'd care to fix it, by all means please do, then maybe this entire 
cherade wouldn't have happened in the first place!

 NB>> They shouldn't be re-wrapped at all. That's a software fault.
 NB>> Htick seems to  display it just fine, why can't other softwares
 NB>> do the same?

 ml> maybe other software is written to tighter specs? maybe other software
 ml> was written and not updated to fully support long descriptions
 ml> extracted from the DIZ or sent in the TIC's DESC and LDESC lines...
 ml> not all systems support extracting the DIZ and not all systems can
 ml> handle a single really long LDESC line in the TIC... there may be
 ml> multiple LDESC lines in the TIC but they are supposed to be used with
 ml> the DESC line and not as a replacement... a lot of what i've been
 ml> seeing has been chopped off descriptions and they seem to be mainly
 ml> originating at gert's system but others exhibit the problem, as
 ml> well...

Let me make my above statement a little more clear. When I say "they shouldn't 
be wrapped at all" that is, of course, as long as the .diz format is being 
followed, and is under 45 characters wide. And the fact that if you start the 
file_id.diz description on the 30th column of your announcement file, the 
second, third, fourth, and so on, lines should ALSO start on the 30th column.

Tinytic starts the first line of the .diz on the 30th column in the 
announcement text file. Then every other line starts on the 1st column. This 
should not be the case. Every line should start on the 30th column in order to 
maintain the 45x10 .diz format.

 NB>>> You will not have any limitations as to how I will hatch out
 NB>>> your network's  information packet that has been released the
 NB>>> same way for years,

 ml>> and they've been "not right" (as opposed to being
wrong) for all
 ml>> this time...

 NB>> I'd really like to know what's "not right" about it, Mark.
 NB>> file_id.diz's have  been used for 20+ years, and that entire time
 NB>> I've seen them in a bunch of  different variations. Even
 NB>> including the ascii characters above 128. While  mine doesn't
 NB>> include that, I've seen that display just fine as well.

 ml> no one is targetting anything specifically... it is just that these
 ml> things don't always come out properly... when they do not, then they
 ml> are "wrong"... ideally, a description should be able to
be wrapped and
 ml> not loose any detail... drawing ascii graphics (or including ANSI
 ml> codes as seen recently!) logos and putting them in the documentation
 ml> is one thing... putting then in the descriptions posted in numerous
 ml> formats is not always a good thing...

If noone is targeting anything specifically, what's the problem then?
I did not create the .diz for the recent artpack I released (which wasn't even 
released on Fidonet, but rather in my own network). But I'm not going to 
change it, either. 

Drawing ASCII graphics (with normal ASCII characters even) in file_id.diz's 
has been done for over 20 years. Some of the most popular programs back then 
used them. The problem is the fact that some software still in use either 
never did or hasn't adapted to that yet!


 ml>> .g00r00_presents__________ _
 ml>>    :     :: :  \   « ¬/ : :::  :
 ml>>  _ ____:_______/     / dEMONIC :
 ml>>      :: /           / pRODUCTIONZ
 ml>> _   :: /     y/    /____________
 ml>>     : /      /    /         « ¬/
 ml>>      /      /    /    y/      / :
 ml>>   _ /___________/_     ______/  :
 ml>>   :     : : :: /            / ::
 ml>>  _  _: _ _____/____________/_   _    _
 ml>> :
 ml>>   mpe add-on for mystic bbs v1.05
 ml>>   allows the user to select their current
 ml>>   message base via their arrow keys, using
 ml>> : a lightbar system.  mpe source included

 NB>> Yup. That displays exactly how it should be displayed. Even
 NB>> though it does  look like it includes a few ascii characters
 NB>> above 128. The regular ascii  (with the /'s and _'s) display a
 NB>> graphical "de" for the group "Demonic". 
Completely legible if
 NB>> you know what it's supposed to be.

 ml> i can't see it and never really have... that was copied and pasted
 ml> from a web page... it was all mashed together there...

And still after quoting it for the third time now (between you and I) it still 
displays perfectly fine over here. What was the problem again? The fact you 
don't have a sense or readability of ASCII art while many others do? I'm 
failing to see a technical problem here, but rather personal ones instead.

 ml>> what about this one?


 ml>> [[ >> qUICK lOGON mPE fOR mYSTIC 1.04b // ]]
 NB>>  ______>> ------->\____________>\---->\_______
 ml>> \_________    _//___ ________/_    _______/
 ml>> __/     -/     /    -______/_  \  /-    \_
 ml>> \______ _    //______ _    //___\/_     //mg
 ml>> --->>_______//--->>_______//--->>______//---
 ml>> dEMONIC mODDING aND cODING pRODUCTIONZ 1999!

 NB>> That one looks fine too, and doesn't include anything over ascii
 NB>> 128. That  logo spells out "DEM" for the same group
as mentioned
 NB>> above. I believe this  one even conforms to the file_id.diz
 NB>> format completely.

 ml> i definitely do not see a 'D', 'E' or 'M' up there... sorry :?

Again, third time quoted and still displays perfectly. The fact that you can't 
read it may be a problem here, but the technical aspect of how it is displayed 
seems to work wonderfully.

 ml>> or this one??


 ml>>   ,,a. Warlock
 ml>> ad$$$$aaa
 ml>>   `$$$$$  `$$, `$$$$,a.
 ml>>    l$$$$   l$$  l$$$$$$
 ml>>    :$$$$:: :$$$: $$$$$$
 ml>>     l$$$l :l$$$l $$$$$$
 ml>>     :$$$$ga,._ : :$$S"'
 ml>>      $$$y^       y"'
 ml>>      $$

 ml>> ..  Warlock Pack viewer door
 ml>> door for win32, linux, dos
 ml>> ---------------------------
 ml>> author  Gossamer Axe
 ml>> ---------------------------

 NB>> That one displays fine too. That's a "W" for the group that
 NB>> released it. Also  standard ascii characters used. So I don't see
 NB>> a problem with this one either.

 ml> again, this one was copied from a web page... those characters are not
 ml> standard ascii characters... here it is again in its original
 ml> format...

So what you're saying is that your editor properly converted it from CP437 to 
ASCII then? Wow, whaddya know? All I see above is $'s, and a few others 
regular ASCII characters.

 ml> ۖ�ۖ� ▀ۖ�ۖ�▓▀ BBS Mods, Darkness ۖ�▌ ▐ۖ�   IGMs, BBS
 ml> Logos    ▐▌ ▐▌   Menus, etc.,       ▐ ▓   Sept/2001
 ml> ▄ ▄    Leech It!      ▄▄ۖ�ۖ� ▐ۖ�▄▄▄▄▄▄▄▄▄
 ml> ▄ۖ�ۖ�ۖ�ۖ�ۖ�ۖ�ۖ�ۖ�▓▀▀
 ml>     ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

 ml> do you see the problem now?

Yep. It messes up when ANSI control codes are used. That's not new news. I'm 
still not going to modify an original zip file to change the original 
file_id.diz. It will remain released as is, and in my own network. The fact 
that it is added to my announcement file with the .diz being untouched 
by anyone, and that it is the original .diz that came with the archive, 
really matters to noone except the anal retentive people that just want to 
give a specific person a hard time. I've seen many others do it, yet I'm 
the only one that got flak for it? Well, my answer: Just like ignoring 
someone you don't want to converse with, there is always the 
next key.

The fact that I don't release them (on purpose, because of reasons like 
this) on Fidonet's FDN is an entirely different story, but now you're trying 
to tell me what I can and can't post on Fidonet even though many others post 
in CP866, UTF-8, other languages, and "happy Thanksgiving" and "Merry 
Christmas" ASCII posts all the time?

Oh, and by the way.. every one of those ASCII pictures you posted above that 
DID display exactly how they should have, have been converted to UTF-8 by me 
on my last two replies to you. See how nothing got changed? Just goes to show 
those are STANDARD ASCII -- just like my network's file_id.diz.

 NB>> Now this one looks like crap. Something was converted on it
 NB>> somewhere. It  probably had the ascii block and line characters
 NB>> in it, I'm assuming.

 ml> this is one of the problem points being brought up to be solved...

Solved how? By not releasing it at all? It's one thing that I don't hatch it 
out on Fidonet, but now you're telling me what I can and can't hatch in my own 
network because of an announcement file in echos that VERY few people actually 
read? Wow..

 ml> this is why only ascii characters should be used... the above was
 ml> converted because there's no way to display >128 CP437 characters in
 ml> all character sets... i've done what i can to set my pages to use
 ml> monospaced fonts but if your browser or OS doesn't use them for that
 ml> display, then you'll get proportional fonts and the characters shown
 ml> will be those in the slots used for the >128 characters in CP437...
 ml> ISO-8859-1 definitely doesn't have the line or block drawing
 ml> characters in it and ISO-8859-1 is used on a huge number of web
 ml> pages...

What are *NOT* standard ASCII characters in my AGORANET.ZIP's file_id.diz, 
Mark? Can you answer me that please?

The whole reason this was brought up was because someone is refusing to hatch 
infopacks that *DO* contain standard ASCII, yet he's calling it "high
ASCII" 
when it's not.

The artpack I released awhile back has absolutely nothing to do with this, was 
never released in Fidonet, and the majority of people have probably already 
forgotten about it.

 ml> ummm... those translations are done for the same reason as noted
 ml> above... xes and #es still look like crap in a description on a bbs or
 ml> a web page when they are used to replace ascii drawings...

In your opinion. Not in everyone's. I obviously can still read them just 
fine, and then also know exactly what they would look like if they weren't 
translated and displayed the way they were originally created in ANSI.

 ml>> the recent artpack release with a full graphic description is
 ml>> really really bad when seen on a web page... it is much worse
 ml>> when it is all wrapped... then there's what happens when it is
 ml>> cut short... i think i finally was able to see that it was
 ml>> supposed to be a skull...

Yay! You're ability to read ASCII/ANSI graphics seems to already be getting 
better. :)

 ml> folks using the same bbs software as you do display it wrapped... even
 ml> their announcement messages wrapped it and some of them chopped it off
 ml> at 4 or 5 lines... if i were an oblivious bbs user and i saw a file
 ml> with a description like that, i might report it to the sysop as being
 ml> corrupted or something... even if i didn't report it, i wouldn't
 ml> download it because i have no way of knowing what it is...

I can't help with what other people use for software, except point them in a 
direction of software that actually works the way it should. *shrug*

 NB>> So my offer still stands. If anyone wants their infopacks hatched
 NB>> out on  Agoranet's FDN, I'll gladly do it without altering their
 NB>> release whatsoever.

 NB>> If the requestor doesn't want to hatch my infopack anymore, I'm
 NB>> completely  fine with that, since I hatch it out in two other
 NB>> file areas as well as offer  it up via FTP. But I'm not going to
 NB>> change how I've been doing things for the  past however many
 NB>> years because someone's software can't do what mine seems to  do
 NB>> just fine. Sorry. :)

 ml> let's not forget that other software has been around as long or longer
 ml> and set the standards that your software supports... let's not forget
 ml> that we're talking about at least two different long descriptions
 ml> used... let's not assume that file_id.diz is always used(!) and
 ml> finally let's not forget that there are certain options that can
 ml> retain or break desriptions and this depends on the *system
 ml> operator*'s choices and how they want to present the information
 ml> provided based on their chosen theme...

I don't forget any of that, Mark. Most of the software I use is still 
currently maintained. There's one major difference. It is the sysop's choice 
whether they want to use outdated and unsupported software, just as it's their 
choice to bitch and gripe when something doesn't work correctly in this day 
and age. They're going to get the same response: change software to something 
that works correctly. Then again it's their choice whether they want to listen 
to that, or keep whining and crying that their current software doesn't work. 
*shrug*

Anyhow, my system here is set to use file_id.diz if it contains one, and if 
not to use the description from the files.bbs. Simple as that.

 ml> after a time, folks were complaining about the wasted space... a lot
 ml> of folks printed out the list so they could mark the files they wanted
 ml> to get and then mark them as having been downloaded... it is much
 ml> easier to look at a printed paper with hiliter marking to know what
 ml> still needs to be gotten ;)  so i decided to change the format i used
 ml> and went with a wrapped format...


 ml> filename     filesize  filedate   #### description line 1 description
 ml> line 2
 ml>                                        ... description line X

There you have it. You've changed the file_id.diz specs to wrap the line when 
it shouldn't. This result does *NOT* output what the file_id.diz originally 
displayed (ie: in a 45x10 area). Your choice by request of your users.

I have never had that request, and people actually have commented on how they 
enjoy the fact that the DIZ's are readable and display how they were 
originally created.

 ml> that was ok but still wasted space so i adjusted it and wrapped it
 ml> fully...


 ml> filename     filesize  filedate   #### description line 1 description
 ml> line 2 description line 3 description line 4 ... description line X

And completely obliterated it there..

 ml> later on, i decided to go back to a formatted style because so many
 ml> descriptions looked like total shit /because/ they were formatted with
 ml> ascii block drawing or line graphic frames in them


 ml> filename     filesize  filedate   ####
 ml> description line 1
 ml> description line 2
 ml> ...
 ml> description line X

Key words there are "so many". It was the way it was done for a very long 
time. I'd bet probably have of the BBS scene archive was done this way. So I 
don't see a problem with it one bit.

 ml> this last one kinda gives me the best results but is still
 ml> problematic... it can be hard to read when there's not a blank line
 ml> between the end of a description and the filename line of the next
 ml> file... i don't relish the idea of having to edit the descriptions of
 ml> ~15000+ files either ;)

IMO, your original format was the best. You've only moved your "wasted
space" 
to the other side of the screen with what you currently have.

Anyhow, I'm not going to argue about this anymore. My .diz completely follows 
spec besides the 10 lines rule. If software was made exactly to spec, it will 
cut it at the 10th line, which would still include all of what I would want 
included if it were to be cut off anyways.

The fact that some don't do this, is the fault of the software, or even PEBCAK 
if they have different options in their tic processor to choose from as to how 
their descriptions are displayed, and decide to use an option that displays 
things like crap.

The ANSI artpack I hatched was into my own network, and was announced in echos 
here on Fidonet that 99% of people don't even look at. Simple answer, hit the 
next key if a file_id.diz scares or disappoints you.

If you want to complain about that, start complaining about how the Russian 
cyrillic characters don't display properly in any BBS/FTN related programs. 
And well, since the rule of Fidonet is ASCII ENGLISH, it's against the rules. 
See how far you get with that one. :)

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910