MobileRead Forums - View Single Post - Hacked Up Reader for epub/fb2/txt/rtf/html/pdb/etc

hawhill · 04-08-2012, 08:17 AM

Culex: Yep, the energy consumption will peak on page shifts. However, it should be roughly equal in this case. The eink consumption is probably the biggest part, so switching a full screen is probably the expensive thing here. "top" is somewhat notorious for leading to wrong conclusions (though in most cases regarding memory consumption), that's why I intervened :-) It's a time sample what top is doing and the CPU utilization is a mere estimate. A lot of the values that top shows are actually a bit voodoo :-)

amalewolf: There are two things involved: On the one hand, the bytes in a file map to (abstract) chars, which is commonly called the "charset" or "encoding" of the text. Nowadays, "UTF-8" is kind of a standard here. However, older TXT files might well be encoded differently. The culprit is that TXT files to not carry hints (in most cases) about which encoding they carry. HTML, EPUB, MOBI, PDF etc. are better in that regard. Some programs overcome this by doing guesses. Some encodings know "invalid sequences" (UTF-8 does). A typical convention is to present bytes that do not map to characters with a question mark ("?").
The other thing involved is the font you are using to display characters. Characters or character sequences map to "glyphs" in fonts. Or they might not, because the font does not really carry glyphs for the character in question. A convention for missing glyphs is to present them with an empty centered box. You might have seen those boxes when visiting foreign websites using exotic (for your environment, that is) scripts.

Sooooo... it's a bit difficult. It's not always the encoding which is the culprit, it might also be the font. And vice-versa. Or even both. Then there are documents which specify a wrong encoding and present a lot of invalid characters that way. Some programs ignore encoding information and "magically work" under some circumstances (files matching the fixed built-in encoding). Other programs ignore encoding information and derive it from the byte sequences in the document - and might as well get it wrong.

04-08-2012, 08:17 AM	#121
hawhill Wizard Posts: 1,379 Karma: 2155307 Join Date: Nov 2010 Location: Goettingen, Germany Device: Kindle Paperwhite, Kobo Mini	Culex: Yep, the energy consumption will peak on page shifts. However, it should be roughly equal in this case. The eink consumption is probably the biggest part, so switching a full screen is probably the expensive thing here. "top" is somewhat notorious for leading to wrong conclusions (though in most cases regarding memory consumption), that's why I intervened :-) It's a time sample what top is doing and the CPU utilization is a mere estimate. A lot of the values that top shows are actually a bit voodoo :-) amalewolf: There are two things involved: On the one hand, the bytes in a file map to (abstract) chars, which is commonly called the "charset" or "encoding" of the text. Nowadays, "UTF-8" is kind of a standard here. However, older TXT files might well be encoded differently. The culprit is that TXT files to not carry hints (in most cases) about which encoding they carry. HTML, EPUB, MOBI, PDF etc. are better in that regard. Some programs overcome this by doing guesses. Some encodings know "invalid sequences" (UTF-8 does). A typical convention is to present bytes that do not map to characters with a question mark ("?"). The other thing involved is the font you are using to display characters. Characters or character sequences map to "glyphs" in fonts. Or they might not, because the font does not really carry glyphs for the character in question. A convention for missing glyphs is to present them with an empty centered box. You might have seen those boxes when visiting foreign websites using exotic (for your environment, that is) scripts. Sooooo... it's a bit difficult. It's not always the encoding which is the culprit, it might also be the font. And vice-versa. Or even both. Then there are documents which specify a wrong encoding and present a lot of invalid characters that way. Some programs ignore encoding information and "magically work" under some circumstances (files matching the fixed built-in encoding). Other programs ignore encoding information and derive it from the byte sequences in the document - and might as well get it wrong.