Quote:
Originally Posted by Gudy
Meh, the HTML parser is even worse than that. It seems that POS has absolutely no usable support for html entities whatsoever, named or numeric. Which means that any attempts to get the thing to display an ampersand should prove interesting, as encountering an ampersand apparently causes it to just swallow that and the following character. Strangely, putting German umlauts into the html as naked UTF-8 works just fine, but that doesn't help with the ampersand problem.
|
I've played around some more and need to revise that assessment a bit. Named entities are still an almost complete loss. " works, but it's just about the only one that does. Numeric entities mostly work. Which means that there is one, and only one, way to get an ampersand displayed in an HTML file on the V3: & # 3 8 ;
Most other "special" characters can be displayed either as numeric entities like with the ampersand above, or as naked UTF-8 characters, provided you set the charset to UTF-8 in the content meta-attribute in the HTML head. The problem is that with some of those (I suspect at least the mdash and ndash), kerning problems abound, i.e. you get characters running into each other. This is most likely a font problem.
To sum up, should anyone from Jinke or lBook read this: support for named entities in the HTML parser would be really, really nice. The font issue is more pressing and definitely needs to be fixed ASAP. Additionally I would like to see the ability to upload our own fonts to the device.
ETA: Also, if RAR archive support could be made a bit more stable, that would be nice. RAR files made with WinRAR and Compression Method set to "best" reliably fail to open. Even if you leave Compression Method set to normal, extracting a file fails for some archives, I've yet to pin down the reason for that.