Aedict -> Ankidroid export bug in 3.40: visible HTML code

[aedicted]

The Kanji / readings field has been made editable during export to Ankidroid now.

However, the reading field contains weird HTML expressions in the AnkiDroid flashcard after export which weren't present before.

[mvysny]

Sorry about that - that was caused by #770 . If you leave the HTML there, in the reading field, it will mark the pitch in red in AnkiDroid. Yet, perhaps most of the users do not want that / do not care about pitch markings, so I guess I should introduce a setting for that. A checkbox setting whether to mark exported pitch in color or not; it should probably default to false.

[mvysny]

Actually hard to say whether this is a bug or a feature :-D

[laxa88]

(just chiming in) I think since users may have preference for how the "reading" field should be rendered (just raw text, or with-HTML), having a setting to toggle this would be helpful. :)

[aedicted]

Hello Martin, meanwhile, when it comes to the furigana/reading thing, some other thought came into mind: Actually, I still find it a bit nutty that one has to manually edit the field in the first place, just in order to get the correct centering of the Furigana. For example, when we have 思い出す, I would have to insert a space beween い and 出 to prevent the Furigana from being completely off. However, isn't it possible to automatically recognize the "transition" between the Kana and the Kanji? This would already cover the most cases where the Furigana are "screwed up". With words, consisting of several Kanji, while it is less apparent, as far as I understand it, the default, as I already mentioned in another mail, isn't totally correct either. For example: 機能 would have 機能[きのう] as default, which still looks decent. However, since the first Kanji only stands for き and the second for のう, I tend to manually edit it to 機[き] 能[のう] in order to have the reading のうcentered above能 only and not across the whole expression together with き. Now to be honest, I'm not sure myself either, if there is a specific rule in Japanese to determine what part of the reading belongs to which Kanji. There are some rules though, like the う at the end wouldn't be represented by one single Kanji only, thus it is obvious that the 機 stands for き and not きの and the 能 only for the う. Same with small つ (っ), they would always belong to the preleading Kanji. I hope it's understandable where I'm getting with this. I don't want to have to manually edit the expression field in the first place but have it just fine out of the box provided by Aedict. ^^ I'd like to hear your opinion about this. Regards Joshua

…

On 11 Jul 2017 7:54 pm, "Martin Vysny" ***@***.***> wrote: Actually hard to say whether this is a bug or a feature :-D — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#777 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYi10AfQvq_OFMG1gt2rs4sAMo_pINfeks5sM1RkgaJpZM4OTq8x> .

[mvysny]

@aedicted I completely agree. The format of 機能[きのう] is non-deterministic - it is not clear to which parts actually the reading applies: is it 能 or 機能 ? Internally, in Aedict, I'm using a different format: {機;き}{能;のう} which makes it clear.

The problem is that the abovementioned format of 機能[きのう] was designed by AnkiDroid and is used by AnkiDroid, so I need to stick to that for the foreseeable future.

Perhaps you should open a feature request for the guys at AnkiDroid to add support for the "curly brace" format? Incidentally, this format is also used by the FuriganaView component: https://github.com/sh0/furigana-view

Anyways this does not relate to the original bug report, please make a new bug report regarding this.

[mvysny]

@laxa88 You're right - there's probably no other way than either not have the html at all, or let the user deal with it ;) Since after the field has been modified, it would be impossible to track the changes and add the html back in.

[mvysny]

Fixed in Aedict 3.41