Most efficient way to suggest/submit multiple corrections?
kintopp
kanjialive.uchicago.edu) which is a simple web app for teaching kanji
to beginner and intermediate level students. Kanji alive was
originally released in 2005, then quickly re-done a few years ago to
work around some technical issues. We're now planning to completely
revamp the app as a HTML5 application and are considering using
KanjiVG for our animations.
However we foresee that we are going to have to make many adjustments
to the KanjiVG data. The Japanese instructor who leads the project
prepared these screenshots to show the kinds of changes we anticipate
making:
http://dl.dropbox.com/u/1667511/KanjiVG_KA1.jpg
http://dl.dropbox.com/u/1667511/KanjiVG_KA2.jpg
How do you recommend we should handle best submitting and/or
requesting such changes on a comparatively large scale? For reference,
there are 1235 kanji in our database.
many thanks,
Arno
karl rosvold
I'm sure other members can tell you more about the details, but as an
example, Kotoba! (a dictionary APP for iPhone) uses the KanjiVG stroke
data, but it has none of the issues that were shown in your
screenshots. Others will have to confirm this, but I guess KanjiVG has
various settings that can be used to alter the appearance of the
kanji. Hopefully someone with a more detailed description can respond
to you soon.
Karl
> --
> You received this message because you are subscribed to the "KanjiVG" group.
> For options and unsubscribing, visit this group at
> http://groups.google.com/group/kanjivg
Alexandre Courbot
On Mon, Feb 20, 2012 at 11:20 AM, kintopp <arno....@gmail.com> wrote:
> Hi, I'm acting as the project coordinator for Kanji alive (http://
> kanjialive.uchicago.edu) which is a simple web app for teaching kanji
> to beginner and intermediate level students. Kanji alive was
> originally released in 2005, then quickly re-done a few years ago to
> work around some technical issues. We're now planning to completely
> revamp the app as a HTML5 application and are considering using
> KanjiVG for our animations.
Great idea! ;)
> However we foresee that we are going to have to make many adjustments
> to the KanjiVG data. The Japanese instructor who leads the project
> prepared these screenshots to show the kinds of changes we anticipate
> making:
>
> http://dl.dropbox.com/u/1667511/KanjiVG_KA1.jpg
> http://dl.dropbox.com/u/1667511/KanjiVG_KA2.jpg
I'm not sure how you got these renderings of KanjiVG, but there are a
few errors with them to start with. The middle lines in 月 and 白
clearly touch the right line in the SVG files. To get a good idea of
what it should look like, I suggest you open the KanjiVG files with a
SVG editor like Inkscape or see the renderings we get in Tagaini
Jisho.
Also I do not experience the hook in 殺 (see attached korosu.jpg) with
the latest data, which indicates you are maybe using old data to get
your renderings? (actually I do not remember seeing such a thing at
all, so this may be very very old).
As for the non-straight lines and corners that stick out, I do not see
these as errors, as many renderings (mincho?) use this style. Well,
the non-straight line case may be debated, I'm not sure why it is this
way neither.
> How do you recommend we should handle best submitting and/or
> requesting such changes on a comparatively large scale? For reference,
> there are 1235 kanji in our database.
The best way to submit a large amount of changes (or to submit any
change at all, actually) is to fork the github repository at
https://github.com/Gnurou/kanjivg , commit your changes on your clone,
and ask for a merge request. However it seems that with respect to the
latest data, the latest remaining concerns for you are the corner
thing and the not-so-straight lines, and from our perspective this is
clearly not an error - more of a style decision. What I can suggest if
you cannot live with that is to adjust the SVG paths of components to
your liking. For instance, points that are close enough could be moved
to the same position to fix the corners, and lines of a particular
type can be straighten the same way (just have a small SVG parser that
checks the stroke type and fix the positions of the initial point and
first curve's control points). This should not be hard to do using a
script (can even be done on the client side) and should give you the
result you expect.
Of course if you see errors in the data (wrong stroke order,
non-matching component information, ...) we would be glad to have your
fixes. If you are not familiar with git/SVG I can also answer your
questions here.
Alex.
kintopp
Thank you both for your responses. I've forked the current build and
still see the problem with 殺 for example but I can now see why. First,
it's not the renderer. We were just previewing the swf file in the OSX
Finder (I subsequently double-checked with Inkscape) but that's not
the issue. What had happened is that I had been looking at 6bba-
Kaisho.swg and not 6bba.swg. I took a quick look through the docs on
the main KanjiVG site and couldn't see an explanation for the variant.
Could you explain the rationale behind the variant files? 6bba.swg
certainly looks fine.
I do still have a follow-up question. How do you literally recommend
changes or corrections be made? I mean, I understand that I can push
my changed files back up to github for review and merger, but what
tools do you recommend we use to make the actual corrections.
Inkscape? Some other app?
Many thanks in advance.
cheers,
Arno
Ulrich Apel
> I took a quick look through the docs on
> the main KanjiVG site and couldn't see an explanation for the variant.
> Could you explain the rationale behind the variant files? 6bba.swg
> certainly looks fine.
KanjiVG takes a schoolbook - kyokasho - font as modell. Schoolbook font is a variation of the kaisho stile which is closer to character stiles like Mincho, goshikku etc. Where standard kaisho has a hook - hane - at the end of a stroke, but mincho hasn't, a kyokasho font has no hane. Where strokes in standard kaisho don't touch, but touch in mincho, they touch in kyokasho. If you have three drop-like strokes in kaisho in the lower part of ito-hen but you have one long stroke in the middle at Mincho fonts, Kyokasho has the same long stroke; and so on.
Kyokasho is the stile that is taught at school, kaisho is what one learns at calligraphy or shodo. In cases, where kyokasho character form differs from standard kaisho, there is variant form for kaisho which is marked accordingly. KanjiVG considers the schoolbook variant as the standard although it is newer than kaisho. There maybe more variations for kaisho too.
It might be desirable to make further aesthetic adjustment, but both versions can be considered as correct for their purposes.
> I do still have a follow-up question. How do you literally recommend
> changes or corrections be made? I mean, I understand that I can push
> my changed files back up to github for review and merger, but what
> tools do you recommend we use to make the actual corrections.
> Inkscape? Some other app?
At this point, I wouldn't treat non-straight lines and corners that stick out as mistakes (the characters look like they do because we tried to stick relatively close to the model font). It shouldn't be too difficult, to write an algorithm which applies certain rules for this kind of problems and "fixes" them automatically without changing the original data. This would mean to read out the position of certain SVG control points and to adjust them according the position of certain other control points.
More important is the problem which Karl was mentioning: data consistency. For example stroke type and the number of control points and the form of the stroke in SVG should be related. This could be checked automatically. Sometimes stroke types also include information whether a stroke touches an other one. This could be checked for constancy, too. If the stroke types are correct, one could again check whether all component variations are marked as such. Not all possible components in a character might be marked as such. One could find possible candidates by looking for series of certain stroke types. I will discuss the feasibility of such operations with our IT specialist, when I am back at Tübingen in March. We have to see, whether our dictionary society would be able to cover the costs.
Ulrich
Alexandre Courbot
On Feb 26, 2012 1:24 AM, "kintopp" <arno....@gmail.com> wrote:
> I do still have a follow-up question. How do you literally recommend
> changes or corrections be made? I mean, I understand that I can push
> my changed files back up to github for review and merger, but what
> tools do you recommend we use to make the actual corrections.
> Inkscape? Some other app?
As much as possible, I use good old text editor to do most changes (since they do not go further than inverting two lines or fixing component information. However when you need to change the shape of a stroke, this is not enough.
The problem with editors like Inkscape is that they add plenty of properties and mess with the formatting of the file. We want to keep every file in KanjiVG as simple and readable as possible, with the same copyright notice, the same groups in the same order. In order to address this, I was using a script (harmonize-svg.py) that is supposed to remove these and produce a clean kanji from an editor-produced file. I know for sure it works with Inkscape for instance. Problem is that it has probably not been updated to the new format, so if you plan to use it please let me know so that I ensure it works as intended.
The best way to edit KanjiVG files would be to have an inline editor in HTML5. This is probably far from being complicated - and by using the Github API one could probably even directly commit changes into its repository clone from it. We would also have total control as to how the file is generated and ensure the strokes match constrained associated to their types (number of control points and default shapes, etc.). Lack of time prevents me to tackle this, but anyone willing to provide this would be welcomed. This would be a huge contribution (not in term of work, but in terms of workflow improvement).
One word about commits by themselves: try to keep them as consistent as possible, i.e. only group changes together if they are related. For instance, if you fix a stroke order in all the instances of a kanji used as a component, it is ok to do that in one commit. However, please avoid having a commit that says "Fix stroke for x and component information for y". This would make it harder to undo the changes if the commit turns to be wrong itself.
Alex.