i am processing an email message that is saved to a text file... currently my processing only locates the content type, plain/text or multipart... if multipart, then we look for the plain/text section and the multipart boundary... all we want is the plain/text...

i've been doing this with a TP/BP program but have recently run into a problem with line lengths longer than 255 characters... so i'm porting the tool to be a native OS/2 FPC tool... the only real change i had to make was to change "string" to "ansistring"...

now i'm wanting to clean up the rest of the processing... previously we were using the above mentioned tool to extract and save the plain text content... in some cases, this is peppered with things like "=20" for spaces, "=99" for "(tm)" and such... and yes, in some cases lines are broken at a set length with "=" at their end... i want to clean all of this up in the above tool so that i can get rid of the external sed processing...

the sed processing works and works well but now i'm (back) to having clean lines longer than 255 characters... another tool takes this output file and posts it to various message bases but the other tool cannot be so easily ported to handle line lengths longer than 255 characters... so one of the things the initial conversion tool also needs to do, after everything else, is to word-wrap at column 70 or the first previous space if column 70's character is not a space...

what would you recommend for handling this process so that the tool i'm converting outputs a clean plain ascii text file with no lines longer than 70 characters? is there a mime(?) conversion library available in FPC to handle that part so i don't have to code specific replacements as i do with the sed process now? is there a line length routine that will break long lines into individual lines of X length?

in my BP/TP world, i had things like word-wrap taken care of with other libraries but i cannot port them to FPC (yet)... my main goal is to get this one tool working first and then move on to other tasks...

thanks!

Op 2011-02-10 22:24, waldo kitty het geskryf:

the tool to be a native OS/2 FPC tool... the only real change i had to make was to change "string" to "ansistring"...

Glad to see somebody still uses OS/2. I still have my original disks and packaging of OS/2 2.1, 3.0, 3.0 Warp Connect and Warp 4.0. :-) It was an awesome OS in it's day. I still think the WPS beats anything currently out there... Anyway, now I'm get a bit off-topic.

than 70 characters? is there a mime(?) conversion library available in FPC to handle that part so i don't have to code specific replacements as

Yesterday, while looking at LNet and Synapse I spotted the latter having a MIME processing unit. So maybe you could use that, or at least find it a somewhat useful.

i know the feeling ;)

thanks for the info! i find it very hard to locate information on some of the things i want to work with... in the past, i'd just write my own but trying to move to the newer capabilities and features while also learning the new environment AND remember what i used to know like the back of my hand is a job in itself... i will take a dig into those and see what i can see... hopefully it won't be hard to drag the routine(s) out and get them to work for my needs...

i'm contemplating reading the original file into a stream and then processing it from there before writing the final output files... i've only worked with streams a few times... this should be interesting... maybe i can get all the processing done at once with a few passes thru the stream and then spit out the final files at the end... it would be better than now where the finals are spit out as we go and then get more processing externally :)