Commons talk:Stroke Order Project/Archive 1

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.


Reevaluating the naming convention

I have some concerns about the image naming convention. Currently, the simplified Chinese serves as the baseline for the Han characters. The other two schools of writing — traditional Chinese and Japanese — have characters added where they differ from the baseline. There is, however, little information about which characters have been checked and there are no guarantees that where a character is missing, it has the same stroke order as the baseline. This prevents a graceful fallback for traditional Chinese and Japanese. Just as simplified Chinese shouldn't fall back on Japanese without being thoroughly checked beforehand, the converse shouldn't happen either.

My suggestion is that we move away from this fallback system in favour of one that guarantees accuracy without demanding that uploaders have access to sources on all stroke order variants. I'm not sure what the best system would be, but I've toyed a bit with the idea of creating redirects. These, unfortunately, don't show up in categories that contain the original. We could then have to create manual catalogues to show which characters exist in which variants or modify the {{SOlicense}} template to list variants.

I'd be interested in doing some brainstorming to get a more reliable system in place so please share your thoughts. --Swift (talk) 01:17, 22 October 2008 (UTC)


My initial idea was to set these characters up at distinct filenames, but once characters with the same stroke order were identified, the file would be moved to a "variant neutral" filename (like the current simplified Chinese) and set up redirects to it.

Categories can be maintained by transcluding the {{SOlicense}} but redirects can be confusing and selecting the images in categories and galleries takes users to the source image page. Redirect pages have a further downside in not showing the categories they are in.

I set up Image:一-jorder.gif to test case a few setups for those interested in playing around. --Swift (talk) 06:17, 4 November 2008 (UTC)

Maybe a few simple "fallback" things would work out better? Like, with a redirect you never know too sure that it is placed with 100% accuracy, maybe just maintain a list of the different kanji stroke orders or something? I don't know if the redirect solution is going to be that vital, especially, since it doesn't say on the page you redirect to, that it is redirected and with the new template
Authority control
, it would even list the redirected picture as a variant... So maybe a list is going to work out much better? --Tauwasser (talk) 00:27, 25 January 2009 (UTC)
Actually, the fall-back was the problem. See the recent discussion in these sub-sections.
The issue of users not noticing that they've been redirected has also been raised. I implemented a rough idea for a solution to this (which you reverted). I'll work more on this later. --Swift (talk) 02:42, 25 January 2009 (UTC)
Sorry, I still don't see what your code is supposed to be doing with redirects... It just changes the background color, so it won't show itself in the list of other versions with the same background color like all the others. It didn't really work for me regardless, as all the pictures had a funny color around them (which was not the background color for me that the other entries had) and red links everywhere... Maaybe I don't see what it's supposed to be doing? --Tauwasser (talk) 15:16, 25 January 2009 (UTC)
This template is a work in progress and the code wasn't complete. --Swift (talk) 08:04, 27 January 2009 (UTC)

Maintaining copies

One way to check these would be to seperate these schools of writing. Images for characters that share stroke order would then be uploaded twice under different names.

An example: the traditional Chinese stroke order for character X is uploaded under a filename such as X-t-order.gif. Later it is verified to have the same stroke order as in Japanese, so the same file is reuploaded under the filename X-j-order.gif. The simplified Chinese turns out to be different, and thus a seperate file has to be uploaded.

This will ensure that if a mistake is found to exist in a character (say the traditional Chinese) but the Japanese was correct, then updating the traditional Chinese won't mess up the Japanese. The down-side of this is that we'll end up with a whole host of duplicate files under slightly different names. I'm not sure if that is such a bad thing, though.

Maintainance won't be too hard as we can have index pages that list all the variants of each available character. --Swift (talk) 06:17, 4 November 2008 (UTC)

Kanji progress

I've started a new kanji progress page at Commons:Stroke Order Project/Kanji progress. This duplicates Chinese_stroke_order:KanjiProgression, but I didn't want to overwrite a something useful. I'm not sure what, precisely, that page is attempting since the columns on that page are labeled with contributors and only one lists Japanese specific ones.

Anyway, on the new page I'd like to list links to images with characters listed on the Heisig list (currently 2042 characters). It's the same list as the previous progress page and very useful since it's readily available online. I've added information about where I retrieved the raw list and how I formatted it.

I'd also like to set up a column for verification; possibly one for each of the sources listed on the sources page. I'm going to think about how to best do that. For convenience, I've also listed the "fall-back" characters (the ones without "j" in their filenames) since these may have the right stroke order and could reduce duplicating work. --Swift (talk) 03:12, 16 November 2008 (UTC)

OK, I've just completed the new Commons:Stroke Order Project/Kanji progress pages. They list the 2042 kanji of the current Heisig list. The page describes how to obtain and format a new list.
This obsoletes these pages:
I propse that we delete them as they are out of date and don't reflect the current status of the proejct. --Swift (talk) 17:28, 3 February 2009 (UTC)
I've just tagged them {{speedy}}. --Swift (talk) 19:06, 16 February 2009 (UTC)

Progress templates

{{Hanzigallery}} is designed for the Chinese varants lists, but is also used on Commons:Stroke Order Project/Hiragana, Commons:Stroke Order Project/Hangeul, Commons:Stroke Order Project/Katakana and Commons:Stroke Order Project/Bopomofo. We should come up with newer versions of these. I created {{Kanji progress entry}} when I set up the Commons:Stroke Order Project/Kanji progress page. We should probably come up with a template for the phonetic characters. --Swift (talk) 13:15, 22 January 2009 (UTC)


I've mentioned before the idea of using meta-data to better organise content. Currently, the naming conventions provides a protocol that allows the collection to act as a database. We are, however, unable to access any metadata that one might otherwise store in database columns.

I had the idea of creating pages with specific content that would act in a way as columns in a database, but I'm not sure if it's worth-while to pursue. To try it out, I've set up 一-j/nobarasha which is included on Commons:Stroke Order Project/Kanji progress/1 and it seems this isn't too expensive. I figured we could simplify the process of uploading and accessing information (Stroke order code for 一: 一-j/nobarasha).

It would stabilise the progress pages by separating the infomration away from the presentation. Let's suppose we want to update or use a different list. Currently that would be extremely problematic. Still, we don't know we'll ever want to update the lists, and in that event, a simple script should be able to run through the old list and add the details to the new one.

Furthermore, monitoring all these sub-pages would be both impractical and a royal pain.

As with a number of things I'm working on in relation to this project, I'm just wondering about this and don't think we should rush into anything. I'm largely just thinking out loud to clarify my ideas — both to myself and others who might be interested and able to bring something to this discussion (or just come across these pages and are confused about what on Earth I'm doing). --Swift (talk) 16:10, 31 January 2009 (UTC)

Actually, while it would be really cool to have this, if we need it we should just set up an off-Commons database. Creating thousands upon thousands of pages just to create a database look-a-like is a poor kludge at best. The information in these lists is salvageable so this is not irreversible. Retrieving the information from sub-pages, however, could be a pain. --Swift (talk) 14:03, 3 February 2009 (UTC)

...SO data side

I personnaly will not support this view. As you said, that will be a very royal pain. For special case of stroke order, I will more support to cre ation of a page such Commons:Chinese characters decomposition, and with the syntaxe:

汉 D-D-T-HP-N

A such page may be bot-create using :

汉 ⺡-⼜ ¹

together with:

⼜ HP-N ²
⺡ D-D-T ³

With 1. findable from : Commons:Chinese characters decomposition ; 2. findable in Kangxi radicals/1-99 (and /100-174 & /175-214), and 3 still needing creation 116 extensions)

