API radical images


#1

Hello folks,

I’m hoping this will come to the attention of WK devs as well as technically proficient WK人.

The API documentation states that where a unicode equivalent of a radical exists, the response will contain said character and the image field will be set to null. However, when one does not exist, the character field is set to null and the image field is a URL to the image.

To WK devs:
Do the images for radicals which have a unicode equivalent exist? If they do, could they be exposed in the API too? (ie. if image is null, just let them link be set even if character is non-null).

To everyone:
If they don’t, what has been the process some of you have used to juggle between images and characters in your applications? Would one send the characters that have unicode to jisho to get an image out and use only images? Or would one juggle around with the interface to populate an image where one exists or a character otherwise?

I ask because I am building an android XML layout right now for a which would take in the character (which is fine for Kanji, Vocab, and some Radicals), but if I need to juggle the interface to adapt to whether it is in an image instead of text, I need to either a) inflate and deflate Views accordingly, or b) switch from a simple LinearLayout to a RelativeLayout and mess around with the View’s visibility as needed. Neither of these are ideal.

Thanks!


#2

No images exist for the radicals with Unicode equivalents. They have only been produced for the radicals where they were needed. The usual way to go is to do just like WaniKani does, and render radicals as text where possible and as images otherwise.

Something you could do is check out WakaFont, a custom font WaniKani uses to display some radicals that don’t exist in Unicode. I don’t think WakaFont codepoints are a part of the API, though, so you’d have to map those manually. Once you’ve done that, you can just display most radicals in your font of choice, and WakaFont ones in WakaFont. If I recall correctly there are still some radicals that are image-only, though… You’d have to display those as images regardless (or make your own custom glyphs).

If you really wanted images everywhere, you could render the unicode characters to images via a library of some sort. Due to resolution and image/text rendering differences, however, there’s a very real risk that it’d look a lot worse.


#3

Thanks for the detailed response. I guess I will be rendering based on the type of resource available per radical.

Thanks!


#4

Hi all, I’m new to WK, so I apologize if this question’s in the wrong space. But this thread deals with problems with radical images and is fairly recent, so…

I’m at level 4 now. If I extract level 1-4 radical details through the api, most of them come out OK, but nine (out of 115) come up ‘null’. Given that WK uses Unicode characters where they exist, I’m assuming that the missing nine are non-Unicode, and that there’s some problem accessing those image files. The picture below shows the details for the nine missing characters, plus an example of a radical where the character can be seen.

In case it’s relevant, I’m using Windows 7 and Firefox 59.0.2 (the latest version).

Thank you!

Dan

PS - this is my first post. If the image below is missing/gobbledeegook, then I need to learn how to include an image too…

WK_Radical_problem


#5

I’m not seeing a question… :sweat_smile:
Anyway, yes, those characters are not Unicode. They are image files.


#6

Well, my questions are, (a) Does anyone have any idea why WK returns the name of those image files rather than the images themselves, and (b) Is there any way to get WK to send the images?

Thank you :slight_smile:


#7

I would guess the reason that WK returns the names of the image files instead of the actual files is to save bandwidth for every time someone needs information other than the image/characters.

As for how to get the image, it looks like the image field (not image_file_name) contains a full URL, like https://cdn.wanikani.com/subjects/images/8762-gun-large.png


#9

As @TellowKrinkle said, it’s to save bandwidth on those responses and make them easy to parse. Delivering images via JSON is super duper ugly, as Base64 encoding is the only real way to do it. The encoding process increases the image file size, only adding to the bandwidth problem.

BUT! We know that the API v1 image/custom font/Unicode setup isn’t the cleanest. You should should check out API v2 — the way the images are delivered is way better (we think), far more consistent, plus you get access to SVG versions of all the radicals. We give the content types and the full URL to the image in there, not just the file name, so it’s easier to link to it or grab it.

Let me know if there’s anything we can help out with. :smiley:


#10

Hi TellowKrinkle and oldbonsai,

Thanks very much for your thoughts. I can see how in the real world, including images in the JSON feed is really a non-starter. I didn’t know there was an API v2 available, so I’ll look into that.

Thanks! :sunglasses:

Dan