Re: [hylafax-users] Text => Postscript converson in faxmail

[Aidan Van Dyk <aidan@xxxxxxxx>]

* Martin Bene <martin.bene@xxxxxxxxxxxxx> [071012 14:48]:
> Hi Aidan,
> 
> Well, I found the previously used converters based on mime type quite
> nice. The content - based classification used by typerules effectively
> discards valuable information (i.e the mime-type) present in the email
> structure.

Fair enough.  In my experience, I found that most of the time I was
getting everything besides text attached as application/octect-stream if
it wasn't a text or multipart.

> The current handling based on partial mime doesn't semm optimal - while
> the internal conversion can deal with text/plain, the results you get
> for text/html parts are certainly not useful :-)
> 
> I think that all parts of a message  (text/plain, text/html,
> attachments) should be handled equaly; I'm not 100% sure how to best
> deal with the headers/metainformation.
> 
> A possible scenario could look like this:
> 
> * create a postscript file using the internal converter containing only
> meta-information from the email (headers, sender/recipient information,
> whatever); submit as postscript file
> 
> * treat all parts of a multipart/mime message, like attachments, i.e try
> converting them based on typerules file and submit them as separate
> documents.
> 
> * I would love to have the added flexibility of the mimeconverters back:
> for each part of the multipart message, first check if there's a
> converter for the specified mime type. Use if it exists and try
> converting via typerules if there's no converter.

OK, so how about this:

1) Use internal formatter for "message/rfc822" (the main message starts
   this way) which prints headers, and the "body" if it's not a mime body,
   all as text (subject to the FormatEnvHeaders).  Keep this as 1 document
   to submit to HylaFAX, with a option to suppress this document.

2) For every mime part, check for a mimeconverter program.  The *output*
   of the mimeconverter program (if there is one) is submitted in place
   of the original mime part as a document to HylaFAX in the job through
   the normal machinery.  Note that this means the output doesn't have
   to be Postscript/pdf/etc.  It just needs to be something that the
   regular typerules based submission can convert to PS/PDF/TIFF if it
   isn't that directly.  Having the mimeconverter program output be
   "empty" would mean that that mime part is not submitted as a
   document.

3) If no "mimeconverter" is found, handle the part directly.
   - multipart are recursively handled, as now
   - message/rfc are handle internally, as now
   - all others are submitted as separate documents, as now

Would this framework be flexible enough for you?  It fixes the main
problems of faxmail (the squish everything into a single postscript
document, and handling application/octet-stream), and gives back the
flexibility of handling individual parts with special mechanisms.

a.

-- 
Aidan Van Dyk                                             aidan@xxxxxxxx
Senior Software Developer                          +1 215 825-8700 x8103
iFAX Solutions, Inc.                                http://www.ifax.com/


____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*