Display Message From To Date Subject Cc (Bcc) in Content for pdf Output

[flywire]

Outlook displays message from to date subject cc (bcc) in content. These vital parts of the message should be supported, especially when outputted.

[Dijji]

I agree with you on this one. Information equivalent to that shown by Outlook should be displayed. I will add it to the development list.

Dijji

[Dijji]

This has been addressed in the release for Version 1.6

[flywire]

I think this was closed too early:

• Fairly sure it default outlook header has a line under it (?)
• Does not have a left margin like rest of email
• Wonder if default header font is available
• Not included in print/print preview

[Dijji]

It is rather flattering that you are setting such a high bar for my efforts. My original goal was just to put a front-end on my C# code for reading Office mail files - I seem to have built something that at least some people find quite usable. But having said that, I'm never going to compete with something like Outlook, which has had hundreds of man years spent creating it. But if the cost is reasonable and the cause is good, I will continue to make improvements.

To get to your specific points:

• In Outlook 365 for PC, at least, there is no line under the header material.
• The header that I have added is not in fact part of the email. But I could easily indent it to line it up with the email text. I will look at this.
• The header is in a font that I choose arbitrarily, unrelated to anything in the message body. I think this is also the case with Outlook.
• The header does not appear in print preview because it is not part of the message body, and there is no cheap means of making it so across the range of message body formats that I am supporting (HTML, RTF, plain text).

Dijji

[flywire]

Thoroughly agree with putting effort into time-effective enhancements. Let me give my needs some context. I used Outlook for many years but I'm a keen open-source user so now I have the data without access to the application. I tried a few alternatives and I really like your interface.

Essentially I have two issues:

