Re[2]: 80-columns and EMAIL

Chris,

I agree with you, but since I do not make company wide desisions which
EMAIL software to use, I have to put up with what I get.

Also, does uuencode exist on the PC? I have not heared about one yet.
As it is, I find myself showing files back and forth between my UNIX
and PC accounts, and because many times I forget about binary or ASCII
mode, I have to retry several times... How is that for wasting time?

As far as the restrictions are concerned, I thought the purpose of IBIS
was to make models easy to get or distribute. I am not in for more
restrictions (that is why I live in the US), but I think this might be
something to keep in mind.

On the other hand, if we are migrating in the non-readble direction, we
might even consider binary files. They would be much more compact. And
noone could read them, except machines...

Arpad

Arpad writes:

> One more comment on the 80-column issue. The IBIS files should not
-only be
> human readable but easy to transfer via EMAIL.

> We need to consider that some EMAIL softwares automatically wrap long
-lines and
> not only wrap but add an extra symbol to the beginning of the wrapped
-line to
> indicate that it was wrapped. Now, imagine you get an ibis file that
-is several
> thousand lines long, full with such automatically added trash in it.

> Are you going to edit it manually, or write a program to put it back
-to it's
> original format?

> CCMAIL does this, and there were times when I could not use electronically
> received SPICE model files for this reason.

If we had to constrain our design to something that every existing system
was capable of handling without any problems we would be sorely constrained.
I sugest that any mail system with such properties should be trashed. As a
work-around for those forced to use such things uuencode should solve the
problem.

Chris
Received on Tue Dec 14 09:43:22 1993