qdmr
qdmr copied to clipboard
Extend charset for Anytone
Intro
While experimenting with APRS and AT878UVII+ I've accidentally find out that it supports much more than just ASCII characters. Further play with their CPS and scrolling through the font file, made me believe that it is the GBK encoding.
Details
GBK encodes ASCII characters on one byte, and non ASCI ones on two bytes. This could explain why some 16 characters fields are 32 bytes padded.
QT supports GBK through QTextCodec. I've made my implementation on top of it and it seem to work as expected.
TL:DR
This PR should give us possibility to use fancy characters like: "∮" or "№ " (see). It will also let something like naming "hotspot" as "ホットスポット" :blush:

TODO:
- [x] Implement GBK encoding/decoding
- [ ] Implement GBK
RadioLimit - [x] Use GBK in channel name as POC
- [ ] Use GBK where it is supposed to be used
- [ ] Rewrite encoding/decoding (cleanup explicit for loop)
- [x] Fix yaml saving issue (qdmr fails to save the utf characters)
- [ ] Prepare graphic with Anytone font
The YAML issue may require some work as the yaml-cpp library only supports utf8 in std::string. I neglected that so far. However, the majority of strings are serialized automatically from the Qt properties by calling QString::toStdString() which itself first calls toUtf8(). So if the GBK string can be converted to Utf8, it should be no problem to be stored and read from the YAML file.
Yes it is exactly how it works. String is converted to Unicode when generating reading the binary data to be uploaded.
For some reason I had problem that when adding non asci chars to the channel name it wasn't saved to yaml. Neither radio or the fancy encode was involved. I'll investigate this after the weekend.
I tested this feature branch just out of curiosity to replace "ö" with "ō" in a channel name but there was some kind of encoding and/or decoding issue that caused "Syōte" to show as "Syō te" on the radio display :)