Quote:
Originally Posted by tompe
That is how it works now. The records is just an implementation detail and of course you have to decode a set of records to display the text. It is not that property that is the problem. The problem is that you have to render the whole document to get the page breaks. But that might be relatively fast. Look at TeX/LaTeX that render to get page breaks rather fast.
|
Maybe I'm just dense.
Look, the easiest way to count pages in "text" is to have a loop that counts characters and line-returns. If X characters (this is depending upon the font and size chosen) are counted before hitting a line-return, one (1) unit is added to the line count and the character count is restarted. But if a line-return is hit before the character count hits the 'magic value', the line-count is incremented and the character count is zeroed. Keep doing that until every displayable character is read. Oh wait. Add in a section to do the same as the line-return initiates whenever a page-break character string is found. I note that one doesn't have to 'render' anything as long as a lookup table is created and kept for the 'magic numbers' for each font family on the Cybook. Those metrics can just be plugged in to the page-count algorithm and off we go.
As for HTML, it's not as if we don't have pretty darned good parsers out there to scan through the files and 'count' the displayable characters, so the same would apply. Do I understand correctly that Mobigen turns the input files into HTML before sticking it in the PRC container? Seems easy enough without having to actually 'render' the display. And we all know that at this time the Cybook just displays ONE font family/size at a time, so that means we don't have to do fancy footwork around multiple sizes and fonts to do this counting.
But then, I've been out of the programming racket for a few years.
Derek