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.
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)
Redirects
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.
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
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)
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.
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:
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)
cjklib
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)
Hello,
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.
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)
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 :]
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 ;
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.
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)
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:
Create a Letter it for distinct stroke orders (that don't match modern nor traditional)
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).
? 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).
? namespace HK ?
? 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.
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)
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?
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.
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: 教育部隸書字形檔. 174.23.213.25302:03, 20 October 2009 (UTC)
Contribution traditional(ROC) stroke orders
Hi,
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:
There is already a simplified image, and the ROC authoritive work 《常用國字標準字體筆順手冊》indicates that they are the same
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?
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 :(].
eh, sorry I accidentally pressed submit...
I just wanted to say that this is awesome, the detailed animations and such.. Good work :) -- 203.171.195.14606:17, 25 November 2009 (UTC)
Some questions about contributing
Hi,
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?
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 to , 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.
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 http://upload.wikimedia.org/.... 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?
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)
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)
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.
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)
As I was commenting on [en.wikipedia:Bopomofo], 常用國字標準字體筆順學習網 of the Ministry of Education of Taiwan lists both File:ㄖ-bw.pngFile:ㄓ-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
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.
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: http://commons.wikimedia.org/wiki/File:山-bw.svg That's one I made. I can programme in python and I know HTML and a little js.
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)
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?
Hello,
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.
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)
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)
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
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.
Prof. Wang published a serie of GPL free fonts: http://www.unifont.org/fontguide/ (Citation: "Dr. Hann-Tzong Wang (王漢宗教授) has released a number of traditional Chinese fonts to the open source community under the GPL." )
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.
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)
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)
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
Hi.
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)
实 ok
主 ok
些 ok
从 ok
但 ok
分 ok
动 ok
发 ok
同 ok
后 ok
开 ok
当 ok
成 TO CHECK (should be ok)
样 ok
法 ok
然 ok
现 ok
理 ok
着 ok
种 ok
经 ok
起 ok
进 ('walk' rad 3 strokes = PRC)
还 ('walk' rad 3 strokes = PRC)
部 ('place' rad 2 strokes = PRC)
都 ('place' rad 2 strokes = PRC)
实 (displayed twice)
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)
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)
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 drop.io. 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.
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:
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.
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)
@Justinrleung: I meant that's a good criterion to work on, but I do not know how to compare both dabases, namely HSK vocabulary and characters with a strokes gift, could you do it please?. Secondly, at least I can do mere 'mechanical, manual' work because I do not have much time to study new processes. --Backinstadiums (talk) 19:43, 18 November 2017 (UTC)
@Backinstadiums: Sorry for misunderstanding. There's a list based on some simplified Chinese standard, but not HSK. I hope that would do, since I think all of the HSK characters should be in that list. (BTW, it's gif, not gift.) Justinrleung (talk) 21:18, 18 November 2017 (UTC)
The article Wikipedia:Citing Wikipedia clearly states that 'You should not cite any particular author or authors'. So I think that this section is wrong:
You only have to state the: [...] authors: Mostly M4RC0 for -bw.png; Muke and Yug for -red.png; Wikic and Micheletb for -order.gif.
It should instead be put as a recommendation or as a petition, not as part of the license terms, incompatible with those of wikipedia.
The template need a revamp. As of 2018, and given I made far less images than expected, I'am more than willing to release fully my copyrith for a PD license. Wikic, M4rc0, Micheletb made impressive works tho, so need to see with them. --Yug(talk)19:12, 18 January 2018 (UTC)
@Justinrleung: I meant that's a good criterion to work on, but I do not know how to compare both dabases, namely HSK vocabulary and characters with a strokes gift, could you do it please?. Secondly, at least I can do mere 'mechanical, manual' work because I do not have much time to study new processes. --Backinstadiums (talk) 19:43, 18 November 2017 (UTC)
@Backinstadiums: Sorry for misunderstanding. There's a list based on some simplified Chinese standard, but not HSK. I hope that would do, since I think all of the HSK characters should be in that list. (BTW, it's gif, not gift.) Justinrleung (talk) 21:18, 18 November 2017 (UTC)
It would be great to find a dabase/list of characters whose stroke order is different from the one to be expected according to the standard guidelines 现代汉语通用字笔顺规范.
Eventually, the characters that do not follow the standard guidelines should be arranged into groups according to the "type of irregularity", which would be very useful both for lexicographic and learning purposes.
Maybe the info. necessary can be gathered form new input methods' lists of sequences as well as from stroke order gifs. Then it would be manually checked. --Backinstadiums (talk) 12:49, 30 November 2017 (UTC)
Ok. The License is not stated and the creator seems anonymous and inactive since 2016. The strokes.sql file is from unknown source. Potential copyright kicks in. What one can do is to
Hack this NodeJS program (see todo, but in larger than 300px)
Runs it to generate 1766 {characters}-red.svg
Use imagemagick convert (resize, pad) to convert back to png and 300px via $magick convert roseFlower.svg -resize 50% roseFlower.png
Mass upload to commons
The shape themselves being Kaishu shapes from 2000 years ago, they are under PD license. The data (sql converted into xml) is, potentially, under copyright so no svg can be uploaded. Yug(talk)20:11, 18 January 2018 (UTC)
Failed. I hacked it but a strokes.db database is missing while the strokes.sql files doesn't work. I don't find any conversion process
New avenue :
[works] remove grid sed -i 's/<path d="M 0 0 L 270 270 M 270 0 L 0 270 M 135 0 L 135 270 M 0 135 L 270 135" stroke="#CCCCCC" \/>//g' ./test2/*.
Back tracking !!!! While done, I still have some doubt about the copyright of this upper method since I now simply convert existing colored SVG characters. While miroring our reds gradiants, this coloring are resulting from the developer's program and choices, so while characters shapes are PD, the red gradients within the repository may be copyrighted. I don't think such copyright is really defensible in court... but could be, and some commonist may one day request deletion on this basis which would be simply annoying.
I tried to find out the author, and the datasource, but couldn't.
... (wind blowing dry dust in the desert, bush rolling across the path)
Given a folder with relevant red style svgs with unknown dimensions.
mkdir-p./temp./png# create folders to work on copies of data and store final png output
cp./*./temp# copies svgs to ./temp, so to word on copies
sed-i's/<path d="M 0 0 L 270 270 M 270 0 L 0 270 M 135 0 L 135 270 M 0 135 L 270 135" stroke="#CCCCCC" \/>//g'./temp/*# delete background cross in all files in ./temp (depending on your svgs!) forfilein./temp/*.svg# loop on the [edited] copies in ./tempdokeyZi=$(basename"$file".svg)# name of the file minus .svg keyRed=$(basename"$file".svg)-red.png# name of the file minus .svg, plus .-red.svg convert-backgroundnone-density1200./temp/($keyZi).svg-resize300x300\!./png/$keyRed# /!\ not sure for the brakets syntax in ($keyZi)done
There are actually three different stroke order schemes for Chinese-speaking locales. See https://www.visualmandarin.com/... for Mainland China's 8-stroke character
I don't know what the official HK source would be, but Eon Media Ltd. is from HK, and their standalone eStroke app has three national stroke order settings among its options and promises to "Show[s] accepted Stroke Order in Hong Kong, China and Taiwan". Perhaps it makes sense to contact them and ask where they have their data from. Love —LiliCharlie (talk) 17:23, 22 September 2020 (UTC)
I don't know what this discussion about sources is about, but I checked the canonical sources listed under "Source" in the summary box. The character depicted is either the simplified PRC version or the Japanese version (I probably shouldn't have mentioned Taiwan), but the stroke order is only appropriate for the latter. The problem is that it gets included on the Wiktionary page wikt:垂 under "Translingual" without specifying this, whereas on pages for other characters it is specified where they differ. Looking at the naming conventions, it seems like this particular gif should be renamed to 垂-jorder.gif. --NoInkling (talk) 23:13, 15 October 2020 (UTC)
Yes, the problem is with the English Wiktionary and any (Wikimedia or other) project that relies on the correctness of our graphics. — As to sources: For CN, TW, and HK stroke orders we use those prescribed by the respective Ministry of Education (MOE), but Japan's Ministry of Education, Culture, Sports, Science and Technology (MEXT) doesn't seem to prescribe a fixed order any longer. en:Stroke order#Stroke order per polity says they only stipulate that stroke order should "follow commonsensical orders which are widely accepted in the society". — Also note that that article distinguishes between traditional (=calligraphic) and Taiwanese stroke order. Love —LiliCharlie (talk) 01:00, 16 October 2020 (UTC)
Is there a stroke "count" instead of stroke order? For example, 气 = 4 stroke counts. -- Rolandlai
Yes, such data is well known and accessible online, most notably by Unicode's UNIHAN data, which contains that and many other data. You have python, nodejs, npm packages which as language-specific versions of UNIHAN. So we do not focus on this aspect. Unihan has kTotalStrokes, by example. See 我:
cjkUnihanqueryon我:{character:'我',SUnicode:'62.3',kIRGKangXi:'0412.010',kRSKangXi:'62.3',kIRG_GSource:'G0-4E52',kHanYu:'21401.020',kHanyuPinyin:'21401.020:wǒ',kIRGHanyuDaZidian:'21401.020',kIRG_TSource:'T1-4A3C',kTotalStrokes:'7',kMandarin:'wǒ',kIRG_KPSource:'KP0-F7A5',kMorohashi:'11545',kKangXi:'0412.010',kDefinition:'our, us, i, me, my, we',kCantonese:'ngo5',kCCCII:'213F64',kSBGY:'304.26',kKPS1:'',kIRGDaiKanwaZiten:'11545',kIRG_KSource:'K0-6432',kCangjie:'HQI',kCNS1992:'1-4A3C',kCNS1986:'1-4A3C',kDaeJaweon:'',kIRGDaeJaweon:'',kCihaiT:'552.101',kIRG_JSource:'J0-3266',kRSAdobe_Japan1_6:'C+1382+62.4.3',kEACC:'213F64',kJapaneseOn:'GA',kBigFive:'A7DA',kPhonetic:'743 967',kJapaneseKun:'WARE WA',kIICore:'AGTJHKMP',kXerox:'241:046',kIRG_VSource:'V1-5637',kKorean:'A',kTaiwanTelegraph:'2053',kMatthews:'4778',kVietnamese:'ngã',kGSR:'0002a',kMeyerWempe:'2062',kMainlandTelegraph:'2053',kGB1:'4650',kGB0:'4650',kJis0:'1870',kFennIndex:'370.08 604.07',kJis1:'',kNelson:'0200',kFrequency:'1',kFenn:'338A',kKSC0:'6818',kGB3:'',kHKGlyph:'1459',kCowles:'3065',kKPS0:'F7A5',kIRG_HSource:'HB1-A7DA',kHKSCS:'',kTang:'*ngɑ̌',kHanyuPinlu:'wǒ(23213)',kJIS0213:'',kLau:'2357',kSemanticVariant:'',kKSC1:'',kGB5:'',kSimplifiedVariant:'',kTraditionalVariant:'',kGradeLevel:'1',kZVariant:'',kKarlgren:'410',kCompatibilityVariant:'',kGB8:'',kSpecializedSemanticVariant:'',kIBMJapan:'',kHDZRadBreak:'',kRSJapanese:'',kRSKanWa:'',kPseudoGB1:'',kGB7:'',kIRG_USource:'',kOtherNumeric:'',kAccountingNumeric:'',kRSKorean:'',kPrimaryNumeric:'',kFourCornerCode:'2355.0',kHangul:'아',kXHC1983:'1209.070:wǒ',kCheungBauerIndex:'',kCheungBauer:'',kIRG_MSource:'',kJa:''}
If you focus on radicals and stroke order variations, I made this Commons:Stroke_Order_Project/Kangxi_radicals/1-99 (Please cite me if your publish an academic paper with that data). But this last one is overly detailes and limited.
Last, you may want to check on google the projects cjklib, MakeMeAHanzi, and animCJK (with variants). They contain such data in various forms.
Yug(talk)16:03, 7 April 2021 (UTC)
Licensing
I noticed that most of the files created by this project are licensed under the GFDL and CC-BY-SA 3.0. However, aren't these mostly just raster images of text with arrows? Do these meet the standard of originality to be protected by copyright? Shouldn't they be in the public domain? Mysterymanblue 03:42, 23 February 2021 (UTC)
Now that you mention it, I think you are right. In this case this discussion is still open and in my opinion all the questions that you formulated should remain opened as well(until the day in that they can be clarified from a trusty source).
@Mysterymanblue and FanNihongo: At the emergence of the project we agreed to use open fonts only and a common license for our work, with a push for PD since we are working on centuries or millennia old characters and styles. Kaishu dates back 3rd~2nd Century BC. We don't verify if contributors used an open fonts, we trust their statements. But we also stands upon {{PD-font}}, which states that raster images of typefonts are public domain under US laws, where the data is stored. It's a light point for keeping this SOP and MCC projects in raster, it gives us more spaces to play if we wish to. Yug(talk)11:22, 7 April 2021 (UTC)
Right on topic, I just uploaded one hundred kaishu images from a GPL font, but using the SO template. In the light of this discussion above I'am having a 2nd though. The Kaishu style is classic and cannot be copyrighted, published under PD license. But my svg are rather raw conversion of the GNU font. Therefore I should I rather publish under the font's GPL license (en:List_of_CJK_fonts#Font_series). Rigths ? I may also want to switch font (en:List_of_CJK_fonts#Chinese_3). Yug(talk)16:18, 7 April 2021 (UTC)
Due to the fact that making pictures and animations of stroke order is very time-consuming, It would probably be a good idea to add stroke decomposition, i.e. just list the strokes in correct order. Most of them (except for some special strokes such as in 𠆭) are already encoded in Unicode, so it would be a lot faster than making pictures for every single character. For a person that is familiar with the general rules for the stroke order, this is straightforward enough to find out which of the same strokes corresponds to which line in a character.
Stroke decomposition could be easily added as a subheading of Han character in the Translingual section or added to the right side, the same way as they are now in the picture form. The only problem I see is that strokes in a character are not well-defied. What do you think about this possible addition? Garygo golob (talk) 15:30, 12 December 2021 (UTC)
I get that it is similar, but the point that I was trying to make is that making a picture for nearly 100,000 characters is very inefficient and would be a lot faster that we just type the strokes (at least where there isn't a picture for stroke order). Garygo golob (talk) 13:47, 13 December 2021 (UTC)
In my opinion, you should comment this idea to the User Yug(The creator of the Stroke Order Project), if your idea is really good, then maybe I will consider stop creating animated images, and start working on that.
About the Animated series, I want to point out that I were working on that, that is why I developed new guidelines for its creation(which I recommend), and made a new plan to complete them, which is explained on the new section below.
I also want to point out that on the list of the new plan there are only 2042 Chinese characters, of which currently(14 December 2021) 1710 are needed to be completed.
One last thing, I suggest you to read this section from user Yug, there is explained that I have a similar problem that you, but at the end, I decided to stay with the animated series, despite all of its inconveniences. FanNihongo (talk) 06:58, 14 December 2021 (UTC)
New plan to finish the animated series
Note: this was on the roadmap, but I think it should be here.
I have a plan to finish the animated series: The last objective of the Stroke Order Project was to finish the most commonly used characters. So with that in mind, here is this list, and its status. Completing this list, is now the top priority objective for the Stroke Order Project's animated series.
So now all the help should go into finish that list. The day it is completed, then that day we will be done with the animated series. FanNihongo (talk) 05:57, 14 December 2021 (UTC)
Returning to the 100px format in the "-order.gif" animated images
I am sure that when the project started on 2006, it took a lot of effort to create the 100px images. But nowadays, those images can be created easier than the 300px ones.
I think it is time to finish the "-order.gif" animated images. Besides more than one time I heard complains from people about the creation of the animated images, including myself. I think that this new 100px format: "-order(100px)", will compensate that. FanNihongo (talk) 19:56, 7 March 2022 (UTC)
Current situation: 80/214
Example of "stroke order friendly" details.
example of what SVG may generate.
to 
Done
实 ok
主 ok
些 ok
从 ok
但 ok
分 ok
动 ok
发 ok
同 ok
后 ok
开 ok
当 ok
成 TO CHECK (should be ok)
样 ok
法 ok
然 ok
现 ok
理 ok
着 ok
种 ok
经 ok
起 ok
进 ('walk' rad 3 strokes = PRC)
还 ('walk' rad 3 strokes = PRC)
部 ('place' rad 2 strokes = PRC)
都 ('place' rad 2 strokes = PRC)
Yug (talk) 19:35, 18 January 2018 (UTC) PS: just asked the license.
Yug (talk) 23:38, 18 January 2018 (UTC)
). FanNihongo (talk) 07:31, 13 December 2021 (UTC)
![73 Returning to the 100px format in the "-order.gif" animated images](#Returning_to_the_100px_format_in_the_"-order.gif"_animated_images){kind=link}
![19:56, 7 March 2022 (UTC)](https://commons.wikimedia.org/wiki/Commons_talk:Stroke_Order_Project/Archive_1#c-FanNihongo-2022-03-07T19:56:00.000Z-Returning_to_the_100px_format_in_the_"-order.gif"_animated_images){kind=link}
