search

Dijji / XstReader

Xst Reader is an open source viewer for Microsoft Outlook’s .ost and .pst files, written entirely in C#. To download an executable of the current version, go to the releases tab.
Microsoft Public License
479 stars 70 forks source link

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

Open flywire opened 5 years ago

flywire commented 5 years ago

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

Dijji commented 5 years ago

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 commented 4 years ago

This has been addressed in the release for Version 1.6

flywire commented 4 years ago

I think this was closed too early:

Dijji commented 4 years ago

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:

Dijji

flywire commented 4 years ago

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 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 commented 4 years ago

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

Which of these features are must haves for you?

Dijji

flywire commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

I understood from https://github.com/Dijji/XstReader/issues/14#issuecomment-559427999 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 commented 4 years ago

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 commented 4 years ago

Yes

flywire commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

There is alternative way to print a message.

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 commented 4 years ago

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 commented 4 years ago

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

flywire commented 4 years ago

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.

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

Tested with Win10

flywire commented 4 years ago

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:

Dijji commented 4 years ago

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:

Thanks again

Dijji

flywire commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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.