Re: [SL] latex dilemma & blank emails

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

I also modified my invoice template using the built-in editor in SL.  I 
had done this with a previous release with no problems, and the email 
worked everywhere.

In the meantime, I'm saving the invoices as PDFs when I display them in 
SL.  Then I'm sending them out manually from PINE.

Fred

On Thursday, April 11, 2002, at 08:11 PM, Keith Mastin wrote:

> 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
>
>
>
>