diff options
author | xji@chromium.org <xji@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-23 06:00:44 +0000 |
---|---|---|
committer | xji@chromium.org <xji@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-23 06:00:44 +0000 |
commit | 4ea6cab1939dff2111f779d8fff80e5dc5d7b8c6 (patch) | |
tree | aa3de08379aab61f8ac17f55b419ec5119eea2ab /chrome/common/gfx | |
parent | b285a98a45c5ddd4ad9080a06d5a7d4943ac19d9 (diff) | |
download | chromium_src-4ea6cab1939dff2111f779d8fff80e5dc5d7b8c6.zip chromium_src-4ea6cab1939dff2111f779d8fff80e5dc5d7b8c6.tar.gz chromium_src-4ea6cab1939dff2111f779d8fff80e5dc5d7b8c6.tar.bz2 |
This CL fixes issue 6099 -- bad display of multi-line English message in pop ups.
(http://crbug.com/6099)
Currently, in RTL locales, a pure *multi-line* English message is displayed as right aligned and has RTL directionality (such as the ending punctuation appears at the very left).
Single-line message works fine.
I do not know why, but simply putting LRE-PDF around a multi-line English text which has the following flags
DT_WORDBREAK | DT_RTLREADING
wont render the English message as LTR.
We have to remove the DT_RTLREADING to render multi-line English message correctly in LTR direction.
The fix is that in RTL locales, for JavaScript message, if the message is pure English, the alignment is set to be left-aligned, and the directionality is set to be left-to-right. If the message is mixed BiDi text, the alignment and the directionality is determined by the directionality of the first character with strong directionality in the text.
JavaScript message is a MessageBoxView, and the message is a view::Label. Both MessageBoxView and Label are used by Chrome's UI as well.
If the message is one of Chrome UI's, the alignment and directionality of the message should be taken from that of the UI's.
In order to distinguish where the message comes from, a new flag kFlagWebMessage is introduced in MessageBoxView, and a new argument is introduced in Label::SetHorizontalAlignment() to control whether the alignment need to be flipped or not for RTL locales.
Consequently, quite a few files which calls Label::SetHorizontalAlignment() are changed.
The main changes are in 5 areas. Other files are changed due to the signature change of Label::SetHorizontalAlignment().
1. jsmessage_box_handler.cc: pass in extra flag kFlagWebPage when creating MessageBoxView to indicate the message box is one from a web page, not from Chrome UI.
2. l10n_util.h/.cc
added function GetFirstStrongDirection()
3. label.h/.cc
a new argument is introduced in Label::SetHorizontalAlignment() to control whether the alignment need to be flipped or not for RTL locales.
4. message_box_view.cc
when init message box view, if the flag is kFlagWebPage, get the text directionality from the text itself (not Chrome UI's) and calls Label::SetHorizontalAlignment() to not resetting the flag for RTL locales.
5. chrome_canvas_win.cc
5.1 ComputeFormatFlags()
only set flag DT_RTLREADING for RTL locales if the text contains strong RTL characters and the alignment is RIGHT aligned. All labels of Chrome's UI and other Chrome UI components in RTL locales have been set as (or flipped to) RIGHT aligned.
5.2 DoDrawText()
Only adjust string for locale is the reading direction is DT_RTLREADING.
Review URL: http://codereview.chromium.org/18863
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10178 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/common/gfx')
-rw-r--r-- | chrome/common/gfx/chrome_canvas_win.cc | 44 |
1 files changed, 35 insertions, 9 deletions
diff --git a/chrome/common/gfx/chrome_canvas_win.cc b/chrome/common/gfx/chrome_canvas_win.cc index f28b0cb..770effb 100644 --- a/chrome/common/gfx/chrome_canvas_win.cc +++ b/chrome/common/gfx/chrome_canvas_win.cc @@ -21,9 +21,14 @@ void DoDrawText(HDC hdc, const std::wstring& text, std::wstring localized_text; const wchar_t* string_ptr = text.c_str(); int string_size = static_cast<int>(text.length()); - if (l10n_util::AdjustStringForLocaleDirection(text, &localized_text)) { - string_ptr = localized_text.c_str(); - string_size = static_cast<int>(localized_text.length()); + // Only adjust string directionality if both of the following are true: + // 1. The current locale is RTL. + // 2. The string itself has RTL directionality. + if (flags & DT_RTLREADING) { + if (l10n_util::AdjustStringForLocaleDirection(text, &localized_text)) { + string_ptr = localized_text.c_str(); + string_size = static_cast<int>(localized_text.length()); + } } DrawText(hdc, string_ptr, string_size, text_bounds, flags); @@ -31,7 +36,7 @@ void DoDrawText(HDC hdc, const std::wstring& text, // Compute the windows flags necessary to implement the provided text // ChromeCanvas flags. -int ComputeFormatFlags(int flags) { +int ComputeFormatFlags(int flags, const std::wstring& text) { int f = 0; // Setting the text alignment explicitly in case it hasn't already been set. @@ -82,9 +87,30 @@ int ComputeFormatFlags(int flags) { // English) this flag also makes sure that if there is not enough space to // display the entire string, the ellipsis is displayed on the left hand side // of the truncated string and not on the right hand side. - if (l10n_util::GetTextDirection() == l10n_util::RIGHT_TO_LEFT) - f |= DT_RTLREADING; - + // + // We make a distinction between Chrome UI strings and text coming from a web + // page. + // + // For text coming from a web page we determine the alignment based on the + // first character with strong directionality. If the directionality of the + // first character with strong directionality in the text is LTR, the + // alignment is set to DT_LEFT, and the directionality should not be set as + // DT_RTLREADING. + // + // This heuristic doesn't work for Chrome UI strings since even in RTL + // locales, some of those might start with English text but we know they're + // localized so we always want them to be right aligned, and their + // directionality should be set as DT_RTLREADING. + // + // Caveat: If the string is purely LTR, don't set DTL_RTLREADING since when + // the flag is set, LRE-PDF don't have the desired effect of rendering + // multiline English-only text as LTR. + if (l10n_util::GetTextDirection() == l10n_util::RIGHT_TO_LEFT && + (f & DT_RIGHT)) { + if (l10n_util::StringContainsStrongRTLChars(text)) { + f |= DT_RTLREADING; + } + } return f; } @@ -115,7 +141,7 @@ void ChromeCanvas::SizeStringInt(const std::wstring& text, b.right = 1; } b.bottom = *height; - DoDrawText(dc, text, &b, ComputeFormatFlags(flags) | DT_CALCRECT); + DoDrawText(dc, text, &b, ComputeFormatFlags(flags, text) | DT_CALCRECT); // Restore the old font. This way we don't have to worry if the caller // deletes the font and the DC lives longer. @@ -141,7 +167,7 @@ void ChromeCanvas::DrawStringInt(const std::wstring& text, HFONT font, SkColorGetB(color)); SetTextColor(dc, brush_color); - int f = ComputeFormatFlags(flags); + int f = ComputeFormatFlags(flags, text); DoDrawText(dc, text, &text_bounds, f); endPlatformPaint(); |