problems opening pdf attachments ; no such problem with MSOutlook2000



Mail Window Front End
14 years ago
13 years ago


(Reporter: andrej kaligaric, Assigned: Scott MacGregor)


Firefox Tracking Flags

(Not tracked)



(2 attachments)



14 years ago
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( 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: 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"

Comment 1

14 years ago
Created attachment 140397 [details]
attachment saved on disk; error on opening

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.

Comment 2

14 years ago
Created attachment 140398 [details]
sample of "problematic" attachment

another sample *.xls file; I have experienced similar problems SOMETIMES when
trying to open attached files as regards
files of type


Comment 3

14 years ago
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"; 

Comment 4

14 years ago
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.

Comment 5

14 years ago
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'.

Comment 6

14 years ago
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;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
and also:
Content-Type: application/octet-stream;
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;

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?

Comment 7

14 years ago
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, 

Comment 8

14 years ago
No response from reporter, duping.

*** This bug has been marked as a duplicate of 142517 ***
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.