Subj : Notice To : Nicholas Boel From : mark lewis Date : Mon Feb 17 2014 19:04:57 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 * Origin: (1:3634/12.71) .