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 (43)

  1. Teis Johansen says:

    Just to be sure. Can I redistribute RichEdit 6.0 with my application?

  2. Kyle Alons says:

    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().

  3. I just had a couple random things to mention this afternoon: ARCast – Office 2007 Open XML Format (Part

  4. Bob F says:

    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!

  5. MurrayS3 says:

    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.

  6. Fazal Khan says:

    Is there any RichTextBox control available which is compatible with RichEdit 3.0 or later ver. ?

    How can I download it?

  7. Bob F says:

    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.

  8. I created a RichEdit 6.0 control and I’m having some problems with RTF created inside Outlook 2007. Shapes don’t show, textboxes just display their text but not the box, dropcaps create a newline, SmartArt, WordArt, Equations, and Horizontal Lines halt further processing of the RTF (but keep everything before it.) I can drag any of these objects into my control just fine and they show up perfectly, but when I read in the Outlook RTF if doesn’t like it very much. Under the hood it looks like outlook is using some strange undocumented (and apparently unsupported?) method of embedding binary data for certain objects inside the RTF (to save space?). Is there something that I don’t know here? I am reading in the attachments from where Outlook keeps them and placing them where they belong. These embedded objects however are not behaving correctly. Are there extra functions that I have to call her? Different functions? Styles to set? Options to enable? HELP!!

    Some objects, including PowerPoint Presentation objects don’t consider the boundaries of the control to be important.

  9. ... says:

    Du musst ein Fachmann sein – wirklich guter Aufstellungsort, den du hast!

  10. ... says:

    pagine piuttosto informative, piacevoli =)

  11. ... says:

    luogo grande:) nessun osservazioni!

  12. ... says:

    Great site! Good luck to it’s owner!

  13. ocnsss says:

    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/

  14. ... says:

    Luogo molto buon:) Buona fortuna!

  15. ... says:

    pagine piuttosto informative, piacevoli =)

  16. ... says:

    Ich erklare meinen Freunden uber diese Seite. Interessieren!

  17. ... says:

    9 su 10! Ottenerlo! Siete buoni!

  18. ... says:

    Stupore! Amo questo luogo!:)))))))

  19. ... says:

    Stupore! ho una sensibilit molto buona circa il vostro luogo!!!!

  20. ... says:

    E grande io ha trovato il vostro luogo! Le info importanti ottenute! ))

  21. Marcelo Saldanha says:

    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!

  22. Gareth says:

    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?

  23. Steve says:

    Any chance of the class names? I currently only know these:

    v1.0 = RICHEDIT

    v2.0 & v3.0 = RichEdit20A or RichEdit20W

    v4.1 = RICHEDIT50W

    Although I’ve only actually confirmed v4.1, so it would be nice to have a reliable source on the others. The v5.0 and v6.0 class names still elude me.

    Also, do any of them print tables spanning multiple pages correctly? With v3.0 and v4.1 using EM_FORMATRANGE or in various apps that use RichEdit, I see either:

    a.) They don’t seem to calculate the last row of a table that can fit on a page until the text is actually required. So on a long table that spans multiple pages, the vertical lines just kind of end at varying lengths depending on page content and trail off into nothingness. It would be incredibly difficult to draw a white box over the stray lines where this occurs because I don’t see any way I could calculate exactly where the table cuts off without knowing the exact font size and performing various calculations involving internal RichEdit rendering which I could only guess at for the spacing, etc.

    b.) They don’t print the last horizontal line of a table on a page before it carries over to the next because that horizontal line is part of the top of the next row. Obviously it works on the last row of the table, i.e. the one on the last page, but it seems someone forgot about multi-page print documents. Again, it would be difficult to calculate where to draw this line in myself.

    It would also be incredibly difficult for me to split the table on each print page into multiple tables so that they would always render correctly. This would also make editing of the document a nightmare if for example a row simply needed to be added somewhere, throwing all the tables out. I could work around that by maintaining two documents I guess, but the calcs for where to split the tables still scare me.

    The above problems occur in WordPad too, and in the WebBrowser control, and in Internet Explorer. Word always seems to get it right-ish. However the border lines in that are around the cells themselves so the last horizontal line of a page will be thinner, because there is no cell underneath, if you follow me. This also means most lines are doubled up and rather thick, with no obvious way to correct it. The WPF control renders similar to Word as I recall, but it is very slow, although my machine isn’t too shabby.

    v3.0  also doesn’t render tables with cells that have colspan greater than 1 correctly and v4.1 seemed to exceed the print bounds I specified, perhaps because of a table measuring issue involving said colspans, meaning several rows were missing from some pages. Unless the lparam of the EM_FORMATRANGE message is structured differently between those two versions? These issues I could probably work around though and it may be that I’m butchering the RTF spec in that case because those particular tables were converted from html by Word at some point.

    I appreciate any help you can provide. Most helpful would be the class names, so I can then test all of this for myself. But perhaps there is a better way to print than EM_FORMATRANGE? I hope I don’t have to go back to drawing everything on the print document manually with lots of horrible measuring calcs and not being able to edit or export to anything but Adobe Acrobat and Microsoft’s new XPS format via plugins.

    Anyway, I’ve really enjoyed your blog. You’ve made some really interesting posts. Toodles.

  24. BillInPA says:

    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.com

  25. 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.

  26. minhvc says:

    How to use the new features of RichEdit 6.0. Can I built a setup my application with RichEdit 6.0 without contact MS?

  27. Steve says:

    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.

  28. Dave says:

    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.

  29. MurrayS3 says:

    RichEdit is developed  by Microsoft Office and is a basic component in this program suite. Two versions (RichEdit 3.0 and 4.1) are also distributed with Windows. They shipped originally with Office 2000 and Office 2002. We’ve been hoping to ship a newer version in Windows for some time, but testing the huge backward compatibility scenarios and writing the up-to-date documentation have been stumbling blocks. Comments like yours help increase the priority. Thanks

    For a more complete discussion, see my post http://blogs.msdn.com/murrays/archive/2006/10/14/richedit-versions.aspx

  30. wrx says:

    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.

  31. MurrayS3 says:

    Math RTF conversion isn’t enabled in the RichEdit 6.0 that ships with Office 2007.

  32. jj2006 says:

    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.

  33. Neal says:

    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

    Neal

  34. MurrayS says:

    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.

  35. Oleg says:

    Do you know how enable underline color in RichTextBox based on RichEdit 6.0 or 5.0?

    Thank for answer!

  36. polypress says:

    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?

    Thanks

  37. dbenito says:

    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?

  38. Zhou Wu says:

    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.  

  39. oldlamer says:

    Dear Murray,

    I'm writing an application (plain C) which uses RichEdit and should perform spell-checking. I thought it was easy to subclass paint event and after finding incorrect word just to draw wavy line under it. But I cannot find any way to get the height of this word (or the height of entire line of RichEdit) – because the text may be formatted with different fonts and sizes.

    Is there any way to find the height of line in RichEdit? Have found nothing yet.

  40. MurrayS3 says:

    You could use ITextRange::GetPoint() to find out the height, ascent, descent, etc., of the text at the range, but a better approach is to use RichEdit's own squiggly underlines via ITextFont. Specifically get an ITextFont from an ITextRange that selects the word to be underlined, call ITextFont::Reset(tomApplyTmp) to cause the ITextFont to use temporary formatting. Then set up the underline type you want in ITextFont::SetUnderline(Value) and call ITextFont::Reset(tomApplyNow) to actually do the underlining. Such formatting isn't saved in file formats. tomApplyTmp is defined as 4 and tomApplyNow is 0.

    The Value has the meanings: high byte = 0xFF, low three bytes are underline RGB color; high byte = 0, low bits are the underline type defined by the enum

    tomNone = 0,

    tomSingle =1,

    tomWords = 2,

    tomDouble = 3,

    tomDotted = 4,

    tomDash = 5,

    tomDashDot = 6,

    tomDashDotDot = 7,

    tomWave = 8,

    tomThick = 9,

    tomHair = 10,

    tomDoubleWave = 11,

    tomHeavyWave = 12,

    tomLongDash = 13,

    tomThickDash = 14,

    tomThickDashDot = 15,

    tomThickDashDotDot = 16,

    tomThickDotted = 17,

    tomThickLongDash = 18

  41. Daniel Firka says:

    Hi Murray,

    Would you mind providing an update of this post with the versions following Office 2007, and also 32/64 compatibility issues? thanks

  42. Martin Watson says:

    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 you

  43. Query says:

    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?