Subj : Notice To : mark lewis From : Nicholas Boel Date : Mon Feb 17 2014 11:34:26 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 " /\<>~!@#$%^&*()-=_+:;"'`,. " 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 * Origin: Dark Sorrow | darksorrow.us (1:154/701) .