An human made review should then check the full and correct complex cases. Yug (talk) 08:38, 4 February 2009 (UTC)

NB: Accordingly, I'm considering to divide the current /Kangxi_Radicals/pages (which currently contain both radical and variants such 水 & ⺡), this mixed list accuracy being is difficult to check, into 2 distinct pages, based on Unicode 116 (graphic elements) + 214 (true radicals) scheme. Any opposition ? Yug (talk) 09:37, 4 February 2009 (UTC)


Hi guys, I don't know how serious you are about this stroke collection, but in case you are interested, I would be happy to have people joining in on creating a database of stroke orders for all Chinese characters (Hanzi, Kanji...) based on the Unicode defined stroke set. I am currently setting up a project that offers access to a CJK-based set of functions still partially in need of more data. In the case of stroke orders I build on a list of stroke order information for base characters [1] that then are used for more complex characters following a set of rules and a table of decompositions into components [2]. The idea is that in an ideal world only those base characters need "annotation" which according to some sources are about 1000 characters. As you can see these tables are still kind of empty, so I would be happy for any help on filling them up using good sources. The code exists, it's the data and documentation that still needs some love. --Christoph Burgmer (talk) 15:50, 15 February 2009 (UTC)

Some points :
  • We are a group of volunteers, contributing for fun, this means that we can manage hundred specific small tasks, but rarely one BIG one ;
  • accordingly, we have not the power to manage/involve in a long-term project like your (unicode=44.000 characters if I' m correct) ;
  • for professionnal help, please see the "Link section" of en:Chinese_character_Description_Language. But most of these scholards or teams are working on their side, and 'wait and will' (when ? in 2445?) share their work. Stay that you can get helpful advice from them.
For your stroke order database, I'm a bit worry about the correctness of your database compare to 'official' stroke orders. You can take a look at user:Yug/Stroke order for an introduction. A specific page discuss about 'official national rules'. By example, I quick look let me see '"⺷",D-P-H-H-H-S,0,', a stroke order who don't exist, neither in China-taiwan ("⺷",D-P-H-H-S-H), neither in Japan ("⺷",D-P-H-S-H-H).
But if you want create a stroke databases (list of stroke contain in one character), then you are in the good way. And yes, according to the CDL (Chinese Description Language) team and documentation, a bunch of 1.000 radicals-characters are the core graphic elements of all 88.000(?) know characters.
Regards, --Yug (talk) 06:11, 20 February 2009 (UTC)
Hi, thanks for ping back and answer and sorry for the long delay.
cjklib tries to be as specific as possible about the characters involved and as several use cases should be supported no narrowing assumptions can or should be made. So, when it comese to stroke orders I believe the best way is not to say "this stroke order is wrong and this is right", but better rather say "this stroke order is not covered by the sources we adhere to" or "this stroke order is mentioned in one of the sources that we follow".
I know that the commons stroke order project has already invested some time in reviewing sources and adding data, so I would be happy if you could share this knowledge and make it available to a broader public. If this data then can be used by you in enhanced ways even better and maybe the only motivation for you.
So, while this project tries to focus on one stroke order per character which makes totally sense regarding the target use case, this would be fine with the library. It is just important that it is backed up by a solid source. I think creating a huge database only to later see that it is of limited use due to its unclear source status should be avoided.
So what can the library do? cjklib is targeted at all languages with Chinese characters, so in the future we can hopefully include enough data for all locale specific writings. Stroke order data is targeted at all base characters and characters where the stroke order can not be derived from its components (e.g. 圈,噩). All other entries will be constructed from the components' data. Using the stroke order, the more general stroke count can be derived. Searching for characters using stroke order can be supported (partially already implemented in the library) and it thus can also help by aiding stroke order annotation as e.g. useful for your project.
So, I don't know if you would be willing to contribute in this context and help me build up a database like that. You already have lists of stroke orders as I see. --Christoph Burgmer (talk) 14:12, 24 February 2009 (UTC)
This seems like an interesting project. Sorry if it isn't apparent from the responses so far, but the SOP contributors all share your concerns about the shortcomings of aggregating this information here on this wiki rather than in a database. I'm not sure how your library interfaces with a database, but might try to look into that later. --Swift (talk) 15:42, 26 February 2009 (UTC)
So right now it's all in the source file as text information? Right now I think it lacks a certain bit of modularity and therefore clarity. For instance, ""德","⿰彳⿱⿱十⺲⿱一心",0,0,O" vs. ""⾖","⿳一口⿱丷一",0,0,O". In the first one, the character composition is based on the whole kanji, then the upper part and then a bottom part? Yet, it's not clear how it is read. In the second example, the order seems reversed. It is composition of whole kanji, upper part, composition of bottom part, bottom parts. IMO it would be better to have a clear structure in that data. Also, I see that you can organize this differently on the database level, however, you're going to create this out of this data, so it's important to have a clear layout first. I don't want to put you down, just pointing it out. Maybe also instead of a text file a modular spreadsheat would work better. You could have fields like, "Kanji", "Overall Kanji composition" (these have a strict order for every composition, top down, left right etc.), "First sub-kanji composition", "Sub Parts first sub-kanji", "First sub-kanji composition", "Sub Parts second sub-kanji", etc. --Tauwasser (talk) 22:21, 26 February 2009 (UTC)
Thanks both for your answers. @Tauwasser, as you already dive into some of the problems of character decomposition, let me answer you more in detail. I have yet to set up a place on the project's wiki to explain that. I will use this answer here to formulate some of my thoughts.
On the data source: The table cjklib includes is uptil now very small. There are already very extensive tables out there but fail to address two demands of the project: 1) License, these lists are not LGPL, and I don't intend to change the project's license only so that those sources can be incorporated; 2) Detail, the lists I've seen so far don't decompose glyphs, but characters (e.g. only one decomposition included per character). That said it seems that the CHISE db seems to rather follow Kanji renderings, though being built on a source from Taiwan. Furthermore there are issues of what decompositions should be included, as these are only graphical not ethymological, and therefor many ambiguities exist.
Now, while the system underneath is somewhat finalised, the sources are not. The points you address are well reasoned and on the project's agenda yet to be covered.
In particular:
  • Decompositions follow the Unicode Ideographic Description Sequence rules.
    That is: a IDS operator is followed by 2 or 3 entries, either Chinese characters or IDSs again. So 說 can be described by ⿰言兌, or even extended to ⿰言⿱八兄 or ⿰言⿱八⿱口儿 by stacking Ideographic Description Sequences onto each other. There is some ambiguity as 說 can also be expressed as ⿰訁兌 (mark the different first character), so a future decomposition guideline should mention those cases and a good implementation should be able to handle both. You are correct in indicating the problem of having multiple orders how to stack together single components. There are other problematic cases like single strokes or ethymological variants without visual resemblance. In fact a guidline could regulate that. Uptil now they already abide to the stroke order rule: the component including the first stroke of the character comes first.
  • Character decomposition entries can and should be defined as simple as possible as it is the system's task to do the actual unfolding where appropriate. In fact 亘 provides more information as ⿻二日 does. The later may be the decomposition of two different characters. The example 德 you give is one character which is completly described by one IDS, only because currently I couldn't come up with a character for the right part side. If I understand you correctly you would like to have different views though all on the same data. In fact the component table includes all the information the system needs to know about the specific characters. Character 孰 for example has an entry ⿰享[1]丸 indicating that the left hand side character is a variant of 享. This character has then two entries with a difference in 子 vs. 孑 indicating the different last stroke. The system unfolding 孰 works through the database picking the exact subentries. So, different views on the data would be the task of software to generate.
