> >*EERRRRRR* wrong answer! It's not because you can read a large part of a > >file that it is text/plain (i.e. pure ASCII TXT). PDF files can contain > >binary objects and streams. Even text-only files can contain binary bitmap > >font info, digital signatures, DRM info, logos (more often than not in > >business documents), print info, ... > > In fact, unlike embedded objects in PS, the binary data is in raw > >format, not MIME encoded (binhex'ed, base64'd, ...) like in an email. The > >text you see when reading a PDF is the PostScript framework on which a PDF > >is based. While you might have a text-only PDF, this is hardly the > >general case and since it is NOT pure ASCII, you need a correct MIME type > >in order to guarantee its integrity (especially on non-ASCII foreign systems).
pdf in many cases only uses characters that conform to a charset. Thus it's going to show as text/plain without a mailcap. That's correct. However, it doesn't really matter if it has binary data in it or not. As long as the characters are in a definable charset then MIME considers the file text/plain in the lack of other information. So as far as MIME is concerned a text file is defined not by following ASCII but by following a charset. ASCII is merly one of those charsets not the only charset. We can argue till we die about what is and is not a text file. But ultimately it doesn't really matter because as I'll explain below the type has nothing to do with Tibor's problem. > > So Ben, either you didn't look deep enough in your example files or your > >files are the exception, rather than Tibor's. (See attachment, look for > >"stream" and what follows. Also check it with a hex-editor and you will > >see that it even contains NULL characters for example. Yes, at the end it > >contains a simple line drawing. I don't think all the binary is related > to that, in fact, it can be easily handled by EPS.) You'll note that I said some of my examples weren't that way. I had ones that are very likely like his and ones that aren't. They all worked. Heck one of them was a PDF for a manual for a thermostat that has pictures and binary data all over in it. If anyone is interested I'll be happy to email you a bunch of PDF's all with the wrong type set on them that I can assure you unless your mailserver or mail client messes them up will come through just fine. > >However, I could be completely wrong. Anyway, I thought this list was to > >report problems. Let Mandrake decide what goes in the distribution > >and don't shoot the messengers (even when they sound ignorant to > >you) because you think they are stupid (an impression (not by me) obviously > >based on bad English language skills). The distribution is targeted at > the desktop (i.e. client (f.i. mutt) fine tuning and easy, complete > configuration), isn't it? This is not clear to me anymore, lately... > (notice *tongue in cheek* for the humor-impaired) This list exists not just to report problems but to discuss issues related to cooker. A missing dependency and if it is really a dependency is most certainly worthy of discussion. As far as if I think Tibor is stupid or not... well if there is any feeling that he is it mostly has to do with his circular logic. He starts at by saying look at the RFC and tells me that my experience doesn't matter that we should follow the RFC. So I do go look at it. I show him how mutt follows the RFC and that the RFC properly covers not having a mime.types file. Then he asserts that it doesn't matter what the RFC says that his experience of sending a message trumps it. He also makes assumptions that the correct MIME type would have resolved his one single issue in sending a message. However, according to his message he has yet to try it with the correct mime type, instead opting to send the file to his partner by uploading it to a web site and having his partner download it. Therefore, we have no way of knowing that the correct mime type really resolves his issue, but he veametly argues that it does. Finally, the assumption that the MIME type is the problem shows a fundamental lack of understanding of MIME. The type is there for the receiver of the data to determine what program can handle that type. It has nothing to do with the encoding. You can base64 text/plain, in fact many spammers do this in order to try and avoid filters. The encoding is marked by the Encoding tag not the Type tag. Encoding is determined based upon the content of the file irrespective of the type. If both sides support the encoding chosen the file will be decoded on the receiving side just fine. As I already pointed out mime.types is just a mapping between file extensions and mime types. It contains no information about recommended/required encodings and mutt doesn't use the type to aid in determining the encoding. However, I guess I don't think Tibor is stupid. But rather misunderstanding the way things work and asking for something that is unnecessary. I've already suggested that rather than a Requires that we just raise the priority of the mailcap package (essentially making it install by default). This would allow someone who doesn't want the package to remove it, but still would cause people doing basic installs to still get it. This prevents a Requires on a package that I still insist isn't really required. But would give Tibor what he wants, makes mailcap get installed by the installer. So what is showing on my part towards Tibor is frustration on the fact that he did not study the resources he pointed out as supporting his position (the RFC's regarding MIME in this case). And the fact that it appears to me that he has done very little testing of the problem and has jumped to a conclusion based on invalid assumptions. That doesn't make him stupid but it still makes him wrong. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org We tend to see all wars through the lens of the current conflict, and we mine history for lessons convenient to the present purpose. - Brian Hayes
