On Mon, 17 Feb 2014, Nicholas Boel wrote to mark lewis:

 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

 NB> Thank you for the links.

you are welcome...

 NB> Now tell me where in any of those I'm in the wrong  with my 
 NB> file_id.diz for Agoranet?

that would only be due to the ascii graphic logo thing and that it gets
broken all to hades on systems that wrap the (supposedly) plain ascii text
descriptions...

 NB> This is why this all started in the first  place, correct?

no sir... not that i'm aware of... there are quite a few that do the same
thing... agoranet is not and has not been singled out AFAIK...

[trim]

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

 NB> From fileid.txt:

 NB> STRUCTURE:
 NB> ----------

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

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

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

 NB> [snip]

 NB> So it has already gone against it's "ONLY alpha & numeric
 NB> characters" rule,  right (since it contains a period, and
""
 NB> characters, along with a hyphen)?

apparently the definition of alpha and numeric characters is different...
in a some languages, the alpha character set includes symbols... the
period, aka decimal aka point, is included in the numerical set...

[trim]

 NB> How much are we puckering our assholes here, Mark?

i'm not and i don't know why anyone else would be, either... hell, the
damned spec was written in 1994 for PCBOARD and then accepted and promoted
by the ASP (Association of Shareware Professionals)... after that, it
became a defacto standard used all over the world for many distributed
archives...

[trim]

 NB> something was said was because his software doesn't  work the way
 NB> it should and displayed the .diz like crap, which *I* am not to 
 NB> blame for.

no one ever singled you or your software out, nick... let's not get too
defensive here, ok? ;)

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

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

interesting... all the software that i'm aware of that wraps the DIZ does
it when the lines are longer than 45 characters... but i've also never
looked at tinytic because i wanted all the support i could get and i get
that from the leading package, allfix... i used to run the tick and hatch
packages back in the day but maintaining the config files was a PITA so i
moved to allfix and never looked back...

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

 NB> No. Not when it writes to files.bbs. When it outputs the
 NB> file_id.diz into an  announcement text file.

oh... but that's also only one part of the problem... the other place is in
the file area descriptions...

 NB> I've already gone over
 NB> this with the original Tinytic  author, and his answer for me was
 NB> something in the lines of "I'm pretty rusty  at C++ these days, but
 NB> here, try this fix: "  and within
 NB> a week disappeared once again. The software doesn't work as it 
 NB> should, and hasn't for quite some time (if it ever did at all). 

i'm sorry that you didn't find tinytic able to perform as you wanted it
to... many others also found it to be lacking and they moved on as well...

FWIW: allfix uses template files where you can specify and define what
fields appear where and how long they are to be...

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

sorry, i don't do C or C++ or .NET or numerous other languages...
especially C and related languages...

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

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

that stands to reason...

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

the problem here may be a config option... i don't know... it may also be
explicitly how the author wrote it to conform to their (political??)
feelings about the use of DIZ and how they personally felt that file
descriptions should appear...

BUT we're also not talking /only/ about the announcement postings... we're
also talking about how they are displayed in the BBS...

[trim]

 NB> If noone is targeting anything specifically, what's the problem
 NB> then?

maybe i wasn't clear? i meant that no individual, group, othernet, or
software was targetted... only that what was being used in the DIZ and
*moreso* in the LDESC fields of the TIC, with folks trying to have fancy
logos and the like, were the subject...

 NB> I did not create the .diz for the recent artpack I released
 NB> (which wasn't even  released on Fidonet, but rather in my own
 NB> network). But I'm not going to  change it, either. 

no one is asking you to change them...

[trim]

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

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

NO! you see what i saw... there was no editor involved other than the
message editor... it looks the same on the web page other than being mashed
up from the font and character set used...

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

 ml> do you see the problem now?

 NB> Yep. It messes up when ANSI control codes are used.

there was no ansi codes in there at all!

[trim]

 NB> Oh, and by the way.. every one of those ASCII pictures you posted
 NB> above that  DID display exactly how they should have,

they were not displayed exactly as they should have been /because/ some
characters were converted *before* i copied and pasted them in to the
message...

 NB> have been converted to UTF-8 by me  on my last two replies to you. 
 NB> See how nothing got changed? Just goes to show  those are STANDARD 
 NB> ASCII -- just like my network's file_id.diz. 

i'd like to know how the single character 1/2 and 1/4 characters got in
there? they were not in the original ASCII description... they were put
there my the browser character set and stayed there when i pasted them in
here... all those capital 'U' looking characters were the converted the
same way... and that 'W' from warlock was also converted...

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

 NB> Solved how? By not releasing it at all?

no... solved by using the 7-bit a-zA-Z0-9 and symbol characters...

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

no one is telling you that, nick... christ... i'm done with this because it
has gone much further than it ever should have and you've become all
defensive and are ''attacking back'' to a perceived attack on you, your
software and your methods and beliefs...

the simple fact of the matter is that drawings of any kind really do not
belong in descriptions in DIZes or in LDESC lines of TIC files... period,
end of statement... i'm not the only one saying this and i haven't been for
years...

the ONLY reason i got involved in this conversation in this message area
was because of your response to robert's post... all i tried to do was to
clarify what was going on, why it was going on and how to deal with it...
i've said what needed to be said and i'm not going to argue or debate or
similar about it any more... it isn't worth all the crap... the spec is
easily read and understood... logos and the like simply don't belong in the
description of a file on a bbs -=BECAUSE=- "you" (inclusive)
cannot control how others display those descriptions and surely
"you" (inclusive) want "your" (inclusive) files'
descriptions to be legible in any format... think about that instead of the
artistry involved and trying to pretty things up...



)\/(ark

One of the great tragedies of life is the murder of a beautiful theory by a
gang of brutal facts. --Benjamin Franklin

--- FMail/Win32 1.60