Rich Text Editor – Improved WYSIWYG Support (v18.1)

As we all know, accurate document rendering is an important feature for any word processing tool. In our forthcoming release, we’ve invested significant resources to improve the manner in which our DevExpress Rich Edit control for WinForms, WPF, and our Word Processing File API renders documents.

Before I describe what we expect to ship in v18.1, let me take a moment to detail the issues we sought to address in this release.

When we began work on our Rich Edit control over a decade ago, we decided to use a 96DPI display resolution to calculate its layout. Because high-resolution devices did not exist, our choice was a logical one. We used 300DPI for printing. Thus, the Rich Edit control calculated its display and print layouts using different units. This caused a problem with layout consistency in the Rich Edit control. A document would not accurately print content: paragraphs could slide apart, text lines could shift to the next page, etc. Here is an example:

Rich Text Editor - Print and Display Layouts in v17.2

To address this issue, your only option was to change display units. Unfortunately, this move could lead to layout corruption.

With the start of the high DPI era, we encountered new but similar issues. Pixel size is no longer absolute and is based on system settings. As a result, a document may not display properly on devices with non-standard DPI settings.

The bottom-line is simple: the need to modify our Rich Text Editors is no longer an option...we had to act.

With this release, we’ve modified layout calculation algorithms for both our RichEditControl (WinForms and WPF) and our Word Processing File API.

These modifications help to:

  1. Increase the accuracy of document layouts.
  2. Eliminate the need for any customization. Documents maintain the same appearance when displayed within the viewer, printed or exported to PDF.

And as you’ve probably guessed by now, DPI settings are also no longer an issue. Simply said, the changes we’ll introduce in v18.1 help ensure that “what you see is what you get.”

Rich Text Editor - Print and Display Layouts in v18.1

Unfortunately, there is a downside to these changes. Since we’ve updated the layout engine in v18.1, your documents may look different than in previous releases.

For those who want to retain previous document layouts, we’ve kept the previous behavior for backward compatibility. To activate it, enable RichEditControlCompatibility.EnableLegacyLayoutEngine option at the application start.

We are working hard to extend document layout accuracy and hope to incorporate additional enhancements in future release cycles. Please let us know what you think about this change. We’d love to hear your feedback.

4 comment(s)
Jean-Francois
Jean-Francois

Great!  This has been (is) a serious issues for us with our users, so we are very happy to see it fixed.

Now will that help with the implementation of footnotes that is being requested by many of your customers (including us...) for years?

17 April, 2018
Office Products Team
Office Products Team

Thank you for your feedback!

We plan to improve our document formatter in future releases. Please stay tuned to our What's New announcements.

18 April, 2018
Eric Legault
Eric Legault

Are there any related changes to the way HTML-based documents are rendered when you import from an HTML file? Any support for responsive HTML design?

24 April, 2018
Office Products Team
Office Products Team

@Eric - We haven't changed anything in our HTML import in this release. Of course, we will keep your ideas in mind.

25 April, 2018

Please login or register to post comments.