RichEdit versions
Recurring questions are what RichEdit's are available, where they are installed and what features they have. A relatively new question is which RichEdit's support the new Office math editing and display. So this post attempts to answer these questions. To answer the last question first, only RichEdit 6.0 has the Office math facility, although RichEdit 5.0 has a preliminary math capability that was good enough to get people intrigued with doing something well.
Before answering the other question, here's a quick summary of what RichEdit is in case you haven't heard of it: RichEdit 6.0 is a facility for getting plain/rich-text, single/multiline Unicode/ANSI edit controls and combo/list boxes in single world-wide binary that runs on all Windows operating systems. It has multilevel undo, message & com interfaces, considerable Word compatibility, richly formatted text, outline view, zoom, support for the latest IMEs, speech and handwriting input, rich complex script support (e.g., BiDi, Indic, and Thai), pagination, multilevel tables, autocorrect, hyphenation, kerning, ClearType support, autoURL detection, East Asian features such as vertical text, text wrap around embedded objects, font binding, and support for Unicode surrogate pairs and most Unicode 4.0 scripts. To some degree all RichEdit versions since 3.0 have had these features; although the support for them has improved greatly from version to version (Indic support was first available in 4.0). The rich-ink support was added in 5.0 (4.1 is used in the Ink Edit control that ships with the Tablet PC).
This post continues with a summary table, followed by a list of new features for each version. For the most part, each version has all the features of versions with lower version numbers. One exception is that the Japanese version of RichEdit 1.0 had vertical text display, which wasn't supported by later versions until RichEdit 4.0. Another is that RichEdit 1.0 was also pen-enabled and understood gestures for use with Pen Windows, while only the RichEdit 4.1 ink control and later versions have rich ink support.
Version | Ships ('ed) with | dll name |
1.0 | Windows 95/98/ME/NT | riched32.dll |
1.0 | Exchange 4.0 for Windows 3.1/WFW | richedit.dll |
2.0 | Office 97, Windows NT/98 | riched20.dll |
2.1 | BiDi Office 97 | riched20.dll |
2.5 | Windows CE, Pocket Word | riched20.dll |
3.0 | Office 2000, Windows ME/2000/XP | riched20.dll |
1.0 emulator | Office 2000, Windows 2000/XP/Vista | riched32.dll |
3.1 | Windows Server 2003, Vista | riched20.dll |
3.5 | Windows CE, eBooks | ebriched.dll |
4.0 | Office XP | riched20.dll |
4.1 | Windows XP SP1, Tablet, Vista | msftedit.dll |
5.0 | Office 2003 | riched20.dll |
5.1 | Windows CE, Pocket Word | riched20.dll |
6.0 | Office 2007, Encarta Math Calculator | riched20.dll |
If you want to use the Office 2007 RichEdit 6.0, you'll find it in the private subdirectory \Program Files\Common Files\Microsoft Shared\OFFICE12. Similarly the Encarta Math Calculator is stored in a private Encarta subdirectory. The OS versions are located in \Windows\system32. Maybe someday Windows will have the good fortune to have a more recent RichEdit than 4.1J But then we'd have to document all the new features L (Wouldn't be that hard…)
RichEdit 1.0 Features
- Basic nonUnicode editing, cut/copy/paste, file streaming
- Basic set of character/paragraph formatting properties
- Message-based interface plus OLE interfaces: IRichEditOle and IRichEditOleCallback
- Vertical text and IME support (FE builds only).
- WYSIWYG editing using printer metrics
- Different builds for different scripts
- Common-control notifications plus some new ones
- Plain text and RTF files
- Pen-enabled and understood gestures for use with Pen Windows
RichEdit 2.0 Additions
- Unicode internally + able to read/write using codepages
- International line breaking algorithm
- Find Up/Down. Magellan mouse support.
- Multilevel undo
- BiDi (RE 2.1) and FE support including level 2/3 IME, dual font, keyboard linking, smart font apply
- AutoURL recognition. Word UI
- Plain/rich, single-line/multiline, scalable architecture
- Password and accelerator control options
- Windowless interfaces (ITextHost/ITextServices)
- Better display (mixed fonts use off-screen bitmap), system selection colors, transparency support
- TOM (Text Object Model) dual interfaces
- Character formatting additions include background color, locale ID, underline type, superscript/subscript.
- Paragraph formatting additions include space before/after, line spacing.
- Roundtrip all Word Format Font/Para dialog properties
- Extensive code stabilization, testing, performance increase
RichEdit 2.5 Additions
- First Windows CE version. Used by Pocket Word
- Outline view, normal and heading styles
- RTF additions
- Minor UI improvements
- Western languages only
RichEdit 3.0 Additions
- Used for emulating RichEdit 1.0's
- Zoom
- Italics caret/cursor. URL hand cursor
- Paragraph numbering (alpha, numeric, Roman)
- Simple tables (no wrap in cells)
- More underline types, underline coloring, hidden text
- More of Word's default hot keys, e.g., accent dead keys, outline view, numbering
- Smart quotes (English only), soft hyphens
- Use Office's LineServices component to break/display lines. Used for complex scripts and options like center, right, decimal tabs, fully justified text
- Complex script support for BiDi, Indic, and Thai with help from LineServices and Uniscribe components
- Font Binding based on charset, which acts as writing system ID
- Codepage-specific stream in/out
- UTF-8 RTF. Used preferentially for cut/copy/paste. Can be streamed in/out.
- Office 9 IME support (MSIME98) including Reconversion, Document feed, Mouse Operation, and Caret position features
- AIMM component IME support for nonFE systems.
- Increased freeze and undo/redo control
- Font increment/decrement function
- System edit control, list box, and combo box controls
- Alt+x input method
- Used to emulate RichEdit 1.0's
RichEdit 3.5 Additions
- Second Windows CE release. Used by eBooks
- Screen-size pagination
- Text wrap around objects flushed left/right
- Custom ClearType support
- Enhanced East Asian typography
RichEdit 4.0 Additions
- Multilevel tables
- Autocorrect
- Improved autoURL detection
- Friendly name hyperlinks
- Font binding according to writing system (generalization of charset)
- Indic support
- Vertical text
- Support for the latest IMEs
- Speech and handwriting input (Windows Text Services Framework)
- More standard hot keys
- Many security fixes (3.0 has also)
RichEdit 5.0 Additions
- Multiselection, smart drag&drop
- Better nested tables, horizontally merged cells
- Better font binding/international support
- More underline styles, small cap & shadow emulation
- Binary file format: "parsed XML"
- Partial XHTML reader/writer
- Subpixel ClearType support
- Better RTF handling, e.g., multilevel lists
- URL tooltips
- Many bug/minor-request fixes
- Improved ink support, especially for OneNote
- Advanced East Asian typography
- Initial PTS integration, including object tight wrap
- Infrastructure for math, ruby, warichu, tatenakayoko
- Text trackers and blobs
RichEdit 5.1
- Third Windows CE release. Used by Pocket Word
- Various UI and RTF enhancements
RichEdit 6.0 Additions
- High-quality editing & display of math
- Formula autobuildup
- Create and support math linear format
- More list numbering options
- Simple "visi" mode
- URL improvements
- Multistory: high-perf cut/copy/paste, rich scratchpads, WP infrastructure
- Text Object Model 2
- Display enhancements, e.g., word underline, horizontal scaling
- Table UI adds, e.g., column resizing
- OfficeArt/PowerPoint enhancements
- Overlapping lines, drop caps & other ePeriodicals improvements
- Device independent layout
- Virtualized OS: "hDC" is totally opaque
- Multiple columns
- Myriad security fixes
Comments
Anonymous
October 15, 2006
Just to be sure. Can I redistribute RichEdit 6.0 with my application?Anonymous
October 16, 2006
So what's the point of listing these features without documenting how to use them? Just to make everyone outside of MS envious? Also, you mentioned the rich edit Ink control. Do you mean InkEd.dll? What is the trick to use that within an MFC application? I can force CRichEditView to use InkEd.dll / INKEDIT_CLASS, but this results in an "0xC000001D: Illegal Instruction" on app shutdown in the main frame's DestroyWindow().Anonymous
October 20, 2006
I just had a couple random things to mention this afternoon: ARCast – Office 2007 Open XML Format (PartAnonymous
October 21, 2006
Thanks for writing about RichEdit! I've been working extensively with the control for a number of years and I find it very interesting to read an insider's view of the control's history. I found the features list in your previous post to be interesting as well since not all of the features you mentioned are documented. And the feature list of RichEdit versions 5.0 and 6.0 give me an idea as to what features may eventually become available in the Windows RichEdit. Although I would love to ask you dozens of questions about RichEdit I will limit myself to just one which I hope you will be kind enough to answer: Your previous post mentioned RichEdit has the capability to flow text around an embedded object starting in version 3.5 (and presumably carried into version 4.1?). I had no idea that was possible. Could you provide the message and parameter values needed for that feature? Thank you!Anonymous
October 23, 2006
Bob F asked how to wrap text around objects. In RichEdit 4.1's richole.h, there are definitions for REO_WRAPTEXTAROUND and REO_ALIGNTORIGHT, which are flags for REOBJECT::dwFlags. If you set REO_WRAPTEXTAROUND when inserting the object, the text should wrap around the object, which will be left justified. If you set both REO_WRAPTEXTAROUND and REO_ALIGNTORIGHT, the text should wrap around a right-justified object.Anonymous
October 25, 2006
Is there any RichTextBox control available which is compatible with RichEdit 3.0 or later ver. ? How can I download it?Anonymous
October 26, 2006
Thanks Murray. REO_WRAPTEXTAROUND seems to work but it appears to have some rather severe painting issues. And, RichEdit does not save the effect when its content is saved to a file. That may explain why REO_WRAPTEXTAROUND doesn't seem to be documented anywhere. I also noticed the effect appears to have been dropped altogether from RichEdit 6.0. Perhaps the feature will be more fully supported in a later version of the Windows RichEdit. At any rate, it's nice to know you guys have been working on it.Anonymous
February 12, 2007
The comment has been removedAnonymous
March 14, 2007
Du musst ein Fachmann sein - wirklich guter Aufstellungsort, den du hast!Anonymous
March 16, 2007
pagine piuttosto informative, piacevoli =)Anonymous
March 17, 2007
luogo grande:) nessun osservazioni!Anonymous
March 19, 2007
Great site! Good luck to it's owner!Anonymous
March 22, 2007
On personal opinion, I find this very helpful. Guys, I have also posted some more relevant info further on this, not sure if you find it useful: http://www.bidmaxhost.com/forum/Anonymous
April 10, 2007
Luogo molto buon:) Buona fortuna!Anonymous
April 10, 2007
pagine piuttosto informative, piacevoli =)Anonymous
April 11, 2007
Ich erklare meinen Freunden uber diese Seite. Interessieren!Anonymous
April 13, 2007
9 su 10! Ottenerlo! Siete buoni!Anonymous
April 13, 2007
Stupore! Amo questo luogo!:)))))))Anonymous
April 14, 2007
Stupore! ho una sensibilit molto buona circa il vostro luogo!!!!Anonymous
April 15, 2007
E grande io ha trovato il vostro luogo! Le info importanti ottenute! ))Anonymous
May 27, 2007
Hi, Murray. Very nice blog you got here! Those early days posts are also quite cool. About the Rich Edit controls, I have a doubt: you said that version 3.5 introduced support for text wrapping around objects, and also how to achieve this (so v4.1 can do it). But I can't find the definition of the constants REO_WRAPTEXTAROUND and REO_ALIGNTORIGHT anywhere, and as I'm using Delphi, I don't have RichOle.h, and couldn't find the right file for v4.1 on the net. Can you post the values for these constants? Also, how well does the control handles Tables? It seems there are no messages for table handling, but the control can draw the tables if I insert the RTF code. What is the best way to use tables? Thanks, and keep up the good work!Anonymous
June 21, 2007
I am using a RichEdit allow reading/editing of files in a piece of software I'm writing. Only problem is, for larger files I am getting an out-of-memory error because the RichEdit loads "all" of the data into memory when I use the EM_STREAMIN message. Is there a common method used to work around this?Anonymous
September 09, 2007
The comment has been removedAnonymous
January 15, 2008
Since installing office 2007, an app using a rich edit suddenly crashes on exit. It is not an MFC app, it uses an RC file and CreateDialog(). In the RC file the richedit is labeled as "Richedit20A", and prior to loading the dialog I am doing a LoadLibrary(RICHED20.DLL"). This has been very stable for a number of years. After loading Office2007, in the exit there is a repeated crash, stack window shows riched20.dll!74e50625() riched20.dll!74e50e2d() Anyone having information, Id appreciate it - wjmsdn@msn.comAnonymous
February 08, 2008
Steve, v5.0 = RichEdit50W v6.0 = RichEdit60W My company uses this in our own app, so I know it works. Be aware that v6.0 has a timer that fires twice after you show it. This timer causes some WM_PAINT, WM_ERASEBKGND, and WM_NCPAINT messages to fire. This will make the window flicker a bit, and can cause other controls to show through it in certain situations if you don't handle it right. Also, the 5.0 and 6.0 versions are occasionally a source of trouble for customers with damaged installations of Office, so you want to make sure it is possible to disable them and always use 4.1. We used a registry key for this, it just provides an available workaround. Bill, The version of rich edit control installed by Office 2007 is in a dll named RICHED20.DLL, same name as the old 2.0 version. You are probably loading the wrong dll. Look at LoadLibrary for information on how the filename is resolved. It's also possible that an installer might try to register this DLL with the system, which would be a problem. If you want the old 2.0 richedit, I don't THINK you need the call to LoadLibrary. If you want to use the 4.1-6.0 versions, you should get the path where office is installed and pass the fully qualified path to LoadLibrary, then you'll need to use the correct window class.Anonymous
April 21, 2008
How to use the new features of RichEdit 6.0. Can I built a setup my application with RichEdit 6.0 without contact MS?Anonymous
March 08, 2009
Thanks John. Wow, I should have checked back sooner. I did for about 3 months, but then got sidetracked. But your info will be helpful for my next .net project. I'm sure I tried RichEdit60W for v6. Although, considering I was only guessing I probably didn't try very hard. Thanks again.Anonymous
March 26, 2009
How come Office Dev team is allowed to extend the Windows RichEdit code for use in Office applications. Does this not give MS an unfair advantage? Or can developers such as the Open Office team get access to the RichEdit source code to extend the RichEdit control for their own applications. I'm sure it this was the Browser control there would be an deluge of complants.Anonymous
March 26, 2009
The comment has been removedAnonymous
April 28, 2009
In my MFC app,I Load riched20.dll of office 2007 in CMyApp::InitInstance,and add "cs.lpszClass=L"RichEdit60W" in CMyRichEditView::PreCreateWindow. But it does not recognize the math in rtf.Anonymous
April 29, 2009
Math RTF conversion isn't enabled in the RichEdit 6.0 that ships with Office 2007.Anonymous
January 14, 2010
Loading RTF files with EM_STREAMIN message in RichEdit20A (3.0) is, for files in the megabyte range, about a factor 20 slower than doing the same with RichEdit50W (4.1). Apparently the parser has a slow innermost loop. On the other hand, RichEdit50W has an issue with EM_STREAMOUT: It occasional forgets two bytes on 2048 byte boundaries. Is there a chance to fix the inner loop of 3.0? There seems to be also an issue with PARAFORMAT2 and the PFM_BORDER values, as numerous Google hits and own attempts show. It would be really great if Microsoft could take RichEdit seriously. Formatted text is so ubiquitous (see this page...) that a dedicated control must be part of the OS, not a loosely documented part of the Office suite.Anonymous
July 19, 2010
Hi, first thanks for publishing this article. We are currently using v5 of the richedit control as we need support for small caps. This is fine as our app is a Word Addin, My question is, in Office 2010 loading v6 of the richedit library appears to also require loading a file called "msptls.dll". What is this for, and are there any other libraries which should be loaded the richedit 2010 version? Thanks NealAnonymous
July 19, 2010
Office 2010 loads RichEdit v7.0, which calls on the Page/TableServices and LineServices functionality housed in the msptls.dll (PTLS v4.0). This version of RichEdit also uses the mso.dll (if it's loaded) for some trickly font binding scenarios.Anonymous
October 03, 2010
Do you know how enable underline color in RichTextBox based on RichEdit 6.0 or 5.0? Thank for answer!Anonymous
October 16, 2010
We've been using RichEdit for several years in a Delphi environment, but we want to start sending documents by email as pdf files, and our method is to convert from the existing rtf. Rtf didn't display properly when using (a fairly old version of ) riched32.dll (subclass richedit), so we've upgraded with MSFTEDIT.DLL (subclass RICHEDIT50W) which displays fine, but when printing a hard copy for Records, it continues to print literally 1000s of pages of blank text after the correct page. Is there a solution to this anomally? ThanksAnonymous
October 19, 2010
On Windows Vista and Windows 7, RichEdit 3.1 (riched.dll) skips over single accented letters (e.g. the French word "à") when using Ctrl+LeftArrow or Ctrl+RightArrow. RichEdit 4.1 (msftedit.dll) handles this correctly, but then it does other weird things: when you're inside protected text and use Ctrl+LeftArrow or Ctrl+RightArrow, the RichEdit sends an EN_PROTECTED notification, and claims it comes from a WM_KEYDOWN message with VK_BACK as wParam!!! Of course, this completely messes things up, since the code we have for handling protected text edits thinks the user is trying to delete text, rather then moving the caret. Is Microsoft aware of these bugs? Is there anything I can do to work around them?Anonymous
March 04, 2011
Forget about the RTF control -- it has too many caveats no matter what versions you want to use -- lots of pains ahead if you really want to try. One may try txcontrol -- I used it for http://google.elookinto.com. It is not free, but it seems it is much better.Anonymous
October 16, 2011
The comment has been removedAnonymous
October 17, 2011
The comment has been removedAnonymous
April 11, 2013
Hi Murray, Would you mind providing an update of this post with the versions following Office 2007, and also 32/64 compatibility issues? thanksAnonymous
March 11, 2014
I have been trying to use the following calls that you posted, but without success ITextFont::Reset(tomApplyTmp) ITextFont::SetUnderline(Value) ITextFont::Reset(tomApplyNow) The underline itself works, but the color is always black. If I remove the Reset(tomApplyTmp) calls the color is set as expected. This is on a Windows 8 machine Thank youAnonymous
September 22, 2014
Dear Murray, I understand that in order to increment or decrement the font-size of a selection in the RichEdit control one can send the EM_SETFONTSIZE message. Unfortunately the resulting font size is then further rounded. While it is useful that the change is applied to each part of the selection individually (such as when CFM_SIZE in the dmMask variable is false), it is troublesome that the user defined increase is arbitrarily 'rounded'. The alternative method of setting yHeight for the selection through the EM_SETCHARFORMAT message is not sensitive to the given font-sizes of sub-regions within the selected text - it changes the whole selection to the absolute size specified. The simple 'Ctrl+]', 'Ctrl+[' increment decrement functionality of Microsoft Word thus seems difficult to implement in the RichEdit. Electing to return the CHARFORMAT2 of binary searched sub-selections so as to fully determine contiguous regions of identical font size (prior to setting EM_SETCHARFORMAT for such regions) is inefficient in practice (even after disconnecting the event mask and redraw). Is there some way to increment the font-size of a non-homogenous selection of text within a RichEdit/RichTextBox, without the arbitrary rounding that EM_SETFONTSIZE performs? Could the TOM interface be used?