Damn, thank you! I asked whether it was possible to disable Unicode normalization for a specific deck/preset, and sadly didn’t get a response, so this is really good news!
I still need to add the characters with the other diacritic: ぱ, ぴ, ぷ, ぺ, ぽ. But I can do that on my own.
You’re right! I forgot about them. I’ve edited my previous message to include them in the script.
Windows 10 Qt6, no add-ons, 24.10 beta2. This issue does not occur in beta1.
There appears to be a regression with the Editor’s “Remove Formatting” (Ctrl + R). All HTML tags inside the ones currently being removed are also removed, even when they shouldn’t be.
For example:
<b>this is an <a href="foo">example</a></b>is changed toexample(not expected).- While
this is an <a href="foo"><b>example</b></a>becomesthis is an <a href="foo">example</a>(as expected).
The same happens when styling is removed using the specific button or shortcut. For example, using Ctrl+A → Ctrl+B → Ctrl+B (applying and then removing the <b></b> tag) on HTML like this is a <a href="foo">test string</a> results in this is a test string.
Curiously, tags that have a class attribute seem to be unaffected, while all other attributes I’ve tested do not seem to provide any “protection”.
For example:
<b><a href="foo" class="myClass">Some Text</a></b>changes to<a href="foo" class="myClass">Some Text</a>.- While
<b><a href="foo" id="myId">Some Text</a></b>becomesSome Text.
(I only included <a></a> tags in my examples, but the same behavior occurs with all other tags I’ve tested.)
1 Like
I noticed that this behavior occurs when a tag isn’t assigned to any cards yet. For example when creating a new tag. When some cards have been added to said tag, it becomes “clickable”
2 Likes
Note.apkg deliberately does not use Anki’s {{type::}} properly: Rather than comparing to {{type::Reading}} or {{type::Meaning}}, it compares to {{type:sort_id}} on both card types. So Anki does not compare to “Lava” and “ようがん” to begin with (and these comparisons continue to work fine), but to “7330”.
Of course Anki then produces something wrong.
So I do not understand the intention of that deck’s author: Why even use {{type::}} in an unsupported way likely to break eventually, only to then redo it in Javascript?
It seems this approach is used as a workaround to potentially allow for more than one correct answer.
For example, the following code is from another note type from the same deck author. Depending on the user’s input, the typed answer will be compared to either the Reading_On field, or the Reading_Kun field.
<div id="correctAnswer" style="display:none">{{Reading_On}}</div>
<div id="correctAnswer2" style="display:none">{{Reading_Kun}}</div>
<script>
//some addons read the script too early:
if (document.getElementById('typeans')){
var typedAnswer;
var correctAnswer = document.getElementById('correctAnswer').innerText;
var correctAnswer2 = document.getElementById('correctAnswer2').innerText;
var typedAnswer_element = document.getElementById('typeans');
if (typedAnswer_element.querySelector('.typegiven')){
// the "typegiven" class exists only on iphone:
typedAnswer = typedAnswer_element.querySelector('.typegiven').querySelector('.typeBad').innerText;
} else if (typedAnswer_element.querySelector('.typeBad')){
//for pc and android:
typedAnswer = typedAnswer_element.querySelector('.typeBad').innerText;
} else {
//if failed to detect answer
typedAnswer = "";
}
//the part of code below is ugly and could be improved
var means1 = correctAnswer.split(new RegExp(',|、', 'g'));
var means2 = correctAnswer2.split(new RegExp(',|、', 'g'));
var means = means1.concat(means2);
var mean = typedAnswer.split(new RegExp(',|、', 'g'));
var found = true;
for (var i = 0; i < means.length; i++) {
means[i] = means[i].trim();
}
for (var i = 0; i < mean.length; i++) {
mean[i] = mean[i].trim();
if (means.indexOf(mean[i]) === -1) {
found = false;
};
}
//Modify answer output
if (typedAnswer === "") {
document.getElementById('typeans').style.display = "none";
} else if (found) {
var c = "<div id='correct'>"+typedAnswer+"</div>";
var d = document.getElementById('typeans');
d.innerHTML = c;
} else {
var e = "<div id='incorrect'>"+typedAnswer+"</div>";
var f = document.getElementById('typeans');
f.innerHTML = e;
};
};
</script>
1 Like
I’ve noticed something and I’m not sure how to interpret it. Beta 1 and beta 2 each report a different RMSE for the same parameters, which I guess makes sense because beta 2 takes historic same day repetitions into account. However, with beta 2 the most optimal parameters result in a dramatic reduction of my workload. This is not a fluke, I’ve optimized multiple times with fsrs4anki_optimizer.ipynb (which often gives a better result than Anki for some reason) on different days, and it results in a lower workload every single time. I’m a bit hesitant to sync it because my actual retention matched closely with my configured retention with the old parameters. Is it because FSRS can better separate cards that I answer incorrectly multiple times in a row on the same day from cards that I answer incorrectly only once?
I should add that there are also some cards that are scheduled into the past (are overdue), but it doesn’t seem to be nearly enough to account for the difference in the overall workload.
The whole point of FSRS-5 is that it takes into account information from same-day reviews to refine it’s predictions. That being said, I’m somewhat surprised that the difference is so stark in your case.
The better RSME I get in beta 2, the worse it seems to be in beta 1 (iOS). I’m hoping there will be a beta 3 soon for both platforms so I can properly test it with the new parameters based on same day reviews. It’s a vocabulary deck and my best guess is that it can separate the easy cards from the hard cards more effectively and schedule the easy ones further into the future and repeat the hard ones a bit more often, which is probably the minority of the cards, hence the reduction in the overall workload.
Oh, btw, next beta will have <1d intervals given by FSRS. Right now, if you leave the (re)learning field(s) empty, the intervals won’t be shorter than one day, but in the next beta, FSRS will be able to control short-term scheduling if you leave the fields empty.
However, this is still an experimental features, so there might be issues.
When is the next beta coming 
Whenever Dae wants.
4 Likes
Do you really think some of us would know better than you? Everyone has the same amount of information given there’s no official hard-coded rules for when a beta should come out.
That makes sense, thanks.
I guess it would be more robust to do everything in JS—incl. the front side input (with sessionStorage.{get,set}Item carrying it over)—and then skip Anki’s type: entirely. But I know that may not be an easy task and when you’re doing 1000’s of notes, deck authors are already busy.
Anyway, the beta3 will return to NFC, so the fix will no longer be necessary.
BTW, there’s also an interesting addon that does multiple-choice type’ing: Answer Set (GH/AW). It could be ported that to Anki’s rslib (typeanswer.rs is nicely prepared now 
) and then MC would be available throughout the ecosystem.
1 Like
Hi all,
Beta 3 is now available:
New iOS beta coming hopefully tomorrow.
I can’t reproduce such big differences - maybe already improved in beta 3? It’s centering on the colon in the expectation multiple lines of text will be shown, so it won’t be exactly centered unless we change how it’s rendered.
6 Likes
Bug in Discard changes (Beta 3)
Repro Steps:
- Open Deck Options
- Close Deck Options page by clicking the X button.
- A “Discard changes?” window pops up despite no changes being made.
1 Like
Doesn’t happen for me. If you can reproduce it after saving the changes, please let me know the deck in question so I can figure out what’s going on.