(Archived) Doublespace bug revisited

[Schooner 26]

Folks, I fear you're underestimating the doublespace bug. Can I persuade you to take another look?

I post here because it is NOT a EN4Win issue per se, though it is naturally encountered by Win users. It is a more generalized Microsoft/Evernote incompatability, with exceptions.

The problem, as perceived by Win users (and Mac users encountering incoming emails from Win users):

Clipping, pasting or emailing from certain Windows apps (notably MSWord, MSOutlook) on windows platforms introduces a doublespace artifact (irrespective of the EN viewer - Mac, WinEN31, WinENBeta or Web - observing the impact).

The practical effect is to render EN.Win unusable for "professional" purposes, except for direct entry via keyboard.

A further practical impact is to undermine the otherwise-miraculous cross-platform utility of EN.

Diagnostic examples for clarity:

1. Screen clip, or paste, from MSWord4Win generates a doublespace for each hard return (^p) but not for the workaround soft-return (^l).

2. Emailing HTML formatted message from MSOutlook (Windows) does likewise.

3. Emailing RTF-formatted message from MSOutlook (Windows) does likewise.

4. Emailing plain-text-formatted message from MSOutlook (Windows) displays correctly.

5. While cut/paste from MSWord (Windows) into EN-WIN(s) inflicts the artifact, the identical actions in MSWord4Mac into EN-MAC display correctly - though the identical word document is used, and each paragraph contains a single hard-return on both platforms, confirmed by searching for ^p vs. ^l.

6. Cut/paste entry from MSWord (Windows) into EN-Web interface initially looks good - but once saved, the artifact is inflicted. Again ^l displays correctly, ^p incurs doublespace.

7. Webclip (Firefox/Windows, MSIEx/Windows, Safari/Windows, GChrome/Windows) displays correctly (where html list lines are terminated with , e.g. Wikipedia "List of Canadians")

8. Clipping from Win apps which EN cannot render to simple text (MSExcel) displays "correctly".

9. 3rd party Windows apps: Notescribe, e.g. clips to EN without doublespace artifact despite RTF environment (EN clip reduces RTF to text); Skype conversations clip to EN without artifact; searchable Adobe .pdf likewise.

10 Emailing via MSOutlook to/from EN repetitively generates but one doublespace per line incurred upon initial email-in, each cycle preserving it but not introducing another.

11 Competing note-ware (e.g. Notescribe 4 Win) suffers no such artifact: copy hard-returned lines from MSWord4Win, displays correctly without doublespacing.

12 OpenOffice Writer clips/pastes behave identically to MSWord - doublespace artifact generated by hard return on Windows platform.

What we need:

WYSIWIG paste/clip/email entry. The acid test would be: EN data can be pasted/emailed back to the spawning app unmolested.

Failing that: reduction to simple text.

I can't believe the challenge is beyond the insights of the EN team, or that we'll have to wait for Microsoft to change their HTML implementation.