| Summary: | [TextSizeDetermination] Add support for measurement of markup | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Ivan Furnadjiev <ivan> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | 1.5 | ||
| Target Milestone: | 1.5 M6 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 355861 | ||
|
Description
Ivan Furnadjiev
I would prefer if we could avoid measuring markup on the client. It feels like creating a dependency on browser-based clients. (In reply to comment #1) > I would prefer if we could avoid measuring markup on the client. It feels like > creating a dependency on browser-based clients. But with the current implementation (with or without RichTextToHtmlTransformer) we have this dependency on browser-based (HTML) clients anyway. Rich text (markup) on widgets requires HTML capable client. (In reply to comment #1) > I would prefer if we could avoid measuring markup on the client. It feels like > creating a dependency on browser-based clients. What would be the alternative to measuring markup? If we're going to support markup in widgets (even if it's just a bold text range in a label), I think we need to respect the markup in the measurement. Otherwise we'll get cut off text, wrong line wrapping and the like. If a client does not support markup, it would display and measure the text as-is. Applications written for those clients will therefore not use the markup feature anyway. A new internal method TextSizeUtil#markupExtent has been introduced. The measurement mode (string, text or markup) has been included in MeasurementItem and respected in TextSizeStorageUtil key generation. For markup size estimation all <br/> tags are replaced with "\n" and all other tags are removed. Changes are in CVS HEAD. |