PSA: You can test UI in right-to-left mode with #force-ui-direction

[Matt Giuca]

I just landed a flag chrome://flags/#force-ui-direction which allows you to switch the entire browser explicitly into left-to-right or right-to-left mode. (It is in Canary.) This allows you to simulate the layout you would see with Arabic or Hebrew, without having to change the language.

You can also use this on the command line: --force-ui-direction=rtl.

If you are working on UI, I encourage you to use this flag while testing your changes, to make sure it looks right. (Note: The text rendering tends to be a bit weird; you see things like periods at the start of sentences, but you can ignore that and just look at the UI layout.) Our UI toolkits generally handle this automatically, but occasionally something breaks in RTL mode. Remember, all users of RTL languages will experience the entire browser flipped horizontally!

Matt

[Kevin Bailey]

This is a great addition that I think will aid my testing. However, to completely facilitate testing my changes, I would need text to be reversed too. Does anyone know if any platform has an "RTL English" that actually lays out text RTL, but otherwise interacts e.g. with Google search as if it's English ? If not, does anyone know if this would be difficult to add?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Matt Giuca]

On Tue, 4 Apr 2017 at 04:19 Kevin Bailey <k...@chromium.org> wrote:

This is a great addition that I think will aid my testing. However, to completely facilitate testing my changes, I would need text to be reversed too. Does anyone know if any platform has an "RTL English" that actually lays out text RTL, but otherwise interacts e.g. with Google search as if it's English ? If not, does anyone know if this would be difficult to add?

I think it would be possible to make a "super force RTL" (or LTR) mode by making all text run in that direction. This would probably be hacked into RenderTextHarfBuzz::ItemizeTextToRuns.

https://cs.chromium.org/chromium/src/ui/gfx/render_text_harfbuzz.cc?q=::ItemizeTextToRuns

The line:

run->is_rtl = (run->level % 2) == 1;

would be replaced by (in super RTL mode):

run->is_rtl = true;

However, all of these changes to RenderTextHarfbuzz only affect the BROWSER UI and not the page contents. If you are looking for Google search, you would need to modify the Blink layout engine which I know nothing about (and I suspect may be more complex than what we have in the UI layer).

[Peter Kasting]

On Mon, Apr 3, 2017 at 11:18 AM, Kevin Bailey <k...@chromium.org> wrote:

This is a great addition that I think will aid my testing. However, to completely facilitate testing my changes, I would need text to be reversed too.

Can you clarify what sort of testing this additional bit facilitates?  Maybe there's a way to get similar effects today (e.g. by testing those pieces with --lang=he).

PK

[Justin Donnelly]

The goal is to more effectively test RTL text layout as someone who doesn't read an RTL language. You can muddle your way through it with --lang=he or ar and then pasting in translated text but you can't tell at a glance whether it's doing the correct thing (e.g. whether the text is getting truncated). Android and iOS offer a built in "RTL English" pseudolanguage for this purpose.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAHOzFDCPwDJQnVei1n7OmTsGnU8NKGTnMZWh%2B%2Bmmt--j%2BMz6g%40mail.gmail.com.

[Kevin Bailey]

Matt,

That might be sufficient. What I'm mostly testing is Omnibox contents and the drop-down.

Peter,

Obviously I could use an RTL language but I won't spot mistakes nearly as easily as if it were RTL English: e.g. cba vs <equivalent Hebrew>.

On Mon, Apr 3, 2017 at 4:44 PM, Peter Kasting <pkas...@chromium.org> wrote:

[Peter Kasting]

On Mon, Apr 3, 2017 at 5:10 PM, Justin Donnelly <jdon...@google.com> wrote:

The goal is to more effectively test RTL text layout as someone who doesn't read an RTL language. You can muddle your way through it with --lang=he or ar and then pasting in translated text but you can't tell at a glance whether it's doing the correct thing (e.g. whether the text is getting truncated). Android and iOS offer a built in "RTL English" pseudolanguage for this purpose.

Right.  My hope was that you can do 95% of what you want with Matt's flag, and use --lang for the last bits.  That's why I wanted to know what those bits are.

PK

[Matt Giuca]

I tried the change I was suggesting above. It was a disaster:

(The URL here is "localhost:8000/demos/share.html"). This happens both with and without the force RTL flag. Something deeper needs to be done than just rendering all runs as RTL.

(Not necessarily proposing that we implement this, but it might be helpful if there is a hack that developers can apply to their RenderTextHarfbuzz if they want to test this locally.)

[Peter Kasting]

On Mon, Apr 3, 2017 at 5:30 PM, Matt Giuca <mgi...@chromium.org> wrote:

I tried the change I was suggesting above. It was a disaster:

(The URL here is "localhost:8000/demos/share.html"). This happens both with and without the force RTL flag. Something deeper needs to be done than just rendering all runs as RTL.

I think the whole field would have to be force-RTLed by having Textfields wrap their contents in markers.

PK

[Alex Danilo]

You could possibly use directional override characters to test the layout:

http://unicode.org/reports/tr9/#Explicit_Directional_Overrides

Alex

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAHOzFDJ6hVcU1pqJOmfNB-N2%3DcL2YnyRJbvyhjL1St%3D69puVg%40mail.gmail.com.

[Peter Kasting]

On Mon, Apr 3, 2017 at 8:30 PM, Alex Danilo <x...@google.com> wrote:

You could possibly use directional override characters to test the layout:

http://unicode.org/reports/tr9/#Explicit_Directional_Overrides

Right, that's what the textfield would have to embed internally to force the overall direction.  Jungshik has a comment on one of the old "force URLs to be LTR" docs saying precisely which markers to place where.

PK

[Kevin Bailey]

Updating for the benefit of the readers. --force-ui-direction=rtl is of course necessary, but not sufficient, as expected. It only reverses the gravity.

Flipping run->is_rtl obviously doesn't reverse the run order, so the bold text in drop-down suggestions still appears on the right.

Wrapping direction overrides around the text (in OmniboxResultView::CreateClassifiedRenderText) works for me, but might not be sufficient for someone testing answers-in-suggest.

I haven't figured out how to reverse the Omnibox itself, since I really have to manipulate the Textfield within it. This might not be necessary for my needs, but it does seem to make everything off-by-one, because of the extra character at the beginning of each suggestion.

cheers,

krb