Previously HTML pasting will fallback to plain text pasting if it contained complex tables. Now all other elements inside those tables will be converted to Markdown. And table columns will be replaced with spaces and rows are separated by new lines.
@tobiaseigen can you please test this with the email newsletters you mentioned. It should work now by skipping the table structure.
lookin’ good! 
nice job, vinoth, and many thanks. you have revolutionized how our community can create formatted topics wioh this feature.
An email that looked like this:
copy/pasted into discourse now looks like this:
Please note that TrustAfrica offices will be closed from Friday, the 22nd of December to Monday, the 8th of January 2018.
it’s like magic! 
Works great and has saved me a lot of time. Thank you!
Would it be possible to actually import the images from the paste? I noticed the images are still referencing the site from which it was taken. In our case, it’s not copyrighted material, just copying and pasting from Apple’s now-defunct Wiki/Blog system.
That’s a good question - does it copy attachments to local as usual based on the admin setting? I have not checked this myself.
In the posting, it looks like it’s still referring to the original source.
Sure. If you enabled download remote images to local site setting then the pasted external images will be downloaded locally.
@Ryan_Nix It will take some time (by default 5 mins as per editing grace period site setting) before it downloaded to local.
Terrific. That option was already checked. So perhaps the images are already there, then? I suppose I should have browsed the storage system to check first before commenting. 
MS Word ul tag support (with nested) is now available. It is tested on Word 2007. I look forward to receive the reviews for other versions of Word.
Next I will try to improve the ol tag support for Word. Currently it is treated same like ul tags.
Copying markdown from discourse’s /raw routes results in some weird behaviour.
For example, copying the content from here gives me this:
This is chrome stable on macOS.
Second-level numbered points in Word are moved into first level. For example,
Word:
1. blah blah blah
1. blah blah blah
2. blah blah blah
Markdown:
1. blah blah blah
2. blah blah blah
3. blah blah blah
Works fine for multi-level bullet points.
How many weird edge cases are we getting into here @vinothkannans? I would hate to have every client in the world download a thousand lines of JavaScript that do nothing but deal with MS Word oddities in pasting. Can this be server side only, so the cost is only paid when we encounter MS Word docs? I don’t want client code size to bloat too much based on dozens of bizarre edge cases.
@schungx as I mentioned ol tag support for Word is limited. In your case it is the output of plain text pasting (fallback) only. Not html pasting.
@codinghorror the weird edge cases from MS Word are ul and ol tags only. To fix ul tag issues it took 26~ extra lines. Yes both ol tag support for MS Word and style attributes support for Google docs will cost more lines. But accessing server side for this may cost similar lines. If possible then I will try to load those lines only if html pasting enabled.
@david thank you. I will check it 
Works for me, as long as we’re not bloating code for a condition 1% of people will ever hit.
Whatever happened to this:
AFAICT, lists pasted from Google Docs are still spaced out. Is this intentional?
While copying from other webpages it is already using tightened list as default. But I am able to reproduce this issue in Google docs and LibreOffice Writer. Thanks for the report. I will fix it.
It’s fixed. You can check it now.
Yes, it works great now, thank you! 