LGTM3. Thanks everyone for providing compelling evidence that this is solving an important need well.
On Thursday, October 21, 2021 at 5:10:27 AM UTC-7 一丝 wrote: > > Chinese version of this email: > https://www.yuque.com/docs/share/ba9f5d45-b1d3-49d6-9a69-d4cb5841de7f > > Thanks to Dominik's hard work behind the scenes, COLRv1 has gone from an > idea to a technology that everyone can use. > > Since Adobe released PostScript in 1984, font technology has undergone a > huge transformation. Looking back on the history, there have been many > detours due to commercial competition. Today, we are at a crossroads again, > and I believe COLRv1 will leave a strong mark on the history of fonts. > > > I am the head of development at www.iconfont.cn > <https://www.iconfont.cn/?lang=en-us>, *iconfont fully endorses the > COLRv1 font format and fully agrees with Chromium's views here.* > > Please allow me to briefly introduce: > > iconfont is the vector (SVG) material management platform of Alibaba > Group, we have millions of massive icons. With iconfont, designers and > developers can easily collaborate. When designers draw icons, they only > need to export SVG and upload it to iconfont to generate code and various > fonts easily. > > Generating colorful fonts with gradients has been the biggest request from > our users. We have also considered the SVG in OT format, but there are > several significant problems. > > 1. generating large font files > 2. variable fonts are not supported > 3. Not supported in *MiniApp*: > https://www.w3.org/TR/mini-app-white-paper/ > > [image: image (3).png] > > Test page(64 emojis): https://at.alicdn.com/t/iconfont/project/900373.html > > > In the end, we chose the COLRv0 format, which does not support gradients. > As of 2021-10-21, here are some data of iconfont.cn. > > - Total number of icons: *16800000+* > - Total number of color icon collections: *4559* > - Total number of projects: *2670000+* > - Total number of color fonts (COLRv0) projects: *4535* > > > There are already 4535 projects with COLRv0 enabled, but nowhere near the > total number of projects 2670000+, I believe a big reason is that they are > waiting for font icons with gradients. So, as soon as Chrome ships COLRv1, > iconfont can implement it quickly so that all users can easily generate > COLRv1 fonts. > > > At Alibaba, many apps are using font icons and I'm pushing to switch the > emoji in Dingtalk App <https://www.dingtalk.com/en> from png to vector > color fonts, which will be a brand new experience. > > [image: 2021-10-21 18_35_22.gif] > > Let's drink to that 🍻 and wait for the good news of the release. > > > Acknowledgements > > Heartfelt thanks to Dominik Röttsches, Behdad Esfahbod, Roderick Sheeter, > Cosimo Lupo and others for their help and support. > > - English users can visit: https://www.iconfont.cn/?lang=en-us > - More iconfont color font introduction: > https://www.yuque.com/yisi/iconfont/colr-font > > > 一丝(Percy Ley) > > 在2021年10月21日星期四 UTC+8 上午7:36:40<dli...@microsoft.com> 写道： > >> +1, thanks for driving this Dominik. Edge is looking forward to COLRv1 >> shipping to provide a compact format that enables a wider set of features >> that icon and emoji fonts can take advantage of. >> On Wednesday, October 20, 2021 at 5:43:52 AM UTC-10 >> pcons...@microsoft.com wrote: >> >>> @Dominik: Thanks for the detailed write-up, and for driving the process >>> to ship support for COLR v1 in chromium. Naturally, as collaborator on the >>> COLR v1 spec, and the one getting it added to OpenType (for version 1.9, to >>> be released soon), I can say that Microsoft is in general supportive of >>> this extension to the OpenType format, and am fully in support of seeing >>> this supported in Chromium. >>> >>> Color fonts have been around for almost a decade, but have not really >>> taken off. I suspect a contributing factor for that is that there hasn't >>> been one format that is widely supported in applications. >>> >>> I also suspect there hasn't been excitement around the bitmap formats >>> ('sbix' or 'CBDT' tables) because bitmaps aren't scalable and lead to large >>> font files. (That's especially the case when alternate bitmaps of different >>> sizes are added to compensate for the lack of scalability.) The bitmap >>> formats also don't integrate at all with variations, which is a downside >>> against them. >>> >>> Clearly a colour vector format is to be preferred. OT-SVG is already >>> available as a vector format. But for reasons I mentioned in the webkit-dev >>> list (cited above), I don't think we should expect it to be adopted widely >>> in environments that don't already have XML and CSS parsers. OT-SVG and >>> COLR v1 will require similar 2D graphics support, and both require ttf >>> parsing, but OT-SVG also requires XML/CSS parsing, which is certainly more >>> complex than parsing the structures added for COLR v1. >>> >>> COLR v1 also has the significant advantage of being much better >>> integrated into other aspects of the OpenType format, notably variations. >>> >>> For all these reasons, I believe the enhanced COLR table has the best >>> prospects among the various OpenType colour formats of being the one that >>> eventually gains wide adoption and allows colour fonts to gain significant >>> interest beyond platform-specific emoji fonts. >>> >>> @Rego: >>> > Did we manage to get any further feedback from Apple after that email? >>> >>> I haven't heard much further from Apple, but I don't expect them to give >>> away too much. The only public comments I've seen have been in the context >>> of webkit, which may or may not reflect the perspective of other product >>> groups. Even with v1, the COLR table doesn't yet provide the level of >>> graphic capability needed to duplicate the carefully, pixel-by-pixel >>> crafted designs in their emoji font, so I assume they don't have an >>> immediate motivation to utilize COLR v1 in their products (unlike Google, >>> Microsoft and perhaps other vendors who can benefit from COLR v1 with their >>> emoji designs). So, I'm guessing they're taking a wait-and-see approach, >>> but that's just a guess. >>> >>> On Tuesday, October 19, 2021 at 11:01:24 AM UTC-7 Manuel Rego wrote: >>> >>>> Hi Dominik, >>>> >>>> On 19/10/2021 09:31, Yoav Weiss wrote: >>>> > *WebKit:* Negative >>>> > (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html >>>> <https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html>) >>>> >>>> > >>>> > From the WebKit team, we received this negative response stating >>>> > there's no real need for COLRv1 as OT-SVG exists, to which I >>>> > responded extensively in this post >>>> > <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031839.html>. >>>> Please >>>> > refer to this thread for further details. Some API owners are >>>> > already familiar with this discussion. My response sheds more light >>>> > on some assertions and assumptions made by WebKit folks and provides >>>> > a competitive analysis between OT-SVG and COLRv1 in terms of >>>> > implementation complexity, file size and performance. >>>> > Microsoft's Peter Constable responded as well >>>> > <https://lists.webkit.org/pipermail/webkit-dev/2021-April/031789.html> >>>> >>>> > on behalf of Microsoft and Edge positively. >>>> > >>>> > >>>> > I highly appreciate your measured and factful response on that thread >>>> as >>>> > well as Peter's. Thanks for maintaining a high level of discourse. >>>> >>>> Yeah really nice reply there. >>>> >>>> Did we manage to get any further feedback from Apple after that email? >>>> Even if it was not directly on the webkit-dev mailing list but in some >>>> private conversations, working group discussions or whatever. >>>> >>>> Cheers, >>>> Rego >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/be4721e4-506f-4942-a48d-d39067430645n%40chromium.org.