• I can't get a pdf of an old email with the header
• attachments are too difficult to view when browsing emails (hence Explorer Context Menu Support in Message File List #13)

I suppose user could set the header font if the required font was known.

btw - I can't write the code but happy to contribute researching, testing etc at your direction.

[Dijji]

I can see how to deliver on some of what you want.

• I can open an attachment using the associated default application, but I cannot see how to allow you to do the equivalent of Open With…

• The biggest problem with exporting to PDF is dealing with the three message body formats (RTF, HTML and plain text). There are open source libraries around for plain text and HTML, but not as far as I can tell for RTF. The easiest approach would be to convert RTF using the Office API, but I really do not want to do that, I want to stay away from Office dependencies.

Which of these features are must haves for you?

Dijji

[flywire]

Just to be clear, print preview->print to pdf is my must have. I like the right click on message to preview before printing [to pdf].

Sucks there are three formats but iirc RTF is the most common. In terms of solutions, I use LibreOffice Writer and it does a good job with all formats. Only real issue I have had previously is line spacing issue switching between LOW and MS Word but I think that was resolved.

[flywire]

Header should look like: https://support.content.office.net/en-us/media/9e228f43-7b04-4711-b133-d262cfcc954c.png or https://excelesquire.files.wordpress.com/2016/05/header-no.png?w=420&h=253

There should be another line for attachments with filenames: http://www.outlookprinter.com/images/usual_printout.png

... I'm never going to compete with something like Outlook, which has had hundreds of man years spent creating it.

lol - you're too modest, it already competes 😀

[Dijji]

The more I look at saving to PDF, the less I like it.

One approach is to use document conversion libraries. However, I'm looking at having to use more than one library to get the needed functionality, where each is probably larger than XstReader itself. The most technically viable candidates are typically free versions of commercial products with quite severe restrictions (5 pages in one case, 20 paragraphs in another), and don't ship source. The addition of the required multiple files to the release package would probably also necessitate writing an installer. I don't think I would be comfortable shipping such a heavy appendage in my standard release.

Another approach would be to use Microsoft Office or, say, LibreOffice. I do not want to go the Microsoft route for obvious reasons - it was the very dependency I started out trying to break. I also took a look at LibreOffice. There is an API that would do this, I think, albeit rather old and clunky. However, I would have to embed six or seven LibreOffice files in XstReader, and these would have to match the version of LibreOffice I was talking to (32 or 64 bit, and roughly matching versions). So again

What if I gave you formats that you can feed into LibreOffice, or other commercially available tools? I could certainly export HTML emails as HTML files, RTF emails as RTF files, and plain text as text. Injecting the header information would be tricky, but I could write it to a companion text or csv file for you to do what you want with e.g. format it into the Office style memo print format that you reference. It would certainly be possible to take this output and consume it manually, using LibreOffice, and it is probably feasible to write some sort of was make the process. Might this variation work for you?

Dijji

[flywire]

I looked around a lot before I ended up here. I agree this functionality isn't freely available and expect if you crack it it will be well used.

Another approach would be to use Microsoft Office

lol

Hmm, injecting header info was my thought too.

Focus firstly on functionality then on usability. I see this as print preview functionality and the user can close or do what they like. Agree you don't want to turn it into a cut-down LibreOffice Writer but integration through a temporary file sounds interesting, perhaps a plugin. Maybe user could click a button and it opens up in LOW print preview or save pdf as then disappears.

Feel free to email me a hack.

[Dijji]

I'm sorry, no matter how I turn this problem around, I can't see any generic way forward. What you want is entirely doable with available open software, but it would be more like a solution in which XstReader provided one of the pieces, and one of the smaller ones at that, rather than anything that XstReader might set out to be.

For an example of the sort of thing that does make sense for XstReader, take attachment opening, which was just a question of figuring out how to plug into standard Windows facilities, and is the sort of thing that any user of XstReader might find useful.

So I think I'm going to have to draw a line under the question of whether to add export to PDF, and say no. I remain open to exporting mail bodies to some intermediate format for consumption by other software - I would have done that already if there were some plausible, generally well supported email file format to export to.

Dijji

[flywire]

I don't see a problem with that approach, as I said I see the pdf as something the user does with the container. How about we work on a mock-up?

[Dijji]

I've taken another look at the reduced goal of just injecting the header into print preview and print, of the grounds that if you can get that far, you can always print to PDF. However, it just doesn't look very tractable. Print preview and print are provided by the controls that display RTF and HTML, and don't give me a way to get involved to inject the header. But nor do I want the header always present in the displayed email, as even if it were technically much less tricky than it is, it is a print header rather than a display header.

So for now, I won't be taking this further.

Dijji

[flywire]

I understood from #14 (comment) that you would look at "exporting mail bodies to some intermediate format for consumption by other software" which I agreed would be a useful approach. Will you still do this? It would give users many options besides allowing them to format emails for pdf output.

Your investigation about injecting the header into print preview is really nice despite not resulted in a solution. Documenting your work would be really valuable for anyone considering this in the future. Specifically: useful resources, summary findings and any sample code (even if it only injected a single character).

[Dijji]

I was actually writing a response to explain why your reminder did not lead to a cost-effective possibility when I realised that I might be wrong.

What if I export emails in their native format (HTML, RTF or plain text), injecting some sort of header into them as I go? Then I do not get print headers taking up too much space my main view of the body of an email, and possibly being poor aesthetically to boot. Nor do I have issues with deciding when to inject headers, as I do with the native HTML browser print and print preview. Nor do I have to provide print and print preview where they don't exist (RTF and plain text).

The whole thing hinges on whether I can make injection work. The goal is to follow RFC 822 for plain text files and something like the Outlook print header for HTML and RTF (as you suggested). The good news is that the bar is fairly low. Without injection, email properties have to go into a separate file (such as the csv file that I already export), and this sucks when it comes to onward consumption of the email contents. So I will be prepared to tolerate imperfections for the sake of having the crucial properties included in the file.

Some initial experimentation indicates that I'll be able to get at least something injected using only built-in platform capabilities and without too much code. So this approach fits my criteria of adding considerable value a reasonable cost. Does it work for you?

Dijji

[flywire]

Yes

[flywire]

Users might want to tweak header detail so it would be good if a configuration file was accessible. Manual text editing would be fine.

[flywire]

What if I export emails in their native format (HTML, RTF or plain text), injecting some sort of header into them as I go?

Three possible formats. I still think they could export to a temporary file and open up in users application, say LibreOffice Writer (as user configured), maybe in print preview or write directly to pdf and close (?) - Reference. That would fully meet the original request using external user application for processing depending on file type.

[Dijji]

You may not know it, but you are actually asking me to attack two well-known general problems for which there are already many (free) solutions.

First, the header. This problem is one of populating a document template, merging in the header data, and concatenating the mail body document to it. The generality emerges as a problem quite quickly: I really cannot know what header a given user might find satisfactory, so the header template editor has to be a fairly complete document creation tool.

Secondly, the action to take with the exported email. This problem is one of scripting. The first action would be to open a program to handle the exported email, but again generality issues emerge as soon as one considers passing instructions to the opened program, e.g. to print a PDF. Another issue is one of scale. Suppose you export 1000 messages from a folder: you do not want this to open 1000 copies of Libre Office.

The correct problem decomposition, I think, will be for me to stop at what only I can do, i.e. exporting the email in an accessible form, and leave the rest to existing technologies.

Libre Office, for instance, has a perfectly good scripting language which would allow you to open 1 or 1000 exported emails and save them as PDFs. There is a good chance that it could also read the properties CSV that I export and construct the header of your choice, as well.

Dijji

[halueda]

There is alternative way to print a message.

• Export messages into CSV format file with message body, in which a message header/body is in a CSV line,
• Convert CSV file to .eml files, for which you need to run something, e.g., python program.
• Open each .eml message file with outlook or other mailer to print out.

You can use python program and an extension to export CSV with body in my branch of XstReader.
See detail in a issue: CSV export with Message Body #10

[Dijji]

Support for exporting emails is now available in the pre-release of version 1.7. If you are interested, check it out and let me know what you think.

[Dijji]

Halueda, I have responded to you on the original issue (#10)

[flywire]

Very nice - XstReader UAT 191204.csv (looks better if you bold any line with contents only in first column). Seems fully functional - a couple of tweaks would improve and a few others are on the dreaming list.

• Export email - Seems to generate Open File Error "You can't open this location using this program. Please try a different location." Works with OK response. Might only occur if files exported to this directory previously.
• I note Export email exports attachments in zip and save saves as individual files. Maybe add save as zip archive too.
• Consider starting with last file/document open (like outlook (?) )
• Outlook seems to recognise embedded images and not add as attachments

btw My system has font issues with the apostrophe and one of the hyphens and ignore keyboard shortcuts comment.

Tested with Win10

[flywire]

Print / Preview / pdf seems hopeless in LibreOffice Writer but very good in Chrome. (I'm actually looking at dumping Chrome due to tracking concerns.) Regardless, I'm still interested in exploring the possibility of exporting to a temp directory, convert to pdf then deleting file originally exported.

Something like this (which works): "C:\Program Files (x86)\Google\Chrome\Application\chrome" --headless --disable-gpu --print-to-pdf=C:\Users\User\Documents\XstReader\DemoEmail.pdf --no-margins "C:\Users\User\Documents\XstReader\Demo Email.html"

(rtf format likely to be a challenge but there are extensions eg: RTF Viewer)

---

I'd still like a hook in XstReader to launch the pdf writer (or whatever) as described above. As I see it there are two ways:

• proper addon menu item - I've seen user c# code injected into an application but I don't know how it's done
• call user-configurable batch file with a filename as a parameter (quick, dirty and functional) - menu item would appear if batch file present

[Dijji]

Thank you very much for your excellent testing and feedback.

I have updated the 1.7 release with a new version that I believe addresses most of the problems that you have found. Specifically:

• Export and save now always default to My Documents.
• Small margins added in strategic places around preview
• Colons now immediately follow field names in text mail headers.
• Exported attachments now have the creation date set to the date of the email, which is what Outlook does.
• Word wrap and vertical scrolling added to text mail preview
• I hope to have addressed the export email error. It was remembering the last folder used incorrectly.
• Export email never zips attachments. Did you happen to save an attachment that was a zip file?
• I'm not sure I like starting with the last file. Outlook starts with the last mailbox, which makes more sense. I am in a position an analogous to Word or Excel, which do not automatically open the last document. If I did do anything, it would be to offer a list of recently opened files to choose from.
• I also recognise embedded images and show them in a different coloured font in the in the attachments list. You will notice that I also do not export them, instead I export HTML with them embedded.

Thanks again

Dijji

[flywire]

I've enjoyed collaborating on this project. You've considered the issue in my comments, thought about the best way to address them and implemented things in a very technically competent way.

you are setting such a high bar for my efforts.

... and you put a tight cost-benefit constraint on the project. Only you can know if the time-personal satisfaction return was enough. I'm very happy with what you have delivered to the community. It has a nice clean interface that functions as it should in the windows environment. Well done and thank you.

I notice there are a lot of watch/star/forks on this repository. Please consider circulating a brief summary to a few reviewers. eg: Free Outlook Viewers

[flywire]

v1.7 released on Win10

• Export and save now always default to My Documents.

omg no (quickly becomes cluttered), and you have to change folder for Export and Save separately, suggest XstReader or eMail as initial default subdirectory. Fortunately seems to remember directory after using once. Hmm, settings file in C:\Users\User\AppData\Local\XstReader tree.

• Exported attachments now have the creation date set to the date of the email, which is what Outlook does.

Nice. Can you do the same for create date of exported email and attachment directory to allow sorting by create date?

• Export email never zips attachments. Did you happen to save an attachment that was a zip file?

My mistake, it is a folder not a zip file. Regardless, it's inconsistent since Export Email exports a folder with attachments in them and Save * doesn't.

• I also recognise embedded images and show them in a different coloured font in the in the attachments list. You will notice that I also do not export them, instead I export HTML with them embedded.

No, dimmed embedded image file saved with both Export Email and Save All Attachments. Prefer Outlook which doesn't even show embedded image files.

Suspect issues with rtf Export email, including no blank line after header before message

btw - On Export Email with multiple emails selected it only exports first email.

[Dijji]

It has been fun. You've driven some good functionality into the program which would not have appeared without you. A constructive, robust argument is often the best way to get a good outcome. And if other people get value from the changes, all the better!

I'll come back to your outstanding requirements below. First, on your latest points, and changes in the updated 1.7 release:

• My Documents remains the default target. I like to use the built-in Windows defined folders, and the only other reasonable candidate is My Computer, which is worse. I definitely do not want to go to the XstReader program directory, as many people will put it in Program Files.
• Creation date now set on emails and attachment folders.
• Export and Save * remain different. I prioritise consistency between Save and Save *. Behaviour grouping follows the command name grouping.
• Exporting embedded attachments was a bug. Now fixed.
• RTF emails actually look okay. They are saved by automatic padding around the header table.
• I had forgotten you could select multiple emails! Now fixed.

Back to your broader requirement. I still don't want to add any hooks or user-defined commands to the program. I stick with the UNIX principle of separation of concerns: make each program as good at what it does as possible, and compose multiple programs using an external composition tool and the file system. For UNIX, the composition tool was the shell, but these days, there are many alternatives. Two are built into Windows: the command line and PowerShell.

Suppose we want to export a whole bunch of emails and convert them to PDFs using the command you gave for Chrome, or similar for another tool. Then we can iterate over all the files in an export directory as follows.

For a command line batch file:

for %%i in (d:\exports\*.*) do (yourCommand %%i)

For PowerShell:

foreach ($f in Get-ChildItem "d:\exports"){
	yourCommand $f
}

And if you want to delete the emails automatically afterwards, you can do that too. It is just such a more powerful approach than any single hook could ever be, and the concomitant learning curve is really not too bad.

I notice that you don't have any RTF files to hand: they are becoming much scarcer these days. I think it is because sometime in the last few years Office made the subtle change that whenever an RTF email is sent to an Internet email address it is converted to HTML. That way, they maintain enterprise backward compatibility at the same time as playing better with the rest of the world. So you can only really find RTF these days in emails sent within an enterprise.

Finally, I do sometimes wonder if I have spawned a mini industry. I do know for sure, however, that none of them are paying me!

Dijji

[flywire]

Much nicer - I grabbed your commit and tested things (except rtf) as you were commenting above. Everything tests OK.

I agree with your reasoning and you have build in a fair bit of flexibility anyway. If I had grounds to argue you know I would. ;) Anyway, if I really want a hook it is a nice project to help me learn c# and put it there myself. btw I've found the forms.

I do know for sure, however, that none of them are paying me!

lol - your currency is personal satisfaction so you have to pay yourself which I can see you've done.