-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Related Internationalization APIs #59
Comments
Thanks for filing this! It's definitely the case that this API is only one piece of the puzzle. Web applications that want to take advantage of raw font data will need to bundle a lot of other libraries currently lacking on the to make use of the data. We're focused on the specific use case for web applications that are already doing this (e.g. supplying ICU/Harfbuzz/FreeType via WASM). I'm definitely a fan of exposing more of ICU and whatever other low-level APIs we can to reduce the download cost. |
Just for context, as far as I know, Harfbuzz is down to a few hundred kilobytes, but a proper ICU implementation still requires megabytes of downloads for its various lookup tables. With Chrome now providing Intl.Segmenter, I think only the bidi algorithm from ICU is needed, but I don’t know how big just that part is since Intl.Segmenter is still too new for people to have dug into those details. |
https://github.com/tc39/proposal-intl-segmenter-v2 is relevant here. |
That proposal has recently been rejected. Apparently, line segmentation has been unable to proceed through the tc39 standardization process for many years. |
Yes, looking into it more deeply, line segmentation has been moved into WICG. Right now, it might be included as part of https://github.com/WICG/canvas-formatted-text , but it's not clear that it will be implemented in a way that's compatible with the local fonts proposal with custom font renderers. It also looks like that group is also still in its early stages. Can you please work with FrankYFTang to ensure that line segmentation gets standardized somewhere as part of WICG, so that web developers can add proper support for non-European languages to their apps? If something can be standardized and added sooner to Chrome and Firefox, that would at least allow web developers to start working with the APIs even if it's not universally implemented everywhere. |
Were you able to talk to @FrankYFTang about standardizing international line breaking yet? I know it may not seem important to people in California, but it is important to people in other countries. |
I know you already mention it several times in the docs, but I thought I would create an explicit issue for it. Working with raw font data in a correct way internationally requires lots of large APIs, so it would be good if you included an API to them too. There seems to be good progress on Intl.Segmenter, but with raw font data, web devs also need all the bidi/ltr/rtl stuff and a Harfbuzz-equivalent. If you don't include these APIs, there's going to be a lot of websites that only support "English-only" fonts as well as many others that download Harfbuzz every time you use them.
The text was updated successfully, but these errors were encountered: