Subj : Notice To : Nicholas Boel From : mark lewis Date : Mon Feb 17 2014 09:41:36 On Sun, 16 Feb 2014, Nicholas Boel wrote to mark lewis: NB>> Don't use garbage software and you won't have that problem. ml> that's not the problem, nick... the problem is some descriptions are ml> 1. too long (trying to list everything in the doc file) ml> 2. look like crap when rewrapped ml> 3. look like crap on web pages ml> the descriptions are supposed to conform to the FILE_ID.DIZ spec... NB> Can you point me to these specs you're speaking of? the FILE_ID.DIZ spec? sure... http://www.textfiles.con/computers/fileid.txt http://www.wpusa.dynip.com/files/NEWFILES/fileid.txt http://pcmicro.com/getdiz/file_id.html http://en.wikipedia.org/wiki/FILE_ID.DIZ 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. how is that determined? does tinytic retain a diz's format when it is less than 45 characters wide? all the software i'm aware of /will/ rewrap the description from the diz if it is longer than 45 characters... RemoteAccess' tools definitely do... the file database editor even has a marker to show where the limit is when editing a file's description... NB> Tinytic starts a file's description at column 40 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! sounds like you're speaking of when it writes to files.bbs... does TT not recognize the different forms of files.bbs when long descriptions are in use? if not and if TT wraps the description all the time, then it sounds like a problem with TT... ml> the descriptions still look like crap when they get rewrapped or ml> displayed on web pages no matter what network they are hatched out ml> into... NB> They shouldn't be re-wrapped at all. That's a software fault. Htick NB> seems to display it just fine, why can't other softwares do the NB> same? maybe other software is written to tighter specs? maybe other software was written and not updated to fully support long descriptions extracted from the DIZ or sent in the TIC's DESC and LDESC lines... not all systems support extracting the DIZ and not all systems can handle a single really long LDESC line in the TIC... there may be multiple LDESC lines in the TIC but they are supposed to be used with the DESC line and not as a replacement... a lot of what i've been seeing has been chopped off descriptions and they seem to be mainly originating at gert's system but others exhibit the problem, as well... NB>> You will not have any limitations as to how I will hatch out your NB>> network's information packet that has been released the same way NB>> for years, ml> and they've been "not right" (as opposed to being wrong) for all this ml> 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 including NB> the ascii characters above 128. While mine doesn't include that, NB> I've seen that display just fine as well. no one is targetting anything specifically... it is just that these things don't always come out properly... when they do not, then they are "wrong"... ideally, a description should be able to be wrapped and not loose any detail... drawing ascii graphics (or including ANSI codes as seen recently!) logos and putting them in the documentation is one thing... putting then in the descriptions posted in numerous formats is not always a good thing... ml> it isn't the software that's the problem and we are trying to get ml> folks to conform to the DIZ specs... it is also not just robert's FDN ml> but all the others where this has been happening... folks are ml> complaining again just like they do every few years... i get notes ml> from users asking me why my file descriptions look like crap and i ml> just point to the FDN distribution and whoever created the DIZ with ml> the mess inside it :shrug: NB> Again, htick displays file_id.diz's the way they were meant to be NB> displayed. I don't know why other software can't do the same? ummm... htick and tiny tic and other tic processors don't display the descriptions unless they do it during processing... it is the bbs software and associated tools that enable folks to see the descriptions... ml> eg: can you read the following?? i can't... 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 though NB> it does look like it includes a few ascii characters above 128. NB> The regular ascii (with the /'s and _'s) display a graphical "de" NB> for the group "Demonic". Completely legible if you know what it's NB> supposed to be. i can't see it and never really have... that was copied and pasted from a web page... it was all mashed together there... 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 format NB> completely. i definitely do not see a 'D', 'E' or 'M' up there... sorry :? 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 a NB> problem with this one either. again, this one was copied from a web page... those characters are not standard ascii characters... here it is again in its original format... ÜÜÜÜÜÜÜÜÜÜÜ °ßßß ÜÜÜÜÜ ß²ßÛÛÛ² ÜÜÜÜÜga ÜÜÛÛÛÛÛÛÛÛÛÜ ÞÛÛÛ² ßßÛÛÛÛÛÛ²±°ßßß°°ÛÛÛÛÛÝ ÛÝ°Û² ßÛÛÛÛ² ÞÛÛÛÛÝ °ßÜÛ ÜÛÛÝÞÛÛÛÛÝ ÞÜÜ ÛÛÛÛÛ ÛÛÛ² ÛÛ² ÞÛßÜ°Ý ÛÛÛÜ ÛÛÛÛÛ ÞÛÛ²² Û² ÛÝ ±Ý ÛÛÛÛ ßÛÛÛÛÝ ÛÛÛ² Ûß ÛÛ°°Ý ÞÛÛÛÛ ÞÛÛÛÛ ÞÛÛ²² Ü ÞÛÛÛÛ ÞÛÛÛÛ ÞÛÛÛÛ ßÛÛ² ÛÝßÞÛÛÛÛ ° ÛÛÛÛ ÛÛÛÛ² ÛÛÛ ÛÛ ÛÛÛÛÛ ²ÛÛÛ° ÛÛÛ²²Ý Û²²±°° ÛÛÜ ßÛÛÛÛܰܲ²ÛÛÛÜÛÛÛÛ²ß ÞÛÛÛ ÞÛÛÛÜÜ ßßÛÛÛÛÛÛÛÛÛÛßß ÜÜÛÛÛ²² Û߰ݲ²ÜÜ ßßßßßß ßÛÛ²² ÞÝ °±² Warlock ÞÛ²²Ý Û°° °Û pack #001 ÞÛÛ ßÛÛ²ß BBS Mods, Darkness ÛÝ ÞÛ IGMs, BBS Logos ÞÝ ÞÝ Menus, etc., Þ ² Sept/2001 Ü Ü Leech It! ÜÜÛÛ ÞÛÜÜÜÜÜÜÜÜÜÜÛÛÛÛÛÛÛÛ²ßß ßßßßßßßßßßßßßßß do you see the problem now? ml> or this one... ml> ÜÜÜÜÜÜÜÜÜÜÜ ml> °ßßß ÜÜÜÜÜ ß²ßUUU² ml> ÜÜÜÜÜga ÜÜUUUUUUUUUÃœ _UUU² ml> ßßUUUUUU²±°ßßß°°UUUUUY UY°U² ml> ßUUUU² _UUUUY °ßÜU ml> ÃœUUY_UUUUY _ÜÜ UUUUU UUU² ml> UU² _UßÜ°Y UUUÃœ UUUUU _UU²² ml> U² UY ±Y UUUU ßUUUUY UUU² ml> Uß UU°°Y _UUUU _UUUU _UU²² ml> Ãœ _UUUU _UUUU _UUUU ßUU² ml> UYß_UUUU ° UUUU UUUU² UUU ml> UU UUUUU ²UUU° UUU²²Y U²²±°° ml> UUÃœ ßUUUUܰܲ²UUUÃœUUUU²ß _UUU ml> _UUUÜÜ ßßUUUUUUUUUUßß ÜÜUUU²² ml> Uß°Y²²ÜÜ ßßßßßß ßUU²² ml> _Y °±² Warlock _U²²Y ml> U°° °U pack #001 _UU ml> ßUU²ß BBS Mods, Darkness UY ml> _U IGMs, BBS Logos _Y ml> _Y Menus, etc., _ ml> ² Sept/2001 Ãœ ml> Ãœ Leech It! ÜÜUU ml> _UÜÜÜÜÜÜÜÜÜÜUUUUUUUU²ßß ml> ßßßßßßßßßßßßßßß NB> Now this one looks like crap. Something was converted on it NB> somewhere. It probably had the ascii block and line characters in NB> it, I'm assuming. this is one of the problem points being brought up to be solved... this is why only ascii characters should be used... the above was converted because there's no way to display >128 CP437 characters in all character sets... i've done what i can to set my pages to use monospaced fonts but if your browser or OS doesn't use them for that display, then you'll get proportional fonts and the characters shown will be those in the slots used for the >128 characters in CP437... ISO-8859-1 definitely doesn't have the line or block drawing characters in it and ISO-8859-1 is used on a huge number of web pages... ml> now, take a look at them on a web page... ml> http://www.wpusa.dynip.com/files2/FDIST/DDSBBS/ ml> http://www.wpusa.dynip.com/files2/FDIST/DDSDOORS/ NB> With that being your webpage, now take a look at the plethora of NB> door games and artpack's on htt://archives.thebbs.org .. Besides NB> the block/line ascii characters being translated to x's and #'s, NB> everything seems to display as it should. Maybe you didn't go the NB> extra mile to make sure yours displays file_id.diz's that have NB> been done this way for the last few decades (if you notice there NB> are ACiD artpacks on there from 1993 and sooner)? I don't know. ummm... those translations are done for the same reason as noted above... xes and #es still look like crap in a description on a bbs or a web page when they are used to replace ascii drawings... ml> the recent artpack release with a full graphic description is really ml> really bad when seen on a web page... it is much worse when it is all ml> wrapped... then there's what happens when it is cut short... i think i ml> finally was able to see that it was supposed to be a skull... NB> It shouldn't be wrapped. It should be displayed exactly how it was NB> meant to be displayed. The recent Blocktronics artpack release, I NB> can agree, is very long, and is in all block ascii. That's the way NB> they wanted to release it, and I'm not going to alter their NB> artpacks in any way. Just as well, my hatching program displayed NB> it perfectly. It is noone's choice but their own as to what NB> software they use to take care of these tasks. I choose to use NB> software that works in this case. folks using the same bbs software as you do display it wrapped... even their announcement messages wrapped it and some of them chopped it off at 4 or 5 lines... if i were an oblivious bbs user and i saw a file with a description like that, i might report it to the sysop as being corrupted or something... even if i didn't report it, i wouldn't download it because i have no way of knowing what it is... 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 file NB> areas as well as offer it up via FTP. But I'm not going to change NB> how I've been doing things for the past however many years because NB> someone's software can't do what mine seems to do just fine. NB> Sorry. :) let's not forget that other software has been around as long or longer and set the standards that your software supports... let's not forget that we're talking about at least two different long descriptions used... let's not assume that file_id.diz is always used(!) and finally let's not forget that there are certain options that can retain or break desriptions and this depends on the *system operator*'s choices and how they want to present the information provided based on their chosen theme... eg: at one time, my files list looked like a files.bbs format filename filesize filedate #### description line 1 description line 2 ... description line X after a time, folks were complaining about the wasted space... a lot of folks printed out the list so they could mark the files they wanted to get and then mark them as having been downloaded... it is much easier to look at a printed paper with hiliter marking to know what still needs to be gotten ;) so i decided to change the format i used and went with a wrapped format... filename filesize filedate #### description line 1 description line 2 ... description line X that was ok but still wasted space so i adjusted it and wrapped it fully... filename filesize filedate #### description line 1 description line 2 description line 3 description line 4 ... description line X later on, i decided to go back to a formatted style because so many descriptions looked like total shit /because/ they were formatted with ascii block drawing or line graphic frames in them filename filesize filedate #### description line 1 description line 2 .... description line X this last one kinda gives me the best results but is still problematic... it can be hard to read when there's not a blank line between the end of a description and the filename line of the next file... i don't relish the idea of having to edit the descriptions of ~15000+ files either ;) )\/(ark * Origin: (1:3634/12) SEEN-BY: 229/426 103/17 705 102/401 103/1 218/215 810 840 850 301/1 218/860 SEEN-BY: 218/880 214/22 218/900 910 870 930 601 940 124/5016 218/700 1 10/1 SEEN-BY: 218/0 10/0 .