Fixed
Status Update
No update yet.
Comments
aa...@google.com
rk...@google.com
Is hyphenation done in line layout? Anyone know about our hyphenation dictionary?
[Monorail components: -Blink Blink>Layout]
[Monorail components: -Blink Blink>Layout]
bo...@google.com
[Empty comment from Monorail migration]
ma...@gmail.com
Thanks for filing the issue!
@Reporter: Could you please share a sample test file satisfying the conditions mentioned inhttps://crbug.com/chromium/973102#c0 , which helps us to triage this further in a better way.
@Reporter: Could you please share a sample test file satisfying the conditions mentioned in
rk...@google.com
On which platform is this? The dictionaries are OS specific.
ma...@gmail.com
It's simple, create an HTML file that contains these words and change its content so that the words are at the end of the line. As I said, you'll have to play depending on your screen size and everything, I cannot provide a universal test case. You're probably used to doing this, I only do this on my local computer which is inaccessible to you.
My OS is Android 7.1.1 on a Sony Xperia Z5 Compact, but the issue has been reported to me from a user of Samsung Internet 9.2.10.15 on some Samsung device. So it does affect multiple devices.
My OS is Android 7.1.1 on a Sony Xperia Z5 Compact, but the issue has been reported to me from a user of Samsung Internet 9.2.10.15 on some Samsung device. So it does affect multiple devices.
rk...@google.com
Thank you for providing more feedback. Adding the requester to the cc list.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
ma...@gmail.com
rk...@google.com
Still occurs here. What did you try to reproduce as you failed? I just opened my website in Chrome on Windows (latest stable) and I can see this.
ma...@gmail.com
PS: Chrome on Windows now supports hyphenation. And it's just as broken as it was before on other platforms when I initially reported this.
rk...@google.com
Reporter, it would be greatly help us to analyze if you could share any reproducing URLs for our investigations.
I guess the page reporter is seeing has lang="en" or lang="en-uk".
Tests:https://jsbin.com/boxamav/edit?html,output
(may need to shorten "12345" or make it longer depends on fonts)
* Win/Linux/ChromeOS Chrome hyphenates at:
- "start-up" for "en-us"
- "star-tup" for "en-uk" and "en"
* Mac Chrome and Safari hyphenates at:
- "start-up" for "en-us" and "en"
- "star-tup" for "en-uk"
* Firefox doesn't hyphenate at either point.
Two points need investigations:
* I'm not sure if "star-tup" is the correct hyphenation for UK English.
* When the lang is "en", should it be "en-us" or "en-uk"? Currently, Chrome matches Android behavior, but from the tests, Safari seems to use "en-us" for "en".
[Monorail components: -Blink>Layout Blink>Layout>Inline]
I guess the page reporter is seeing has lang="en" or lang="en-uk".
Tests:
(may need to shorten "12345" or make it longer depends on fonts)
* Win/Linux/ChromeOS Chrome hyphenates at:
- "start-up" for "en-us"
- "star-tup" for "en-uk" and "en"
* Mac Chrome and Safari hyphenates at:
- "start-up" for "en-us" and "en"
- "star-tup" for "en-uk"
* Firefox doesn't hyphenate at either point.
Two points need investigations:
* I'm not sure if "star-tup" is the correct hyphenation for UK English.
* When the lang is "en", should it be "en-us" or "en-uk"? Currently, Chrome matches Android behavior, but from the tests, Safari seems to use "en-us" for "en".
[Monorail components: -Blink>Layout Blink>Layout>Inline]
rk...@google.com
My page lang value is set to "en". Does "en-uk" exist after all? AFAIK the ISO country code for UK is still "GB". At least all browsers offer me to send "en-GB" in the accepted languages header.
Anyway, you can see the effect here:https://ygoe.de/en
Both words appear in the content. Please note that hyphenation is only active for page widths below 420 pixels. You may also need to edit the content to place the words at a line end (open developer tools, find the parent <p> element and add the contenteditable attribute, then edit the text on the page before each word to place it where you want).
Anyway, you can see the effect here:
Both words appear in the content. Please note that hyphenation is only active for page widths below 420 pixels. You may also need to edit the content to place the words at a line end (open developer tools, find the parent <p> element and add the contenteditable attribute, then edit the text on the page before each word to place it where you want).
ma...@gmail.com
Thanks, sorry, you're right, not "en-uk", but "en-gb".
Confirmed a few things:
1. "star-tup" is not a correct hyphenation even for "en-gb".
2. Android, and Chrome Android/Win/Linux/ChromeOS uses "en-GB" when "en" is set.
https://android.googlesource.com/platform/frameworks/base/+/master/core/jni/android_text_Hyphenator.cpp#143
From the test result, it looks like macOS uses "en-US" when "en" is set.
The "hyphenator.js" uses "en-us" when "en" is set.
https://github.com/mnater/Hyphenator/blob/master/Hyphenator.js#L93
3. Our "en-gb" dictionary is up-to-date with the TeX hyphenation dictionary.
https://github.com/hyphenation/tex-hyphen/tree/master/misc
4. The "en-gb" dictionary has the "r1tu" entry, meaning to hyphenate as "r-tu". This entry does not exist in the "en-us" dictionary. The "hyphenator.js" has this entry too.
https://github.com/mnater/Hyphenator/blob/master/patterns/en-gb.js
5. Firefox and hyphenator.js does not hyphenate "startup" at all.
I'm still not sure whether the issue is in the "en-gb" TeX dictionary (reproduces on macOS too) or in the hyphenator code (not reproducible on Firefox and hyphenator.js,) and also not sure whether to map "en" to "en-gb" or to "en-us".
Confirmed a few things:
1. "star-tup" is not a correct hyphenation even for "en-gb".
2. Android, and Chrome Android/Win/Linux/ChromeOS uses "en-GB" when "en" is set.
From the test result, it looks like macOS uses "en-US" when "en" is set.
The "hyphenator.js" uses "en-us" when "en" is set.
3. Our "en-gb" dictionary is up-to-date with the TeX hyphenation dictionary.
4. The "en-gb" dictionary has the "r1tu" entry, meaning to hyphenate as "r-tu". This entry does not exist in the "en-us" dictionary. The "hyphenator.js" has this entry too.
5. Firefox and hyphenator.js does not hyphenate "startup" at all.
I'm still not sure whether the issue is in the "en-gb" TeX dictionary (reproduces on macOS too) or in the hyphenator code (not reproducible on Firefox and hyphenator.js,) and also not sure whether to map "en" to "en-gb" or to "en-us".
rk...@google.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src/+/a2c814f8d7db0008fc653d99532e5e7b8ff64732
commit a2c814f8d7db0008fc653d99532e5e7b8ff64732
Author: Koji Ishii <kojii@chromium.org>
Date: Tue Jun 22 01:06:11 2021
Change "en" hyphenation to use "en-us" instead of "en-gb"
When the specified langauge is "en", this patch changes to use
the "en-us" hyphenation dictionary instead of the "en-gb".
It looks like this behavior matches the other browsers.
Android maps "en" to "en-gb", but because Android takes the
language from the system, it is usually more specific (i.e.,
"en-us" or "en-gb", not "en".) On the other hand, CSS
prohibits using the system language <crbug.com/676270 > that
the use of "en" is more common.
Bug: 973102
Change-Id: I7547725b9d30fc137f987fb200fa2e4b699d2c21
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/2975039
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#894484}
[modify]https://crrev.com/a2c814f8d7db0008fc653d99532e5e7b8ff64732/third_party/blink/renderer/platform/text/hyphenation/hyphenation_minikin.cc
[modify]https://crrev.com/a2c814f8d7db0008fc653d99532e5e7b8ff64732/third_party/blink/renderer/platform/text/hyphenation_test.cc
commit a2c814f8d7db0008fc653d99532e5e7b8ff64732
Author: Koji Ishii <kojii@chromium.org>
Date: Tue Jun 22 01:06:11 2021
Change "en" hyphenation to use "en-us" instead of "en-gb"
When the specified langauge is "en", this patch changes to use
the "en-us" hyphenation dictionary instead of the "en-gb".
It looks like this behavior matches the other browsers.
Android maps "en" to "en-gb", but because Android takes the
language from the system, it is usually more specific (i.e.,
"en-us" or "en-gb", not "en".) On the other hand, CSS
prohibits using the system language <
the use of "en" is more common.
Bug: 973102
Change-Id: I7547725b9d30fc137f987fb200fa2e4b699d2c21
Reviewed-on:
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#894484}
[modify]
[modify]
ma...@gmail.com
The message #14 changes the dictionary for "en" to "en-us", which hyphenates "startup" correctly.
The issue in the "en-gb" hyphenation dictionary is not addressed yet though.
The issue in the "en-gb" hyphenation dictionary is not addressed yet though.
rk...@google.com
I don't know whether it's advisable to default from "en" to "en-US" given the worldwide spread of GB-based English (including Australia, India, South Africa, Singapore and others) over the very regional home of US-based English (including Canada only).
Even if you suggest using en-US here, it's probably wrong because my content uses en-GB spelling. And if I set en-GB instead of en, nothing has improved for me. It might even get worse on Macs.
Anyway, it shouldn't matter which is used if "star-tup" is invalid everywhere. So if the system produces that hyphenation, *something* is broken for sure. And please don't forget "JavaScript" as well.
I don't understand the note about Android knowing a more specific language from the system. The language definition comes from the lang attribute in the HTML document. It can change to anything and is completely unrelated to the current system's locale setting. Most websites have a language selector that redirects the visitor to another language version of the site, setting another lang attribute.
Even if you suggest using en-US here, it's probably wrong because my content uses en-GB spelling. And if I set en-GB instead of en, nothing has improved for me. It might even get worse on Macs.
Anyway, it shouldn't matter which is used if "star-tup" is invalid everywhere. So if the system produces that hyphenation, *something* is broken for sure. And please don't forget "JavaScript" as well.
I don't understand the note about Android knowing a more specific language from the system. The language definition comes from the lang attribute in the HTML document. It can change to anything and is completely unrelated to the current system's locale setting. Most websites have a language selector that redirects the visitor to another language version of the site, setting another lang attribute.
ma...@gmail.com
Thanks for the comment.
As in thehttps://crbug.com/chromium/973102#c14 , the switch to "en-us" is done to be interoperable with Safari and Firefox. As you point out, it's not related with this issue, but we found we're not interoperable with other browsers, therefore we took the change.
As you might have figured out, the "star-tup" issue reproduces in Safari too when you set lang="en-gb". All browsers use the TeX hyphenation dictionaries:
https://www.tug.org/tex-hyphen/
or one derived from TeX. I just learned its format as part of the investigation for this issue. As far as I understood, it is an issue in the dictionary itself. So I assume it reproduces in TeX too, though I don't have environment to test it.
On the other hand, however, it does not reproduce in Firefox and hyphenator.js even when I set lang="en-gb", so I'm going to look into why the difference appear. Hopefully that can figure out the real cause of the issue.
That's where I am now, sorry for the slow steps but I hope your understanding.
As in the
As you might have figured out, the "star-tup" issue reproduces in Safari too when you set lang="en-gb". All browsers use the TeX hyphenation dictionaries:
or one derived from TeX. I just learned its format as part of the investigation for this issue. As far as I understood, it is an issue in the dictionary itself. So I assume it reproduces in TeX too, though I don't have environment to test it.
On the other hand, however, it does not reproduce in Firefox and hyphenator.js even when I set lang="en-gb", so I'm going to look into why the difference appear. Hopefully that can figure out the real cause of the issue.
That's where I am now, sorry for the slow steps but I hope your understanding.
ko...@google.com
Yes, I have a workaround in place for now and prevent any hyphenation around the affected words. I'm going to change the lang attribute on my website to en-GB just to be more precise about my intention. I've learned here that it can actually make a difference.
an...@google.com
an...@google.com
Discussed with experts. A few more findings.
* Firefox does not ship the "en-gb" dictionary, but only "en-us"[1]. That probably explains why it does not reproduce in Firefox.
* The previous test on hyphenator.js was wrong, it reproduces too.
* The "star-tup" is probably an unfortunate side-effect for "star-tling"[2].
* In general, the quality of the TeX hyphenation dictionaries outside en-us varies.
Chromium uses the system dictionaries in Android. I think the "star-tup" issue should go to Android, or to the TeX community[3].
The "JavaScript" case is on us,https://crbug.com/chromium/963039 .
[1]https://searchfox.org/mozilla-central/search?q=intl%2Flocales&path=
[2]https://github.com/hunspell/hyphen/blob/master/tbhyphext.tex#L797
[3]https://www.tug.org/tex-hyphen/
* Firefox does not ship the "en-gb" dictionary, but only "en-us"[1]. That probably explains why it does not reproduce in Firefox.
* The previous test on hyphenator.js was wrong, it reproduces too.
* The "star-tup" is probably an unfortunate side-effect for "star-tling"[2].
* In general, the quality of the TeX hyphenation dictionaries outside en-us varies.
Chromium uses the system dictionaries in Android. I think the "star-tup" issue should go to Android, or to the TeX community[3].
The "JavaScript" case is on us,
[1]
[2]
[3]
Description
####################################################
Please provide all of the following information, otherwise we may not be able to route your bug report.
####################################################
1. Describe the bug or issue that you're seeing.
Hi, my name is Max, and I’m currently experiencing an issue with my Android Virtual Device (AVD). After creating the AVD, I’m unable to open it. The system keeps displaying a pop-up error stating that the AVD has terminated.
I checked the log file, and it shows the following error:
" 2024-12-04 19:07:57,970 [ 676451] INFO - Emulator: Pixel 9 Pro XL API 30 - [4504:2088:20241204,190757.970:ERROR filesystem_win.cc:130] GetFileAttributes C:\Users\crazy\AppData\Local\Temp\AndroidEmulator\emu-crash-35.2.10.db\attachments\4adcdf86-281b-417e-b896-b530668bbdcf: The system cannot find the file specified. (2) "
When I checked the file location, the folder was empty. Can u help solve about this ? Thank you!
2. Attach log files from Android Studio
2A. In the IDE, select the Help..Collect Logs and Diagnostic Data menu option.
2B. Create a diagnostic report and save it to your local computer.
2C. Attach the report to this bug using the Add attachments button.
3. If you know what they are, write the steps to reproduce:
3A. Unable to open the AVD
3B. Cannot file the attactments file
3C.
In addition to logs, please attach a screenshot or recording that illustrates the problem.
For more information on how to get your bug routed quickly, see
Build: AI-242.23339.11.2421.12700392, 202411230116
AS: Ladybug | 2024.2.1 Patch 3
AI-242.23339.11.2421.12700392, JRE 21.0.3+-12282718-b509.11x64 JetBrains s.r.o., OS Windows 10(amd64) v10.0 , screens 1920x1080 (100%), 1920x1080 (125%)
Android Gradle Plugin: 8.7.3
Gradle: 8.9
Gradle JDK: JetBrains Runtime 21.0.3
NDK: from local.properties: (not specified), latest from SDK: (not found)
CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)
Source: send_feedback_icon```