Closed Bug 230984 Opened 21 years ago Closed 20 years ago

problems opening pdf attachments ; no such problem with MSOutlook2000

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 142517

People

(Reporter: postol, Assigned: mscott)

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 while opening a .pdf(acrobat reader) attachment - either from Thunderbird or after saving the mentioned file from Thunderbird to HDD - I got AcroRead(6.0.019.5.03) started; the file doesn't open, instead I get a message box telling the file is damaged. Repeating the same procedure with MSOutlook2000 (opening from the MUA directly or previously saving to disk) successfully opens the file. Reproducible: Always Steps to Reproduce: 1.click on attachment logo to open the (particular?!)pdf file attached 2.confirm the "open with ---> 'acroExch*' option in the "opening xx*.pdf" window Actual Results: 3.acroread gets loaded - and an error message gets displayed, reporting the file we tried to open is dameged - the file in fact is not opened. 4.retrying the identical procedure with MSOutlook gives the wanted results. Expected Results: open the attached file via AcroRead directly while clicking attachment's icon within Thunderbird OR first saving the pdf attachment from Thunderbird to HDD, then opening file with Acroread I have no idea wether the problem is file-specific (connected with this particular pdf file)and don't know how to attach the particular file in question to this report; in the past I experienced some problems in MSWin& some programs because of the "unproper" file names of certain files (presence of some characters), which made me register problems opening files; changing the file name however sometimes solved the problem and I could open the file in question May it be a similar case now? the file name is "85x3 Atœn Ac.Veg.Esloveno.pdf"
the attached are some files, which seem to be experiencing data corruption when a.)opening from Thunderbird with OpenOffice OOWriter 1.1.1a b.)saving & opening from the same program PLS NOTE the problem doesn't seem to be in OOWriter (or MSWord), since opening from Outlook with the mentioned word processors (or previously saving the attachment do HDD) doesn't lead to any problems.
Attached file sample of "problematic" attachment (deleted) —
another sample *.xls file; I have experienced similar problems SOMETIMES when trying to open attached files as regards files of type .pdf .jpg .doc
ERRATA: PLS NOTE: I've noted in the hurry I've mistakenly set the bug's reproducibility as "always"; IN FACT it should be "SOMETIMES";
This happens to me very regularly with .wav files also. I use an IMAP server (courier-imap); opening .wav files from TB causes them to be truncated after a few seconds about 75% of the time. Opening the same attachment in Outlook Express causes no problems at all.
I too am seeing this problem (not just with .pdf files) on a linux install. On a linux box, the corruption is occuring because TB is converting the file from a dos format to a unix format. It is converting all x'0d0a' occurances to x'0d'. This may work on text attachments, but it totally messes up a .PDF file because .PDF files have an 'offset index' for every object and since the file is reduced in size, the offsets are no longer correct. FYI, I also see this happen when TB saves an text attachement with the file type of .JSL. This should be a 1.0PR blocker! The operating systems should be changed to 'all'.
I have noticed what may be a pattern. Some emails save ok, some do not. On the ones that save good, have a mime header of: Content-Type: Application/pdf Content-Disposition: attachment; filename="MAINFRAME.PDF" Content-Transfer-Encoding: base64 Content-Description: MAINFRAME.PDF Those that save bad have a Content-Type of: Content-Type: application/pdf; name="BORDALA4.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BORDALA4.pdf" and also: Content-Type: application/octet-stream; name="FRM1UP.JSL" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="FRM1UP.JSL" Notice that one differences is the words 'Application" and "application". RFC 1521 indicates that the value for Content-Type is 'case-insensitive". Could it be something as simple as case-sensitivity?
This is probably a dupe of bug 142517. It's possible that the quoted-printable encoding mentioned in comment 6 is behind some of the problems encountered here. Another possible problem is the sending of attachments in an "appledouble" format, which I don't really understand, but I have seen related bugs that mention that. It is unlikely that the Application/pdf vs. application/pdf is the problem; neither would affect the encoding and decoding of the attachment. The truncated attachment under IMAP mentioned in comment 4 is a separate bug; Toby Johnson, see bug 92111, bug 107221,
No response from reporter, duping. *** This bug has been marked as a duplicate of 142517 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: