Hello mark,

On 17 Feb 14 19:04, mark lewis wrote to Nicholas Boel:

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

The "ascii graphic logo thing" that contains *only* normal ASCII symbols? 
Which some of those same symbols are used in the fileid.txt spec as an 
example?

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

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

This started because I offered up my services to hatch out network 
information packs (unaltered) to others (like me) that were threatened with 
not distrobuting their files(s) because they contain STANDARD ASCII 
characters in them, which the file_id.diz spec clearly shows in use as an 
example.

If one person that moderates one FDN is going to threaten others with 
non-distrobution because they can't figure out how to hatch something 
properly, I'll offer an easier solution with no threats. One person's faults 
is another person's gain. *shrug*

 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
 NB>> text, each line  being no more than 45 characters long. It should
 NB>> *NOT* contain any blank  lines, any form of centering or
 NB>> formatting, or any Hi-ASCII or ANSI  characters. (i.e. it should
 NB>> ONLY contain 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)?

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

Well, apparantly the definition of it that's in the actual spec file shows 
standard ASCII symbols being used. This makes my network's .diz perfectly 
legit.

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

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

And that entire time file_id.diz's have included standard ASCII symbols in 
them. So why was this all brought up again?

 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.

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

Sorry, but you jumped on my case because I offered to hatch out othernet 
information packs because someone else threatened to stop distrobution because 
of standard ASCII, which is completely legit when it comes to spec. It's not 
our fault he uses Tick v1.0 or whatever the hell it is from the 90s because 
he can't configure Allfix properly even though he's a beta tester [shudder], 
and 90% of the time can't even get the "replace" option correct
so they don't 
get hatched when they're supposed to anyways.

 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.

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

You can look at it if you wish, but just look at some of the postings in 
ALLFIX_FILE or FDN_ANNOUNCE that were posted by Tinytic, use a file_id.diz 
that is less than 45 characters wide, and contains more than one line. You'll 
see the problem instantly.

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

If Allfix had a Linux version, I'm sure I would have used it by now.

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

 ml> that stands to reason...

It's software like that where you see .diz's displayed improperly. I can even 
deal with replacing ASCII >128 with standard ascii characters (obviously for 
display purposes only, and not to alter any original files in any way, shape, 
or form), but it has been shown that web pages, BBSs, file hatching 
mechanisms, and whatever else can display these file_id.diz's properly. So 
with that being said, the choice of what software you use to create and 
display these things are completely up to the sysop - whether is works 
properly or not.

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

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

It's definitely not a configuration option when it comes to Tinytic. There 
really aren't many configuration options for that program in the first place, 
let alone anything for display purposes, that is all done in the code itself, 
which I've tried to modify without success, and so has the original author in 
the past.

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

My BBS seems to display all of these file_id.diz's just fine over here as 
well. I'm definitely not seeing the same issue you are.

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

Still not seeing a problem with the DIZ or LDESC fields, or how it's 
displayed on my BBS or archives.thebbs.org either. You targetted me by 
replying to my offering to hatch out files on another FDN, and specifically 
brought up my othernet's DIZ containing standard ASCII characters that make up 
a "fancy logo" which has been done for decades prior to me doing
it.. as well 
as some random ANSI artpack I hatched out in another FDN a week or two ago. 
I'm not the first, and definitely won't be the last to do so.

Every sysop has control over the software they use. If they choose to use 
software that displays the stuff incorrectly while it still follows spec, 
that's completely up to them. But if you come crying about it, I'll just point 
you at software that does display it all perfectly. It is your choice how you 
want to go from there. (this isn't directed at you, personally, but more of a 
generalization to be clear).

 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.

 ml> no one is asking you to change them...

So this entire thread was some kind of rant because you can't read "fancy 
logos" created with ASCII characters?

I offered a service, and you replied (seemingly) blaming things like my 
network's .diz and an ANSI artpack I hatched out somewhat recently as 
examples. So if you're not asking me to change them, then what are we talking 
about, and why are we talking about it still!? :)

 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.

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

