Kumirei is correct.
Radicals are primarily represented by an image due to not all of our radicals have unicode representation. If there is a unicode version, then we include it as a supplement.
In other words all radicals have images (and SVG). Some radicals have unicode.
And now if I could understand why resizing the SVGs results in some of them having blank squares rendering over parts, Iāll be happy.
Iām resizing the SVGs using CSS, so itās probably something Iāve done there.
It looks like maybe your setup is trying to render the clipping masks with a white fill. They should only be clipping other rendered vectors, and shouldnāt actually be rendered themselves. Are you using the SVGs with CSS, or the ones without? What browser (or other tools) are you rendering with?
Iād recommend opening one of the clipped SVGs in the Elements panel, find the clipping mask(s), which should be inside a <defs> tag, and see what CSS rules are being applied to them.
Edit: What CSS are you using to resize them? You should be able to just set the width and height on the <svg> element.
@rosshendry: what @rfindley said. There should be two SVGs delivered with each radical: with and without inline styles, as indicated in the metadata object in the API response. Try the ones with the inline styles and see if that makes a difference.
I should be using the ones with stylesheets, but Iāve seen the effects of āshouldā on my code before! Iāll hopefully have some time to pick this up again next week, I could really do with a leech window on my desktop at all times.
For what itās worth, I use the ones without inline styles, then just add the following CSS on the page:
svg.radical {
fill: none;
stroke: #000;
stroke-width: 68;
stroke-linecap: square;
stroke-miterlimit: 2;
}
Iāve tested that in Chrome and Firefox, and both work.
If youāre rendering at small size, you may want to reduce the stroke-width.
And to set the size:
svg.radical {
height: 40px;
width: 40px;
}
Not sure if this is intentional, but the API is available over normal HTTP as well as HTTPS. That could be a security issue when sending authorization credentials.
EDIT: Iāve also just noticed, the kanji and vocab data both have subject_component_ids listed as a property, but the actual API returns component_subject_ids
That did it! No stylesheets, and the styles you were using. If I get the time, itād be nice to compare the stylesheet youāve provided with the one in the SVG.
Hmmm, howāre you getting to the endpoints over http? My usual set of testing tools is consistently reporting 301 responses when I hit anything at http. I can see how a 403 or something similar might be a better response, though. 
Ah, so it is. I was using insomnia and the swagger editor to test some interactive documentation I was working on, and they were both hiding the 301 from me (in insomnia, it shows up in the timeline)
Iām working on interactive docs for the new API (OpenAPI 3.0.1 standard), and I have a couple questions:
32-bit. I donāt foresee exceeding thisā¦
All are currently 32-bit. The ālargeā, by far, resource ids can be found on /reviews (200,000,000+). At some point we may have to entertain the idea of changing it to 64-bit.
I have my first version of the v2 API Docs:
You can copy one of the above links into the top text box at petstore.swagger.io and get the same result.
My github repository (https://github.com/bennettBuckley/WaniKaniAPI) has UI components that will give you the same experience, but without the green bar at the top.
@rfindley, whould you be willing to host the UI components on the WKStats site?
It returns any text-based data as text/plain, which doesnāt play nice with the html.
see here: https://raw.githubusercontent.com/bennettBuckley/WaniKaniAPI/master/ui/index.html
Iām pretty new to github, so maybe thereās a way to do it I donāt know about.
Ahh, makes sense, and I remember reading about that now that you mention it. You could also look at github.io, though, which hosts a site directly from a repo. But I think itās limited to one site without a subscription, if I recall correctly.
But I donāt mind hosting the images.
Thanks for letting me know! This is so much easier than tracking down some free hosting.
https://bennettbuckley.github.io/ for anyone interested
The copy is lifted straight from the first post, minus the tables (CommonMark doesnāt support them yet). Let me know if thereās anything in the docs that youād like to see updated.
This update will be live tomorrow (about 16 hrs). Just wanted to write this up to get it out of the way.
For /subject resources we include component_subject_ids, which point to subjects which compose the primary subject in question. Vocabulary has kanji components. Kanji has radical components. Radicals do not have components.
The update will add amalgamation_subject_ids. You can kind of think of it like the reverse of component_subject_ids. The attribute lists subjects which has the primary subject as a component.
Radicals are an amalgamation element of many Kanji (if you look at a subject page, such as this one), its analogous to the āFound in Kanjiā list.
Kanji are an amalgamation element of many Vocabulary (if you look at a subject page, such as this one), its analogous to the āFound in Vocabularyā list.
Vocabulary are not an amalgamation element of anything.
My docs have been updated with the new fields.
UPDATE: Iāve also manually written an example for the Subject Resource. Since there were three possible types, the docs werenāt auto-generating an example.