Re: [SL] latex dilemma & blank emails

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I still have the same problem as David. I don't have an M$ machine so I 
don't get to blame uncle bill for this one... I send numerous test 
emails to myself on a different email account and they now arrive with a 
size of 4626... much improved over 7. However, they are still blank, and 
I cannot view them in netscape. I can open the file in vi, and noticed 
that there is no <html> tag there, and so I checked the code on the 
template, there is still no html tag, so I added one... still cannot 
view the (parsed) output in a graphical viewer.

Now, to be fair, I did this with an altered html invoice template, and 
perhaps the alterations are to blame, so I just did a test with the 
original invoice...      :\         ... it worked.

(keith heads back to the drawing board)

On Thu, 11 Apr 2002, Dieter Simader wrote: 
>
>There is an upgrade file available for 1.8.3 which addresses the line
>length for attachments. Apparently this fixed the problem Outlook was
>having with decoding the attachments.
>
>On Thu, 11 Apr 2002, David Ratte wrote:
>
>> This is NOT just an outlook problem, I've been complaining about this since 
>> 1.8.3 came out and have not been able to figure it out myself.
>> 
>> I don't have any microsoft stuff in the building here and I can't read my own 
>> emails using konqueror, netscape 4.75, or anything else!
>> 
>> I've checked the CPAN code Dieter used and can't find anything wrong with it. 
>> The only difference is the maximum line length is a little shorter, but 
>> changing it back to match the original does not fix the problem.
>> 
>> I still believe the CPAN code has an issue though, because if you look at the 
>> raw output of sendmail as compared to other BASE64 documents generated by 
>> other programs, documents from other programs have the code all line up in 
>> neat little rows, where the CPAN code looks like a scrambled mess.
>> 
>> For the moment, all I was able to do to continue to function with my 
>> customers, was to comment skip the base64 encoding routine (and send the 
>> documents un-encoded)
>> 
>> But, meanwhile I have bigger fish to fry - currently I have a postgres ut-oh 
>> such that my database is corrupt and after a re-index only contains 3 
>> records, even though a look at the raw files shows much more... anyone know a 
>> good postgres database recovery service?
>> 
>> -Dave Ratte
>> Superior Circuit Technologies, Inc.
>> dr...@su...
>

-- 
Keith Mastin	     km...@be...
BeechTree Information Technology Services Inc.
137 Laird Drive    M4G 3V5    Tel(416)696-6070
	   http://www.beechtree.ca