I want to stress though that, while the design does not make precise demands on the data wrt to components right now, it does require correct stroke order. I didn't provide any documentation on the data organisation yet, so feel free to ask, your criticism is welcome. --Christoph Burgmer (talk) 11:01, 28 February 2009 (UTC)

Download a full cat

see Yug (talk) 08:17, 17 February 2009 (UTC)

Red and SVG : 214 rads under progress

->214 rad !e
(of 214+116)

Hello, My SVG project is under progression. I just finished the 80th radical. This is vissible on the fisrt image below: In -red.png, radicals already SVG-divided in several strokes (img. 1). I also had improved the shape of several stroke, to make the radical "stroke order friendly" (img. 2). I uploaded a PNG version. Other radicols will follow quickly I hope :]

That's encouraging ! Yug (talk) 16:22, 17 February 2009 (UTC)

Looking good! --Swift (talk) 04:37, 18 February 2009 (UTC)
So couldn't you upload a svg version so that people can copy and paste strokes? Or do they not match up with each other? What font are you using at the moment? --Tauwasser (talk) 11:12, 19 February 2009 (UTC)
That's just a 1st move. To upload finished -red versions, I will have to :
1. create separate files, with the correct names: that's an other later time consuming step ;
2. I just made a quick red gradiant coloration -> some stroke orders are wrong, I will have to check sources ;
3. I will also have to check for the Trad/Mod/Japanese divergeances ;
All this is planed, that's not the now-priority, but all this will come :] Yug (talk) 18:03, 19 February 2009 (UTC)
Hey, I just noticed that in File:⼌广-stroke_order.svg (middle in gallery above) the 及 is actually of the type on the left side, not the one on the right side. Maybe it's important or maybe it's just the wrong kanji or something ;) --Tauwasser (talk) 07:13, 23 February 2009 (UTC)
Damn & Shame on me ! I haven't deleted it ! yeap, you are right, this one should not be there. Moreover, it's a really special stroke order this 及, in opposition of the top then bottom 同-氣 rule. I have difficulties to understand where is the logic in this character stroke order compare to other close cases.
In short: yes, correction need ! --Yug (talk) 07:30, 23 February 2009 (UTC)

bw.png stroke order images in single tiles

I extracted single pieces, one character a tile, from the bw.png diagrams using automatic segmentation: Bw.png stroke order segmentation, some are missing, some might be incorrect, some don't have equal sizes. If you are interested, please help me fix those. --Christoph Burgmer (talk) 11:22, 4 March 2009 (UTC)

1000th most use (China)

This list seems to be a serious study, and first hand file. I looked at the 100 firsts, and yeap: this list have nothing 'odd', and seems trustable. (most lists spread on the web are corrupt, and have some odds lacks or adds. Some, by example, miss 5 character every 35 characters.)
So, this source have to be compare to /Chinese_progress (check not yet done)
The full (10.000 list), should be foundable on the web. Copy a section of this file, and google it.
If someone create a new list page with this simplified characters list, I can convert and make a traditional page version. Yug (talk) 05:41, 8 March 2009 (UTC)

How about the MTSU lists at --Swift (talk) 03:29, 25 March 2009 (UTC)

And this (download the exe -> 下載): Yug (talk) 23:56, 29 August 2009 (UTC)
Fonts : Songti ; Kaishu ; Xiaozhuan Yug (talk) 13:16, 30 August 2009 (UTC)

Proper Usage of Unicode Code Points for Radicals?

Please see Commons_talk:Stroke_Order_Project/Kangxi_radicals/1-99 for my comment on the use of proper unicode.

Basically, now you can find some KangXi Radicals by looking up common Ideographic Symbols, for instance 人(U+04EBA;CJKV Unified Ideograph) instead of ⼈(U+02F08; KangXi Radical Man) and so on. However, as you cannot type all of those (at least I think you cannot type the radicals in Chinese either?), it's really not at all usable imho?

