Please provide links to free and preferably open source fonts.

see http://glyphwiki.org/wiki/GlyphWiki:%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6%E4%BD%BF%E3%81%86%E3%81%AE%E3%81%8B （japanese）

(In reply to comment #2)

see
http://glyphwiki.org/wiki/GlyphWiki:%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6%E4%BD%BF%E3%81%86%E3%81%AE%E3%81%8B
（japanese）

see https://zh.wikipedia.org/wiki/MediaWiki:Gadget-webfont.js

Why is this bug in ULS component?

(In reply to comment #4)

Why is this bug in ULS component?

Because the WebFonts extension is deprecated.

About https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Improve_Extension:WebFonts_or_Extension:UniversalLanguageSelector_for_Chinese_.28or_CJK.29_wikis

Is there an interest in proposing this project for Outreach Program for Women?
If so, and if there at least one mentor for it. please move it to the "Featured projects" section. This way it will be automatically transcluded in
https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7

Thank you!

vladjohn2013 wrote:

Hi, this project is still listed at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Improve_Extension:WebFonts_or_Extension:UniversalLanguageSelector_for_Chinese_.28or_CJK.29_wikis

Should this project be still listed in that page? If not, please remove it. If it still makes sense, then it could be moved to the "Featured projects" section if it has community support and mentors.

(In reply to vladjohn2013 from comment #7)

moved to the "Featured projects"
section if it has community support and mentors.

Done now.

xiaoxiangquan wrote:

(In reply to vladjohn2013 from comment #7)

Hi, this project is still listed at
https://www.mediawiki.org/wiki/Mentorship_programs/
Possible_projects#Improve_Extension:WebFonts_or_Extension:
UniversalLanguageSelector_for_Chinese_.28or_CJK.29_wikis

Hi, I'm going to take the project to apply for GSoC 2014. I have got some plans listed in the proposal, which can be found here:
https://www.mediawiki.org/wiki/User:Xiaoxiangquan/UniversalLanguageSelector_Fonts_for_Chinese_wikis

And the announcement on Wikitech-l is at
http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075232.html

Any feedback is more than welcomed! Thanks in advance!

See https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector/Fonts_for_Chinese_wikis/final_post

Xiangquan Xiao's project was evaluated by his mentors as PASSED. Still, what is the status in reference to this report? FIXED or are we still missing something? If so, please document what is missing. Thank you for your work!

xiaoxiangquan wrote:

Actually it's far from production status, much like a conceptional project. As the demo[1] shows, it does work.

But there are still some problems to be addressed[2]. Some of them are just out of my knowledge, e.g. font manipulate. And I have no idea yet for some others, e.g. additional content loaded with AJAX.

My mentor agrees that there are still a lot of base work to do. I'll keep on, or at least keep responsive, and willing to mentor on future GSoC projects. (I myself has just graduated and start my career.)

BTW, I have ported the work to github[3], a simpler and universal solution.

[1] http://fonttailor.wmflabs.org
[2] https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector/Fonts_for_Chinese_wikis#Known_Issues
[3] https://github.com/xiaoxq/webfonts-subsetting

I wonder whether completing this task as in working in production would make a good #Possible-Tech-Project for a future Outreachy / GSoC edition.

Sounds unlikely. Big fonts and tofu detection in production proved to be a hard interplay with performance and ops folks, which is not feasible for a short-lived lone project. We don't even have a list of tasks.

very unlikely. This bug is close to 'declined' state.

The large size might be avoidable by slicing the webfont into smaller units of e.g. 256 glyphs and merging the slices back into one font in css using unicode ranges. This may have some advantages over 'tailored' subsets as it provides some possibility of reusing among pages, and this reduces the need of having dynamic magic too.

For common glyphs it might be desirable to carefully organize the glyphs so they have a better chance of coexisting on one page, but for rare SIP glyphs (which this task cares about) this is mostly arbitrary as they are basically all very rare.

Regarding font usage, while WenQuanYi (Sans) in Xiaoxiangquan's proposal provides a good number of glyphs with a relatively small size (thanks to truetype references in Micro Hei), hanazono (Serif) can be used as a catch-all fallback after WQY. As with all web fonts, WOFF/WOFF2 is the preferred way to go.

In T33791#2314662, @Arthur2e5 wrote:

The large size might be avoidable by slicing the webfont into smaller units of e.g. 256 glyphs and merging the slices back into one font in css using unicode ranges. This may have some advantages over 'tailored' subsets as it provides some possibility of reusing among pages, and this reduces the need of having dynamic magic too.

Could you please give me another demo about this method? http://fonttailor.wmflabs.org/ no longer possible to visit.

For common glyphs it might be desirable to carefully organize the glyphs so they have a better chance of coexisting on one page, but for rare SIP glyphs (which this task cares about) this is mostly arbitrary as they are basically all very rare.

Regarding font usage, while WenQuanYi (Sans) in Xiaoxiangquan's proposal provides a good number of glyphs with a relatively small size (thanks to truetype references in Micro Hei), hanazono (Serif) can be used as a catch-all fallback after WQY. As with all web fonts, WOFF/WOFF2 is the preferred way to go.

Maybe dzahn could help you or not?

In T33791#2315571, @Liuxinyu970226 wrote:

Could you please give me another demo about this method? http://fonttailor.wmflabs.org/ no longer possible to visit.

W3C CSS Fonts 3 considers lazy loading as a purpose in sec 4.8, and includes a range-aware lazy loading behavior in sec 5.2. Meyer 2013 also mentions some subsetting, although not as aggressive as my suggestion.

I will try to make a demo after my exam in early June, which is also when my poorly-enforced wikibreak ends. (Hope I don't screw my grades up, or bye-bye computers…) The implementation should mainly be written in FontForge/Python, and generates a set of static files. Some initial file size metrics can be taken then.

Maybe dzahn could help you or not?

I don't think I need any access to any wikimedia resources for now (not starting until June 15) and for the initial PoC (some cross-site @import in user-custom CSS will work).