Then you probably saw it in it's original form, and how it was meant to be 
displayed. It was also probably done in standard ASCII characters as well.

 ml>> Û–ˆÃ»ÃªÛ–ˆÃ»Ãª ΓûÇۖˆÃ»ÃªÛ–ˆÃ»ÃªÎ“ûôΓûÇ BBS Mods,
 ml>> Darkness Û–ˆÃ»ÃªÎ“ûî ΓûÉۖˆÃ»Ãª   IGMs, BBS Logos    ΓûÉΓ
 ml> ûî ΓûÉΓûî   Menus, etc.,       ΓûÉ Γûô   Sept/2001 Γûä
 ml>  Γûä    Leech It!      ΓûäΓûäۖˆÃ»ÃªÛ–ˆÃ»Ãª
 ml>> ΓûÉۖˆÃ»ÃªÎ“ûäΓûäΓûäΓûäΓûäΓûäΓûäΓûäΓû
 ml>> ä
 ml>> ΓûäۖˆÃ»ÃªÛ–ˆÃ»ÃªÛ–ˆÃ»ÃªÛ–ˆÃ»ÃªÛ–ˆÃ»ÃªÛ–ˆÃ»ÃªÛ–ˆÃ»ÃªÛ–ˆÃ»ÃªÎ“û
 ml> ôΓûÇΓûÇ
 ml>>     ΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓûÇΓ
 ml> ûÇΓûÇΓûÇΓûÇΓûÇ

 ml>> do you see the problem now?

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

 ml> there was no ansi codes in there at all!

Ah, you're right. No ANSI codes because it was saved as block ASCII, which are 
characters above 128, which is where the problem lies.

 ml> [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,

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

Then you didn't provide good enough examples. When they were pasted here 
(besides the two bottom ones that were obviously >128 and converted to 
complete garbage), they looked fine.

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

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

They weren't there on my display. As I said, all of them besides the bottom 
two that were completely mangled displayed here as standard ASCII characters. 
Maybe because I'm using UTF-8? I don't know. But they looked fine over here.

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

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

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

Wait.. So now there's nothing wrong with my file_id.diz for Agoranet? What you 
mention in the above sentence is all it has ever contained. I wouldn't create 
a file_id.diz with ASCII >128.

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

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

Since you directly replied to me, and used my network's .diz and some random 
ANSI artpack I hatched out a week ago as examples while poking and prodding 
me about specs, yeah, I thought it was a pretty good perceived attack on me. 
That's the only way I was able to take it off the very first reply anyway. 
Either that, or you have to work on your text-based communication skills, as 
this isn't the first time something you said got someone instantly defensive.

With that said, and now that we've concluded that my network's .diz is, in 
fact, proper according to the original spec (we did establish that, didn't 
we - aside from you personally not liking ascii logos and pictures, of 
course?).. the fact remains that the FDN coordinator is going to discontinue 
hatching it (as well as others) because he's completely clueless as to those 
specs, and doesn't realize the software he's using to hatch them is garbage. 
His FDN, his choice obviously. Which is why I offered to hatch them for 
anyone that is going to be shunned by that coordinator, somewhere else. Then 
you got involved and here we are now.. *shrug*

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

Says you and maybe a few others? The only person I've seen complain about it 
in the last 2-3 years is you, Mark. There is no simple fact of the matter 
except your own opinion here. Well, you know what opinions are like..

 ml> the ONLY reason i got involved in this conversation in this message
 ml> area was because of your response to robert's post... all i tried to
 ml> do was to clarify what was going on, why it was going on and how to
 ml> deal with it... 

Well, you've obviously noticed by now that I don't agree with it, and am 
offering a solution to others that are going to get shit on for the same 
reasoning. If the only way to deal with it is to threaten others that use 
your FDN, then another one will be used instead. No harm, no foul.

 ml> i've said what needed to be said and i'm not going to
 ml> argue or debate or similar about it any more... it isn't worth all the
 ml> crap... the spec is easily read and understood... logos and the like
 ml> simply don't belong in the description of a file on a bbs -=BECAUSE=-
 ml> "you" (inclusive) cannot control how others display those
descriptions
 ml> and surely "you" (inclusive) want "your"
(inclusive) files'
 ml> descriptions to be legible in any format... think about that instead
 ml> of the artistry involved and trying to pretty things up...

Some people enjoy some artistry in their lives. Then again, some don't.

So logos and the like simply don't belong because Mark Lewis can't read 
them and says so. Mmkay. Point made, and ignored. Anyhow, thanks for the links 
to the .diz specs where I was able to confirm I'm within the spec no matter 
how you or anyone else sees it.

 ml> 

Good idea!

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910