Jitai (字体): The font randomizer that fits

Yes, I believe that it is because of the icons update, because since this update, the gear hasn’t been displayed for me as well. I don’t think that this is Jitai related, though, but rather has to do with the WaniKani Open Framework. I’ve already posted about this issue there.

2 Likes

It seems like this vocab in combination with the armed banana font completely breakes WK, it doesn’t load anything anymore and the site just gets stuck. I assume this is because there is no “~” symbol in the armed banana font?

2 Likes

Adding onto this, I’m now very sure that this is occuring because the banana font doesn’t have a ~ symbol, because the exact same issue just happened again with ~匹.

1 Like

Screenshot 2024-03-18 at 10.13.52

Sometimes Jitai throws things like this at me that really make me pause. Those are the moments I’m most grateful for it! (it’s 兄弟(きょうだい) btw)

3 Likes

Which font is that?

1 Like

I’m not seeing the gear button anymore (or the lightning-bolt button, though I don’t remember it before), either in regular reviews or in quizzes. Is there a fix, or a workaround for managing settings? (I have incorporated the changes in the patch.)

Armed banana

1 Like

Yes, rfindley released an update for the WK open framework that fixes it (the missing gear button was due to the WK icon update)

Yup it’s Armed Banana. Of all the fonts I’ve found so far that’s the one that goes the hardest :cold_face::sunglasses:

1 Like

You haven’t even nearly seen the worst yet, just wait until you see characters that contain 門 :joy: I feel like that font increased my recognition skills by 420%

1 Like

Right?? It’s so valuable, I love this script.

1 Like

Just in case anyone else wants to use the armed banana font only:

That has worked for me, whenever an item with a ~ shows up, Jitai automatically uses the other font that is able to display the character. I do sometimes get items without a ~ in the other font, but in 99% of the cases, it uses armed banana.

2 Likes

Hi all, I created a one-liner version of the fix to make it simpler for copy/paste:

@@ -360,7 +360,7 @@
        //  - normal  : randomized font
        //  - hovering: default font
        let style = document.createElement("style");
-        style.appendChild(document.createTextNode(".character-header__characters:hover { font-family: var(--font-family-japanese-hover); }"));
+        style.appendChild(document.createTextNode(".character-header__characters { font-family: var(--font-family-japanese); } .character-header__characters:hover { font-family: var(--font-family-japanese-hover); }"));
        item_element.style.setProperty("--font-family-japanese-hover", font_default);
        document.head.appendChild(style);

I created the pull request for those changes before I realized there was already other pull request for the same :stuck_out_tongue_closed_eyes: I didn’t read this post on time. FTR this is the pull request: Configuring CSS class to use random japanese font when not hovering by cheto7 · Pull Request #5 · marciska/Jitai · GitHub.

3 Likes

Is this not working? Can’t seem to get it to function?

It is working for me!

1 Like

I can’t see what I’m doing wrong, when it comes to doing reviews it just doesn’t show up in my active scripts

image

This line seems to be the problem child I’ll look into editing it later

Nope definitely can’t figure out why this isn’t working

The only other scripts I have are double check and open framework

Thanks for keeping this script alive! One issue I’ve noticed is that when the page loads or I refresh it, the character cycles through multiple different fonts before finally settling on one. It’s like some JavaScript event is firing multiple times and triggering the randomization of the font each time. I took a quick peek at the code and didn’t immediately notice an obvious cause for this.

I’m wondering if that’s a known issue or perhaps something introduced recently.

1 Like

I was able to figure out why this is happening. Though my local changes have become rather significant so I won’t share the entire thing.
Aside from fixing the style insertion by using the update from this pull request, there is essentially one main issue causing this (if your browser runs through the scripts fast enough such that it occurs).

updateRandomFont() is being called once in settingsApply() and once on the willShowNextQuestion event triggering.

There’s actually another issue, however, which is that settingsLoad is async and does not await the function call in it, so it’s continuing on to the next call in the startup() chain asynchronously. I’ll come back to this one at the end if you’re interested.

The main issue could be quickly solved by adding something like the following near the top:

let setup_complete = false;

followed by changing the last line of settingsApply() to the following:

        if (setup_complete)
            updateRandomFont(true);

and then changing setup_complete to true after startup() runs, like so:

    startup();
    setup_complete = true;

For many, that might be all you need to do. You could also put the if (setup_complete) in the willShowNextQuestion event listener, or you could solve the event firing issue in a completely different way if you wanted.

However, to see why `await` is also needed, click here for more info.

Instead of moving setup_complete = true; to after startup(), move it to the end of the .then chains in startup() like so:

                .then(installSettingsMenu)
                .then(() => setup_complete = true);

And try running the script (If you really want to see it happen in realtime, put a debug breakpoint at the beginning of updateRandomFont()).
Then, to fix it, just add the missing await to settingsLoad() like:

        await wkof.Settings.load(script_id).then(settingsApply);

And run it again.

2 Likes

Thanks, but it looks like something else is going on–at least for me. My version of the script was already awaiting wkof.Settings.save(), and settingsApply() and settingsClose() are both invoked after that, instead of as then()s (not sure why the author chose to do it that way; maybe they tried fixing this issue and eventually gave up?). Of your suggestions, the only net change was to introduce setup_complete, which didn’t have any observable effect.

Your mention of wkof.Settings.save() being async got me thinking, though. Are all functions of wkof async? Because if so, there are other places we should be awaiting, like in startup():

            wkof
                .ready(wkof_modules)
                .then(addPreconnectLinks)
                .then(registerJitaiEvents)
                .then(settingsLoad)
                .then(installSettingsMenu)
                .then(() => { setup_complete = true; return; });

When I see ready().then() like this, I assume it’s async, but I’m not familiar with the WK Open Framework. Maybe I should check the docs.

Anyway, I appreciate you taking a stab at it.