From: Bill davis newton (newton_at_mail.ecity.net)
Date: Fri Jun 29 2001 - 08:20:46 PDT
>From: Johannes Wolf <jwolf_at_xe.estec.esa.nl>
>Date: Fri, 29 Jun 2001 15:51:08 +0200
>Subject: [NTLK] AW: offtopic .sit/.zip files
>
> Hello Bob,
>
> In the past (when I was working with a Mac at work -> great fun) I
> often was faced to the problem that WinDose users could not open the
> files created by a Mac.
> First:
> If you compress the files you should use ZIP format. This is normally
> readable for every WinDose.
Not if they don't have an unzip program. ALL Macs ship with Stuffit
Expander. I don't think Windows machines are guaranteed to have an
Unzip progrm. They'll may still have to go get one. Most companies
will install it on their corporate machines...but home users or small
business users are a different story.
> Second:
> Different to a Mac which uses the so called resource fork of a file
> to find out the file type and which program has to be used to open it
No, they don't. They use the file's type and creator codes, which are
part of the file's directory entry. It has ABSOLUTELY nothing to do
with the resource fork.
HOWEVER: If your GIF or JPEG file HAS a resource form this might cause
problems for an email program. Many graphic files created by graphic
programs on the Mac do have resource forks; they often will put
a "thumbnail" custom icon on the document, and that goes in the
resource fork. Other things not integral to the file format may go in
the resource fork as well, such as saved printer settings. The Mac e-
mail program might then see the resource fork on the file when you try
to attach it and (in order to keep the file totally intact) they
may "macbinary" it before sending it. (Note that this is NOT the same
thing as BinHex). Macbinary files are BOTH forks of a mac file
encoded into a single fork. Needless to say, PC mail programs may not
be smart enough to deal with this.
You may need to find a little mac app to strip off the resource fork of
graphic files you are trying to send. (Use with caution; some file
types other than graphics file, and possibly even some graphics files
formats if they are proprietary to a program, may REQUIRE the resource
fork.)
Search www.versiontracker.com for "strip resource fork" and you'll
probably find something.
> - the stupid Windoses rely only on the extension!
True. You MUST use them if sending files to Windoze or *nix users.
Some programs are smart enought to look IN the file to see what file
type the file is, so you MAY be able to drag and drop the icon onto an
app in windows, but generally, do make things simple, you NEED the file
type. I'd stick to .gif and .jpg files (JPEG); virtually everyone can
read those because Web browsers will open and display them.
JPEGS are also (as you probably know) typically FAR, FAR smaller than
most other formats.
The Mac file type and creator codes are similar to windows filename
extensions, it's just done in a different way, and a better one, since
you have to go out of your way on the Mac to screw it up (whereas on a
PC all you have to do is accidentally change the file name and boom,
can't open it) and it allows you to have files of the same type but
belonging to different applications, if you want, yet you can still
drag one apps documents onto another program to open them so long as
both programs read/write the same file type.)
> So in general they have a problem with files having no extension
> (normally Mac files have none).
True.
> SOLUTION:
> use common graphic formats like JPG and name the files like
> "picture.jpg", so the PC will easily open those files
> for the ZIP Files it is the same problem: name them like
> "archive.zip", otherwise the PC would not realize that this is a
> ZIP-File ...
True....but since JPEG files are HEAVILY compressed already (unless
you've turned off or turned down the compression rate) and most other
graphic formats are similarly compressed, you may NOT want to bother to
zip a jpeg file.
Compressing a JPEG file generally doesn't save you any space, or very
little. In fact, it's quite possible that compressing an already
compressed file can make it BIGGER. It's often a waste of time, unless
you are trying to bundle several attachments into one file.
And (pet peeve here)...DON'T use "archive.zip" as a filename. Use a
more descriptive name before the ".zip". I get SO tired of
seeing "archive.sit", "archive.zip", etc. I often even see them on
web site download links!!!
The tip about keeping the filename to "8.3" (8 chars before, 3 after
the period, eg. "PICTURES.JPG" not "my pictures.jpeg" is also
important for utmost compatibility with older PC systems.
>
> Can you wonderful people help me.
> Its not newton related but you guys always come up with the goods.
> As some of you know, I am a photographer and
> I use a great program called Ivue to catalogue my work and it can
> make web
> pages up of any number of images.
> I have been trying to send small files of three or four images to
> prospective clients as a taster via email rather than the usual
> channels,phone , appt to show work etc.
> no problem with macusers, but PC users cannot open the files.
> How do I compress these files so that anyone can open them in
> explorer or
> navigator or indeed Icab.
> I dont want to attach an example so as not to use up too much
> space.If you
> need to see it, I would gladly send it to you offlist
This will be a thorn in your side forever, as it's a problem of USER
EDUCATION. There is only so much you can do from your end. Trust
me. Brains are required at the OTHER end, too, sometimes. The above
suggestions from me and other will HELP, but they won't always do the
job.
I used to work for a company that made programs that created and edited
graphics on the Mac and Windows. Our NUMBER ONE QUESTION was "how can
I e-mail graphics to xyz? I'm using a Mac/PC and they are using a
PC/Mac. When they get 'em, they can't open 'em." Even after telling
them all the things above, there's too many things that can go wrong:
-Is your email program encoding it behind your back in some other form
(it happens) Even if it's just e-mail MIME encoding stuff. Some email
programs don't do MIME, or don't do all MIME types.
-Can THEIR email program deal with that? Can they, if the email
program can't. Can you turn it off on your end?
-Did you name the file to end in .zip, .gif, .jpg or whatever is
appropriate?
- Do they have a program that can read that? (gif and jpg are pretty
safe, these days, since web browsers can open them... but PICT (.pct),
TIFF (.tif), Windows bitmap (.BMP) and others may not be....although on
a mac, and perhaps a PC, if they have QuickTime installed, it helps a
LOT with opening most common graphics format. And if it doesn't, get
Graphic Converter on the mac. It supports ZILLIONS of graphics file
types.
-Are those file types even mapped to a program on their PC. Are they
mapped to a program CORRECTLY (this can get screwed up.)
-Did the mac file get macbinaried before sending it (another "encoding
behind your back issue.)
-Does the user on the other end have a clue about PC file types, etc
(most do NOT, and won't want to learn).
See what I mean? No matter WHAT you do, SOME people will always have
problems. It'll drive you up a wall. Even if you're just going PC to
PC, not PC to Mac! (Mac to Mac usually isn't much of a
problem...especially since Quicktime is part of the OS)
It's might actually be easier to post 'em on a web page and let 'em
view 'em or download 'em that way by just clicking a link! Display the
graphic on the page with an IMG tag, and put an Anchor tag (a hotlink)
around it with an ftp link for the hotlink URL so it will download the
file when you click the picture. They can also just right-click (or
control-click on mac without two button mice) the picture and save it
to disk from there.
You might even want to consider providing the links in your e-mail
instead of the attachments. Or perhaps use HTML formatted mail.
-- This is the Newtontalk mailinglist - http://www.newtontalk.net To unsubscribe or manage: visit the above link or mailto:newtontalk-request_at_newtontalk.net?Subject=unsubscribe
This archive was generated by hypermail 2.1.5 : Sat Mar 08 2003 - 11:37:04 PST