Skip to content
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

Open
my2iu opened this issue Oct 31, 2020 · 6 comments
Open

Related Internationalization APIs #59

my2iu opened this issue Oct 31, 2020 · 6 comments
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.

Comments

@my2iu
Copy link

my2iu commented Oct 31, 2020

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.

@inexorabletash
Copy link
Member

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.

@my2iu
Copy link
Author

my2iu commented Nov 2, 2020

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.

@inexorabletash
Copy link
Member

https://github.com/tc39/proposal-intl-segmenter-v2 is relevant here.

@my2iu
Copy link
Author

my2iu commented Mar 30, 2022

That proposal has recently been rejected. Apparently, line segmentation has been unable to proceed through the tc39 standardization process for many years.

@my2iu
Copy link
Author

my2iu commented Mar 30, 2022

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.

@my2iu
Copy link
Author

my2iu commented Jul 16, 2022

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.

@xfq xfq added the i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. label Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.
Projects
None yet
Development

No branches or pull requests

3 participants