Maybe we should come up with a proper solution for these? Also, I noticed that the pictures use the "wrong" glyphs mostly because people copy & paste the character in the list, so it might not represent the intended glyph for all those radicals (so far, it's really minor). I think we should use KangXi Radicals as of Unicode 5.0 as a guideline where-ever appropriate and then maybe disambiguate by having the Unified Ideograph in the license's additional description? --Tauwasser (talk) 01:13, 25 March 2009 (UTC)

Characters have different forms also.

Some might have noticed me adding the 教育部標準楷書 font in the font lists. This is because the older 漢鼎 one doesn't agree with the ROC MOE's stroke orders and character forms which one can see here. One example where the character forms differ is the 匕 character. The MOE write the first stroke as a horizontal stroke, while the 漢鼎 font writes it as a 撇. Please use the MOE's font for -torder.gif and such from now on.Asoer (talk) 14:17, 14 April 2009 (UTC)

Thanks for linking to a more authorative font. I haven't looked at the new font, and I suppose Tauwasser will be able to lend some insight into how it compares with the old one. Thanks also for the link to that site. I haven't had a good look, but it seems a nice compliment to the other traditional Chinese source we have. --Swift (talk) 21:28, 14 April 2009 (UTC)
Well the new font has about 6000 more glyphs than the old one, which should be nice. However, it has some really weird mappings for cyrillic characters (the glyphs are all different from cyrillic and are actually latin glyphs, even missing the "n" in the normal alphabetical order and having it at the end o.O").
I also noticed that the Macintosh Roman mappings are all entirely off by two code points, so glyph for "h" is mapped to codepoint "j"; however, this only covers roman characters anyway. However, since I use Windows, I don't know if this is a problem or not. Oh yeah, it contains Unicode mappings for Windows, unlike the old one, which was Big-5 (one of the ones I redid actually). So that seems like a definite improvement over the old one minus minor screw-ups =) --Tauwasser (talk) 02:14, 15 April 2009 (UTC)

About standard typefaces Korean Hanja

As you might know, there are many national standards for character forms: PRC, ROC, Hong Kong, Japan, and Korea. Vietnam doesn't have a standard. There is also a traditional standard, which follows the character forms found in the Kangxi dictionary. One can read about standards and typefaces in this thread. As the Korean character forms are mostly identical to the Kangxi standard, and their stroke orders are the same as Japan's (See Stroke Order per Polity), I suggest that we ditch making stroke orders for Korean Hanja and instead have the Kangxi standard in its place. An example of a character that already follows the Kangxi standard is 言-red.png. The PRC and Japanese standards have a dot on top which doesn't touch the horizontal stroke below. The ROC and Hong Kong standards have a dot that touches the horizontal stroke. Only the Korean and Kangxi standards have a horizontal stroke first. Also, the Hong Kong standard is, in my opinion, insignificant and too far removed from the traditional standard. Therefore, if you were to follow my suggestions, we would have four standards for character forms and stroke orders: PRC, ROC, Japan, Kangxi. Kangxi stroke orders are almost identical to the ROC stroke orders, with some exceptions, and sometimes the same character can have many stroke orders. Asoer (talk) 16:39, 16 April 2009 (UTC)

Taiwan's stroke order is not Imperial China's

Please read Taiwan's stroke order is not Imperial China's On Talk:Stroke order. Here is how I suggest how the stroke order project handles the changes. torder will stand for "Taiwan order." Rename all instances of "traditional" to "Taiwan." As for "simplified" stroke orders, we may rename them "China" or "Mainland" (but note that Hong Kong stroke orders differs from the mainland).Asoer (talk) 10:47, 9 May 2009 (UTC)

Umm... But there are distinctions between traditional and modern Chinese Hanzi, so I think we should keep that up and do it as we currently do Japanese:
  1. Create a Letter it for distinct stroke orders (that don't match modern nor traditional)
  2. Redirect to the right stroke order for the rest of those images.
I think that way, we would have a proper setup. Please no rash actions, we do have spare time to decide on how to deal with this. --Tauwasser (talk) 20:58, 9 May 2009 (UTC)
I don't quite understand, but I wasn't suggesting that we incorporate the traditional (calligraphic) stroke orders. At least not now. I was only suggesting that the Taiwan stroke orders be named/labelled as Taiwan stroke orders, so as not to imply that Taiwan stroke order matches traditional stroke order. I guess I'll take back the suggestion to rename "simplified" to "Mainland," but I don't think it makes much sense to have Traditional Chinese characters in the "simplified" group. Can this default group be named something else?Asoer (talk) 04:27, 10 May 2009 (UTC)
Oh, I understood you wrong. I just checked with the works and it seems that indeed Taiwanese sources are cited for traditional stroke order. Maybe we should have a different set-up, I agree. So maybe we really should rename it. Still, then we still don't have a proper solution for Hong Kong vs. Mainland China, though it seems Hong Kong order doesn't differ much.
Taiwanese stroke order Mainland Chinese stroke order Hong Kong stroke order Japanese stroke order Korean stroke order
same stroke order: 中-tbw.png should redirect to 中-bw.png (Mainland Chinese). 中-bw.png  ? namespace HK ? same stroke order: 中-jbw.png should redirect to 中-bw.png (Mainland Chinese). Own namespace; redirects for same glyphs; different glyphs get own file
same stroke order: 生-tbw.png should redirect to 生-bw.png (Mainland Chinese). 生-bw.png  ? namespace HK ? 生-jbw.png
伐-tbw.png 伐-bw.png  ? namespace HK ? same stroke order: 伐-jbw.png should redirect to 伐-bw.png (Mainland Chinese).
Quick mockup, what do you suggest for Hong Kong? I would suggest using *-hk*.* as namespace (like "中-hkred.png"). However, we would need an authoritative work to go by, like Ministry of Education publication, learning sites online etc. Simply using rules of thumb will probably lead to disaster.
Also, please see your roadmap page and the preparations for our new SOP license as well as the fonts page. We recently talked about all that and input is welcome :D I also see that coordinating our effort with so many sub-pages is a bit of a hassle! --Tauwasser (talk) 10:24, 10 May 2009 (UTC)
I don't see any problems with *-hk*.*. For Hong Kong, I think 香港標準字形及筆順 is a pretty good source until we can get a 香港教育署香港常用字字形表 for ourselves. Asoer (talk) 09:51, 11 May 2009 (UTC)
P.S. Hong Kong has its own character forms. The standardized fonts are usually called something like *香港標準楷書. I haven't found any free ones yet. Asoer (talk) 09:57, 11 May 2009 (UTC)
I find that the only good way of organizing characters is to separate them according to polity, but I also think that Traditional Chinese characters should not be in the Mainland group, as the PRC doesn't standardize Traditional glyphs. Therefore we would have...
  • a group for Mainland glyphs and stroke orders, containing only characters in the Simplified Chinese character set, like , , and with joined .
  • a group for Taiwan glyphs and stroke orders when they differ from the Mainland, like , , and with separated .
  • I don't think we should have a group for Hong Kong, but if we were to have one, it would contain glyphs and stroke orders that differ from the Mainland or Taiwan, like , with separated , with the sticking out on top of ,
  • a group for Japan glyphs and stroke orders when they differ from the Mainland or Taiwan (or Hong Kong), like , .
  • I don't think we should have a group for Korea, because I can't find a Korean standard 楷書 typeface, and they (should) follow the traditional (calligraphic) stroke order. If we did have a group, we should name it "Traditional" or "Calligraphic" and note that Korea follows this. It would also function as the default group (instead of Mainland as we have it now), so Mainland glyphs would redirect there when they match.
Therefore, the priority of redirection is (Traditional>)Mainland>Taiwan(>Hong Kong)>Japan(>Korea). Asoer (talk) 00:33, 14 May 2009 (UTC)
Ok, so hk flavor may not be needed, ckeck. I'm afraid I still know little of Chinese schools as I am mostly interested in Japanese ;) I don't know if sepearation by polity would be 100% correct, but as it is now all things are supposed to fall back to Mainland China where appropriate. Japanese so far hasn't had any fallback redirects to Taiwanese as far as I know. Still, redirects can work in any way as long as they're correct and when edited no two flavors are affected.
The thing with Korean glyphs is that many look "totally" different because their strokes go in different direction (cf. (zh-CN)vs. (ko)), so while stroke order can fall back to Chinese (and Taiwanese, possibly Japanese) stroke order, glyphs cannot necessarily!
The proposition of renaming traditional to Taiwanese is definitely right, so we'll put that up on the roadmap I guess. I don't know about HK flavor if it isn't really needed :/? On the other hand, categorizing these things is a pain and has to be done by script anyway (as Swift proposed on the SOP license page), so hk could be included anyway for completeness' sake. --Tauwasser (talk) 22:37, 14 May 2009 (UTC)

Eclectus, using your stroke order images

Hi, just wanted to tell you, that my newest project makes use of your stroke order images. I released Eclectus, a Chinese character dictionary, which integrates those images. You can see screenshots on Thanks a lot --Christoph Burgmer (talk) 14:13, 3 June 2009 (UTC)

First contribution to B&W series

Hi. I would like to contribute to this great project. My first one (already uploaded) is

See how I am using those images

--Yizhouan (talk) 11:52, 3 September 2009 (UTC)


While most of the SVG-images have transparent background, and many PNG have, none of the SO-GIF-images has (I found just one exception, File:叫-order.gif). My idea is, it would have been better if the GIFs had as well transparent backgrounds - or would this be any disadvantage?

If others agree to my opinion: could the background be changed by a BOT or by use of another program? -- Sarang (talk) 14:52, 8 October 2009 (UTC)

Animation Request

Next year at February 14 begins the "Year of the Tiger", due to the Chinese zodiac. Currently most of the 12 Chinese zodiac animals (the "Earthly Branches") are not yet available as animated stroke order GIF characters; see Category:EBrequest, where for the tiger File:虎-order.gif the request for animation exists since some months.

Please, would somebody who know how to do replace the temporary AR-picture for the character 虎 by the requested animated picture? Others are rabbit 兔-order.gif, dragon 龍-order.gif, snake 蛇-order.gif, for the years 2011 to 2013.

The Category:AnimationRequest, see the project page, has not yet found mercy, so currently the not-animated pictures are used instead of the requested animations. -- Sarang (talk) 16:16, 8 October 2009 (UTC)

Standard Lishu

I read somewhere on the Stroke Order Project that Lishu was to be recorded. I don't know if you're really planning on doing it, but this is just FYI. So far, only one region has standardized Lishu, and that is the ROC. Here is their standard free typeface: 教育部隸書字形檔. 02:03, 20 October 2009 (UTC)

Contribution traditional(ROC) stroke orders


I'm a little confused about how to contribute traditional stroke orders given the new redirection policy. There seems to be 2 cases that I'm likely to come accross:

  1. There is already a simplified image, and the ROC authoritive work 《常用國字標準字體筆順手冊》indicates that they are the same
  2. There is a simplified image, but the ROC stroke order is different to simplified.

Dealing with case 2 is quit simple, you simply upload a new image with 't' in the name. How, OTOH should the redirects for case 1 be set up?

Another issue is that there does not seem to be a progress/status page for traditional characters. Would there be any objections if I create one based on the simplified one?

--NeilenMarais (talk) 14:45, 8 November 2009 (UTC)

You would set up a redirect just like for any other page. Look at File:用-jred.png for instance. I made that page in anticipation of 用-red.png, which I will come around doing some day next week [or so :(].
#REDIRECT [[File:用-red.png]]
You can create the page just like any other page, you do not have to upload a picture to create it. --Tauwasser (talk) 23:51, 8 November 2009 (UTC)


eh, sorry I accidentally pressed submit... I just wanted to say that this is awesome, the detailed animations and such.. Good work :) -- 06:17, 25 November 2009 (UTC)

Some questions about contributing


I'm currently learning japanese, and kanji and I found this amazing project. I would really like to help with the japanese kanji (mainly because I'm learning it and don't want to confuse myself with other guidelines) but I have a few questions first. I am quite proficient with inkscape and The GIMP. Could I just add to this list: Commons:Stroke_Order_Project/Kanji_progress the kanji which are missing or is the a list of kanji in progress or to be created? I will be making the jbw.png images but I might also do red and animated ones if I can. Should I upload the files to the SVG project as well?

Thanks, --Durand (talk) 00:25, 28 January 2010 (UTC)

Hi, welcome to the Stroke Order Project. Sorry that I respond so late...
Anyway, user:Yug is currently doing SVG animations and is quite confident that he could create red png files from his animations. (also see Commons:WikiProject_CJK_stroke_order_(SVG) and the Roadmap)
For jbw, you can add pretty much everything that's still missing as the former creator has quit the project. However, it has been mentioned in several places that the current arrows are really lacking, because they're not coherent enough. So it might be good to have somebody with enough SVG skills to make a set of copy & paste arrows and use these for the images as well. --Tauwasser (talk) 08:48, 14 March 2010 (UTC)
Ok, I'll do that. Where can I find missing ones? Because it just seems that a lot of them aren't linked to the chinese version when they're identical and I have no idea how to link them. Sorry for replying so late but wikimedia commons only just told me about the edit. Durand (talk) 14:06, 11 August 2010 (UTC)

Setting up image redirects

How exactly are these supposed to work? I've set up a redirect from 川-bw.png to 川-bw.png, which works when you go directly to the page. However it doesn't not show the correct file on Commons:Stroke_Order_Project/Kanji_progress/1.

The changes will be shown on the progress page after the page is cached the next time. If you're really anxious, you can do a so-called en:nulledit. --Tauwasser (talk) 08:44, 14 March 2010 (UTC)
Commons:Stroke_Order_Project/Kanji_progress/1 has hardly any entries. Shouldn't many of these characters redirect? Mps12345 (talk) 11:36, 5 August 2010 (UTC)

Korean stroke order images

I have made some stroke order images for my own wiki @ . I'm wondering if they would be of any use here? They might not be in the exact form you like, but I thought it wouldn't hurt to ask.--Bluesoju (talk) 18:34, 12 February 2010 (UTC)

weblinks to the png files

when I know the character (e.g. 母), how can I link to the png file ( e.g. )?

So I could use the files from "Stoke Order Project" in Anki ( )

Other way would be to download the full Wikimedias category, but I couldn't find out how to use the Python script referenced above ( ).

Thanks!Clerambj (talk) 06:48, 18 February 2010 (UTC)

Your answer is : [[:media:母-bw.png]] -> media:母-bw.png.
You can thus make [[:media:母-bw.png|母]] ->
The script is used by Burgmer, and is include in Eclectus. You can download eclectus and find the python script somewhere inside, for download what Burgmer found just 3 months ago there: . Regards, Yug (talk) 17:44, 18 February 2010 (UTC)
Thanks for the fast answer, and sorry for giving my feedback so late. I wanted to try by myself a bit longer before bothering you again.
A link like [[:media:母-bw.png]] only works within the wiki. But I want to link from outside, so I need an adress like Is this possible?
I couldn't use Eclectus as I'm on Windows.
And what I downloaded from the link aren't the files like on the wiki. It's the single strokes, for each character. Not in one picture the whole explanation how to draw the character. Do you have another idea to solve my question?
Clerambj (talk) 17:57, 13 March 2010 (UTC)

Reporting of (possible) mistakes (1)

Hi, I don't know where to report mistakes (could also be MY mistake...), so I do it here.
When I compare following characters, the first stroke doesn't seem consistent to me. Are the stroke orders correct?
File:背-bw.png ✓ Done
File:北-bw.png - X incorrect
Clerambj (talk) 17:48, 13 March 2010 (UTC)
Indeed, 背 has the first two strokes switched. I'll see if I can add it to a todo-list somewhere. --Tauwasser (talk) 08:41, 14 March 2010 (UTC)
At least according to the ROC MOE, 背 is written correctly. Only 北 is written incorrectly. Asoer (talk) 03:45, 27 April 2010 (UTC)
File:背-bw.png - ✓ Done correct (>ROC)
File:北-bw.png - incorrect according to ROC. Very likely Japanese. Author being M4RC0.
Yug (talk) 10:52, 8 June 2010 (UTC)

Reporting of (possible) mistakes (2)

Hi, here what looks like another mistake, could you please double check these, they don't look consistent to me:
File:买-bw.png ✓ Done
File:卖-bw.png X incorect
File:读-bw.png ✓ Done
Regards Clerambj (talk) 07:12, 26 March 2010 (UTC)
卖 is not written correctly. Asoer (talk) 03:50, 27 April 2010 (UTC)

Reporting of (possible) mistakes (3)

✓ Done - 美-bw.png moved to 美-jbw.png. Comment: 美-bw.png to recreate.
Hi, here a mistake for the 美 character (inversion of 4th and 5th strokes):
Regards,Clerambj (talk) 06:24, 29 March 2010 (UTC)
The .png matches the Japanese standard. the .gif matches the PRC standard. It doesn't match the ROC or Hong Kong standards, not because of the stroke order but because of the typeface. Asoer (talk) 03:53, 27 April 2010 (UTC)

Reporting of (possible) mistakes (4)

✓ Done Yug (talk) 11:20, 12 August 2010 (UTC)
In 所, the long vertical stroke on the left is drawn too late in the -bw file:
Regards, Clerambj (talk) 14:11, 29 March 2010 (UTC)
The .png matches the Japanese standard in stroke order but not in typeface (The Japanese standard has 戸 on the left). The .gif matches PRC, ROC, and Hong Kong standards. Asoer (talk) 03:56, 27 April 2010 (UTC)

Resized animations

Could one of u guys find the unresized versions of those two characters: File:240px-Animation1-Sino-0E90B00AF-order-gif.gif & File:240px-Animation2-Sino-0E50BO091-order-gif.gif cheers --DieBuche (talk) 21:46, 13 May 2010 (UTC)

Doesn't seem like it originated in this project, so we don't have any other animated versions of these characters. We have a red version of 鰯 and a red version of 少, though. The corresponding animations would be animation of 鰯 and animation of 少. --Tauwasser (talk) 14:37, 14 May 2010 (UTC)
In my opinion, this 2 files should be deleted, they are not up to our standard. Yug (talk) 10:49, 8 June 2010 (UTC)

Request renaming rights

Asoer, Tauwasser, look at this page:

That's the page to request move-file rights :D Yug (talk) 12:15, 5 June 2010 (UTC)

Alternative method for showing stroke order


I developed a new method for showing stroke order and thought you guys could be interested. Details here: Comments welcome! Dragice (talk) 13:57, 22 June 2010 (UTC)

As a computer lover : I love your approach ! ^0^y
As an human student, I don't like it ;(
But this is clearly interesting for its concision ! and space save :D I keep it.
PS: May I make a screenshot of your webpage with the Comparisons of diagrams , and put it on Commons under free license. Best: add a free license label to your webpage.
Cheer, Yug (talk) 12:14, 12 August 2010 (UTC)
Thanks Yug! You are welcome to take screenshots of my webpage. The license is CC-BY-SA, displayed at the bottom of the page. Dragice (talk) 15:35, 5 November 2010 (UTC)
Let's say you're notating 華 in the ROC standard, where there are strokes that are the same shape and elevation. How would you do it clearly? Asoer (talk) 14:54, 5 December 2010 (UTC)
It would look like this. You can see many other examples here. Dragice (talk) 22:34, 19 January 2011 (UTC)

Zhuyin Fuhao stroke order

As I was commenting on [en.wikipedia:Bopomofo], 常用國字標準字體筆順學習網 of the Ministry of Education of Taiwan lists both File:ㄖ-bw.png File:ㄓ-bw.png as having 4 strokes first, and 3 strokes as variants (though it might not imply a preference of one over the other).

I personally feel that 4 strokes are more consistent with Hanzi writing rules in 常用國字標準字體筆順手冊, but I'm not sure whether it applies to Zhuyin Fuhao, or which usages are actually more common in Taiwan.

Can 常用國字標準字體筆順學習網 be considered an authoritative source?

What happens when a source lists 2 stroke orders and says they are both acceptable?

I notice that both symbols had 4 strokes in their history, can the 3 strokes variants be separated out and marked as alternatives? Juxtap (talk) 10:42, 9 July 2010 (UTC)

There are differences between characters 日 and letter ㄖ. From what I know, letter are on purpose reduced to less strokes, and yes : in opposition to Stroke order rules applied to characters. That what my books teach me, I was surprised too, but that confirm by most books I watched, and that make sense (to write letters faster).
I don't know if the 常用國字標準字體筆順學習網 is authoritative. Or maybe its a recent move, as they recently changed the official Pinyin in Taiwan.
Conclusion: I have no clear answer, just hypothesis. I'm willing to keep the previous usage: ㄖ is 3 strokes. Yug (talk) 11:41, 12 August 2010 (UTC)

Helping with svg stroke order

Hi, I'd like to help with the svg stroke order project. I was told to post here about two months ago but wikimedia only just emailed me. Thanks

Durand (talk) 14:03, 11 August 2010 (UTC)

Hello, please see user talk:Yug, or email to CFDICT at/@ gmail . I made some progress (almost finished the 214 radicals in en:Kaishu style), but some new websites are more professional, advanced, and are starting to provide free SVG with stroke-by-stroke construction in en:Mingti style. So... My SVG project is in stand by, I'm not willing to add confusion.
What is your project ? you have programmation skills ? --Yug (talk) 12:00, 12 August 2010 (UTC)
I was thinking of helping convert more of the kanji bw strokes to svg, I did 2 of them a while ago but I'm not sure if there is any point:山-bw.svg That's one I made. I can programme in python and I know HTML and a little js.

Durand (talk) 23:50, 18 August 2010 (UTC)

Starting new name type

I'm going to start using the letter "i" for traditional stroke orders. For example, -ibw.png, -ired.png, -iorder.gif. I choose to use "i" after the en:ISO 15924 code "Hani" which stands for Han characters throughout the Sinosphere. Asoer (talk) 12:38, 5 December 2010 (UTC)

Here is the first image.


I just need to find out how to work the SOlicense template to recognize the i-names. Asoer (talk) 13:22, 5 December 2010 (UTC)
Or somebody can do it for me. That would be awesome. Asoer (talk) 00:36, 7 December 2010 (UTC)
I think I've taken care of it. Here are some more i-images.


(Note that in 曰, the difference is not stroke order but form. First and second stroke do not touch.
Asoer (talk) 15:28, 7 December 2010 (UTC)
I think you misinterpreted the intention of the Hani script tag. or script tags in general. Script tags are supposed to give some control over which font text is rendered with.
Hani stands for Han ideographs in any form. Hant is the specific tag for traditional form, while Hans is the script tag for simplified form. Hani does not make any claims that Hani glyphs are the same throughout the Sinosphere, like you interpreted it to be.
Basically, Hani is supposed to be used for scripts that use some form of Han ideographs (and the tagged part only consists of ideographs), but no special preference is given for any font face. Thus, you might end up with Chinese text that uses different fonts for some characters and therefore looks somewhat odd, because it switched back and forth between different stroke weights and styles.
For instance, since Japanese does not follow the simplifications used in China, you might tag ideographs in Japanese text with ja-Hani, thus enabling software to choose any font that claims to support Japanese and has glyphs for these ideographs, even if they don't feature a kana set. However, you will have a hard time finding a Japanese font that features explicitly Japanese kanji but not kana.
For mixed scripts in Japanese, Jpan is supposed to be used (but it's a suppress script entry, so for all text tagged only ja, ja-Jpan is implicitly used). The same goes for Korean Hanja and script tag Kore for mixed script (Hengeul + Hanja). Hant and Hans are used for simplified and traditional forms explicitly. Hant may be used for highlighting old forms, e.g. in Japanese or Korean. For instance, you might want to use {{lang|ja-Hant|}} instead of {{lang|ja-Hans|}} in 南総里見八犬伝 to make sure 總 is rendered with a Japanese font (thus, with matching stroke weights and style) that claims to feature traditional Japanese variants if available. Since no browser yet supports these differences ― partly because not many fonts support this type of compatibility checking ― it's partly a moot point. I made a little example screenshot here. Please note that a font not containing certain ideographs is a very real possibility for CJKV Extension C and onwards.
Since these are script tags, and can be mixed and matched, they don't really lend themselves well to this project, since we choose to implement a different system from the get-go, namely by stroke order and fallback to simplified Chinese, only respecting modern-day usage. Thus, we're actually only using "zh-Hans", "zh-Hant", "ja-Hans" and "ko-Hans", where all fall back to the "zh-Hans" version if stroke order and glyph match. --Tauwasser (talk) 12:50, 19 December 2010 (UTC)
Thanks for the info. I didn't really intend to really connect this project with script tags (but if it happens, there's no modern typeface that matches traditional 楷書, so it would look messed up anyway). I just got the idea from the script tag to use the letter "i". It could have been any letter, but I needed to use one. Asoer (talk) 22:41, 19 December 2010 (UTC)

Getting updates automatically?


first, let me say that your work is awesome! I have been searching the web for several days now and have not found anything comparable to the quality of your efforts.

Obviously, the work is not yet complete (especially on the animated characters). Is there some easy way to get an update when a new animation has been uploaded / finished? I am interested in the animated kanji stroke order GIFs.

Best regards, Andreas

There is a way,
Most stroke order are similar. But if there is a torder (Chinese traditional) or Jorder (Japanese) version, you should use these torder or Jorder. PS: if you make a website thanks to tell us, we will be happy to notice our work is used and enjoyed ! ;) Yug (talk) 13:58, 1 March 2011 (UTC)

Download and use of the stroke order images

Hello I am working to learn Chinese, and to teach it to my kids as well (all of us are American-English speakers). While the speaking/listening is more important in mind, the kids view writing the characters as more fun, and now I'm planning to incorporate characters into our routine. I was searching the web for a stroke order font to use in our studies, and found this site. The images here are excellent - Congratulations on a very useful set of images. I would definitely like to use them in our studies. I am able to download the larger images on at a time, but even after searching the Village Pump, I have not been able to find a way to get the whole set of files without lots of tedium or without stopping my Chinese learning to go learn to be a programmer. Can any offer help or guidance suitable for a newbie? Maybe there's a tool on Wikimedia web site....some existing already-compiled program for Windows XP I can use....or something else I'm missing to make the set of files useful? LearnMandarin (talk) 04:38, 11 November 2010 (UTC)

Hello, we asked for such feature some times ago, I don't know its status now. Does anyone know ? Yug (talk) 14:13, 1 March 2011 (UTC)
If you are interested, I created a small PHP script that download all the stroke animations. Currently it's set to download only the black & white ones but you can easily change it to download the other images too. You can get the script there: User:WikiLaurent/ScrapCCAnimScript. Laurent (talk) 04:44, 10 April 2011 (UTC)
For those who are interested, I just updated the script so that you can download either the B&W, red or animated GIF animations. I've added the documentation and some examples. Still available at the same address - User:WikiLaurent/ScrapCCAnimScript. Laurent (talk) 06:16, 10 April 2011 (UTC)
Wooow ! Thanks a lot Laurent : ] Yug (talk) 11:52, 16 April 2011 (UTC)
You're welcome :) I've also started working on a tool to make it easy to create character stroke animations. I'll post the URL here when it's done. Actually is this project still active? It seems new animations haven't been created in a while? Laurent (talk) 17:02, 16 April 2011 (UTC)
Thanks. Script was saving files with their original filename e.g %E6%88%91-order.gif which is not very useful for me. I'd rather they're saved as 我-order.gif same as downloading manually using a browser. My scripting knowledge is really sketchy now, and I've never really worked with PHP, but here's what I did to make it work for me. Replace line 101 with the following
$alt = $img->getAttribute("alt");
if ($type == "bw") $filename = substr($alt, 1) . "-bw" . ".gif";
if ($type == "red") $filename = substr($alt, 1) . "-red" . ".png";
if ($type == "order") $filename = substr($alt, 1) . "-order" . ".png";
For some reason, the alt attribute was returning 我? instead of 我-order.gif hence the need for separate if statements.

Free fonts

Hello, I don't know exactly where to put this, so I put it there.

Yug 11:30, 29 April 2011 (UTC)

Multi-color instead of shades of red

I'm new to wikipedia editing and discussing so excuse me if I don't follow the rules as I don't know them well.

And I also realize that as there are already 200+ han characters made in shades of red, those who worked on that won't be too happy to hear it, but it's just an idea.

My proposal is that instead of using shades of red which can get confused especially if the character has more than, say, six strokes, we used easily distinguishable colors, like the ones of the rainbow for example. ( purple, blue, green, yellow, orange, red ) When there are more than 6 strokes, 2 or 3 shades of each color can be used.

I'll link to one example to illustrate my idea.

Let me know if this has already been proposed and discarded.

Petruza (talk) 21:31, 20 May 2011 (UTC)

Some users already started to contribute that way. But some clear rule are still need ;) Yug (talk) 20:01, 2 June 2011 (UTC)
I would have preferred green instead of red, as green is most visible to the human eye, and so orders can still be discernible where they are not using red. I don't like using a rainbow because it cycles. I'd much prefer shading among a few colors. However, this might be more difficult to do and make it more difficult to contribute. Asoer (talk) 18:00, 15 September 2011 (UTC)

Redirect system

In the current redirect system the plain file names (red.png, bw.png, order.gif) is the PRC standard. Where the Japanese and ROC standards are the same, this redirects to the plain file name. However, this causes non-Simplified characters to be in this category. I don't think it makes much sense. It would be more beneficial to the users if the categories were separated more clearly, e.g.

  • One category for characters that are the same stroke order and form universally
  • One category for Japanese-specific orders and shapes
  • One category for ROC-specific orders and shapes
  • One category for PRC-specific orders and shapes
  • (One for Hong Kong-specific orders and shapes)
  • Redirects are in place prioritizing in the order of the list.

Why is this simpler? Because the list of categories above goes from the proposed default (traditional stroke orders and character forms) to the one with the most exceptions (PRC Simplified Chinese). This is also more organized because the default category would naturally contain the most files and doesn't imply that they're standardized anyway, while the other categories would contain redirects and exceptions. The following are example scenarios.

  • A file 靑-red.png shows the traditional stroke order of 靑, i.e. 一 一 丨 一 丨 ┐ 丨 一. This is not standardized anywhere, so none of the other categories have it. (The current system would imply that it's standard in the PRC.)
  • A file 乃-red.png shows the traditional stroke order of 乃 and everybody but the PRC standard (Let's say it's called 乃-sred.png) redirects there.
  • A file 成-red.png shows the traditional stroke order of 成. The Japanese standard matches it, so that redirects to the default. ROC uses 一丿㇆㇂丶丿, so it gets its own file. PRC uses 一 丿 ㇆ ㇂ 丿 丶, so it gets its own file.
  • A file 青-red.png shows the traditional stroke order of 青, i.e. 一 一 丨 一 丨 ┐ 一 一. This is standard in the PRC, so that redirects to the plain file name. The Japanese standard uses a different stroke order, so it gets its own file 青-jred.png. The ROC standard uses a different form, with 丿 at the bottom, i.e. like this, so this is its own file.

Doing this mostly requires renaming. I don't know if there is a tool one can use to rename many files at once, but if there is, I'll be willing to do it, as well as rewrite the guides on this project. Asoer (talk) 01:04, 16 September 2011 (UTC)

So if I had all jbw/jorder/jred images on my wiki, they would redirect to the base ones if there wasn't a specific Japanese stroke order, right? That's what I want to happen, I hate having to filter through every kanji to find which ones have a specific Japanese ordering. I don't know if the current system is supposed to do this or not, but for every kanji article I have, that doesn't seem to be the case and I have to use bw/order/red PRC ones specifically for an image to show up. Anyway, I've never contributed to this project before, but I'd be willing to help you with renaming/redirecting for this new system or whatever.
Maybe it could be like:
  • bw/order/red = Universal characters
  • jbw/jorder/jred = Japanese characters (redirect to universal if they're the same)
  • rbw/rorder/rred = ROC specific orders (redirect to universal if they're the same)
  • pbw/porder/pred = PRC specific orders (redirect to universal if they're the same)
  • hbw/horder/hred = Hong Kong specific orders (redirect to universal if they're the same)
Is something like that the system you're proposing? Tell me what you want and I'll start renaming and redirecting stuff. -- XellKhaar (talk) 23:28, 18 September 2011 (UTC)
Sorry I took so long to get back to you. That is exactly right. Only to clarify: when, for example, ROC matches Japan, then it redirects to Japan instead of universal. Thanks a billion for offering to rename and redirect stuff. I'm super busy but I'd like to be able to help, given instructions and permission. Asoer (talk) 06:35, 9 November 2011 (UTC)

Beginner question on redirects...

I have been scouring Wikipedia and the pages of this project for an hour trying to find out how I actually redirect an image. Most sensible routes tell me I need to upload something. The only way I've found around this is to type the name of the image I want to 'create' into the address bar, and that's really annoying to have to do. I must be missing something. For the sake of my sanity, can someone please help? (Or better yet, create or link to a simple "how to" page - you might find there are lots of people willing to contribute but who simply don't know how and get discouraged before they've even started!)

On another note, why has no one put in the hundreds of obvious redirects for Japanese yet? For example, in the b/w series, 一 and 七 have been redirected to the Chinese images, but 二, 三, 四, 五, 六, 八, 九, 十 have been left blank. Am I missing something? Bluepie88 (talk) 04:25, 25 September 2011 (UTC)

If a specific Japanese image does not exist, that usually mean the Chinese image is working for it (same order). We don't upload ALL, we use if (japanese image not existing) then (use the Chinese image). We are now moving to an if (japanese image not existing) then (use the universal image). Yug (talk) 21:41, 1 October 2011 (UTC)

What font was used for the red and white images?

Does anybody know what was used to create this image? I know it's not the open source "AR PL UKai CN" because the 起 qlyph on it is wrong. Does anybody know? I'd really like to find that font to create more animations. Laurent (talk) 18:46, 3 October 2011 (UTC)

I believe that was DFKai-SB, included with Windows 7. I edited the last stroke in Adobe Illustrator. Asoer (talk) 06:41, 9 November 2011 (UTC)
Hmm... so it's not an open source font? I'm wondering if we are not violating some Microsoft license with these images? Laurent (talk) 10:14, 1 December 2011 (UTC)

Please review new stroke animations


I'm making an app for the Playbook, where I will try to teach the 100 most common characters. I have a different most common list than you guys, so I have drawn a few new stroke order animations. I am still learning though, so there might be mistakes. Here they are.

Before releasing this under and open license, have you checked that the font you're using is also open source? If not, releasing glyphs, even if animated, is most likely a violation of the font's license. Laurent (talk) 11:20, 20 December 2011 (UTC)
Most are clearly PRC complient. A small doubt with 成. Please share your list of 100 charactères so the wikiversity may create a course on this basis. PS: Very good work ! Yug (talk) 09:22, 13 February 2012 (UTC)
Laurent, the font file may be copyrighted, the output is not, otherwise ALL printed texts using a copyrighted font should pay copyrights fees or be considered as breaking the law, a non sense. Yug (talk) 09:23, 13 February 2012 (UTC)

Duplicate Categories?

Hello! Please see this discussion topic: category_talk:Chinese_stroke_order_in_animated_GIF#Duplicate_Categories.3F

I'd appreciate any clarification! :) (P.S. I wasn't sure where to post this, so I've just posted a link here. I do appreciate the irony in my duplicate post, though.) ;) Pixor (talk) 18:56, 28 May 2012 (UTC)

2012 Summer check point : Order.gif

A (21 C, 1 P, 489 F)

  • 4 elegant *-order.gif illustrtions missing
  • 55, 70, 174, 201

Yug (talk) 13:27, 21 August 2012 (UTC)

Removing "needs converting to SVG" notices?

Hi. I recently added a {{Vva}} template to File:水-bigseal.gif, but the problem is that the Descriptions of e.g. File:水-seal.svg and File:水-bigseal.svg still stipulate that File:水-bigseal.gif needs converting to SVG. How do I remove its listing from that file Description, so that people don't think that that task is yet to be done? It Is Me Here t / c 14:25, 9 November 2012 (UTC)

Arphic Public Licence and a font compatible with GIMP

Hi there,

I've recently started contributing to the Chinese stroke order project. For my contributions, I've been using the font AR PL UKai, which is licensed under the Arphic Public Licence. The Template:SOlicense, though, publishes all images using the template under the GFDL -- would this cause any problems?

I'm aware that the recommended font for PRC glyphs is 汉鼎简楷体 (HDZB_36.TTF), but I'm unable to use it as I use GIMP, which does not support non-Unicode fonts. The link to User:Tauwasser's remapped version has expired with closure of I'd rather stay with using GIMP, if it's possible.

My question: would it be acceptable to continue using AR PL UKai? If not (and in that case, I'd like to replace my already-uploaded files as soon as possible), then are there any other alternatives to HDZB_36.TTF? It would, of course, be much appreciated if somebody who still has a copy of Tauwasser's remapped version could upload it to another location.

Thanks in advance for your time. I look forward to contributing more to this project. Dewclouds (talk) 07:39, 15 April 2013 (UTC)

Someone seems to like your work

FYI: Someone has left a "thank you"-message for your Project at the help desk (permalink)- Cheers, --El Grafo (talk) 14:08, 9 September 2013 (UTC)

How is character redirection supposed to work?

Many simplified Chinese stroke order bitmaps that used to exist (like file:北-bw.png) don't exist now. They have been moved and now use the Japanese naming convention (like file:北-jbw.png).

If I want to locate the simplified Chinese stroke order for a given character, e.g. 北, it seems I have to:

  • Go to file:北-bw.png.
  • Note that it was renamed to file:北-jbw.png.
  • Check the history at file:北-jbw.png to see if the stroke order has changed since the file was moved.
  • If it has, poke around in the history some more to see if the new order reflects the Chinese or only the Japanese.

Additionally, this change seems to have broken the progress pages. Note that many characters which were done are shown as not done.

I'm sure I'm missing the point and this is not what was envisaged. How is this supposed to work? 16:14, 25 October 2013 (UTC)

Encouraging Message


Well, anyway, congrats, good work, etc.

As a general proposition I'm in favour of more an more audio wherever possible: one of the things I want most is to improve my Chinese speaking voice, so every opportunity for improvement beckons.



David Lloyd-Jones (talk) 19:00, 8 January 2014 (UTC)

Slow SVG project, some news

->214 rad !e
(of 214+116)

214 characters broken in respective stroke : done.

Stay: 2. order them in the correct order ; name each stroke ; create a square under each radical ; create an launch scripts.

Under progress

Timestamp for archive -FASTILY 05:12, 5 June 2014 (UTC)

As 卐 is a Chinese character, could an animation for it be made? Many stroke order animation sites do not seem to accept that it is a Chinese character. WikiWinters (talk) 00:54, 15 December 2014 (UTC)

I bet it's not. Please see en:Swastika --Zhuyifei1999 (talk) 10:11, 15 December 2014 (UTC)
I saw it, and it says it's rendered in electronic documents as a Chinese character. Also, see zh:卐. WikiWinters (talk) 13:18, 15 December 2014 (UTC) WikiWinters (talk) 20:20, 15 December 2014 (UTC)

々 (iteration mark)

Is this symbol in the scope of this project? --4th-otaku (talk) 07:20, 12 February 2015 (UTC)


The stroke order is wrong. Suzukaze-c (talk) 18:27, 7 July 2015 (UTC)

According to the ROC standard, the stroke order is correct, but according to the HK standard, it's not correct. Justinrleung (talk) 04:50, 9 July 2015 (UTC)
@Suzukaze-c: Justinrleung (talk) 08:32, 4 September 2015 (UTC)