|author||Paul Pazderski <email@example.com>||Thu Nov 12 19:08:56 2020 +0100|
|committer||Paul Pazderski <firstname.lastname@example.org>||Tue Nov 17 03:35:37 2020 -0500|
Bug 568740 - [Win32] TextLayout renders underscore, strikeout and border only on last line Each of the three styles underscore, strikeout and border are rendered separately in there own method. TextLayout implementation for windows tries to optimize rendering of those styles by drawing adjacent styles in one a single call. (for border it also looks much better) It will test if two adjacent style parts (separate for underscore, strikeout and border) are 'adherent' which seem to mean they look the same. This can happen for once if the user supplies suboptimal styles, i.e. the same or an equal style instance for adjacent ranges instead of one style for the whole range at once. But even if adjacent styles are different it will still try to optimize rendering if a specific substyle is equal, e.g. two adjacent styles got different fonts but both use underline with the same color. In this case it will draw the underline in one call for both ranges. Now for the failing case. If a style expands over more than one line TextLayout will internally split those styles on line delimiter because it renders per line. This will include a separate StyleItem for the line delimiter to mark it as lineBreak which inherits the style of the range before. An example. The two lines content "abc\n123" with an underline over the hole range produce internally three StyleItems all with same style. While drawing the first line it will see underline for the "abc" part but postpone rendering because the adjacent style for "\n" has the same underline style. But line breaks are rendered differently so the postponed underline drawing will never happen. Change-Id: Ic19f13a559c79d148f62fc7944101dd59ae17dde Signed-off-by: Paul Pazderski <email@example.com>
Thanks for your interest in this project.
See the following description for how to contribute a feature or a bug fix to SWT.
Information regarding source code management, builds, coding standards, and more and be found under the following link.
Before your contribution can be accepted by the project, you need to create and electronically sign the Eclipse Foundation Contributor License Agreement (CLA).
Contact the project developers via the project's “dev” list.
This project uses Bugzilla to track ongoing development and issues.
Be sure to search for existing bugs before you create another one. Remember that contributions are always welcome!