On Tue, 2002-04-30 at 09:31, Adam McDaniel wrote: > Ugh.. I would strongly recommend against that idea simply becuase there > are too many variables to make it viable. The parser's job is to format > the text in a way so that the viewer doesn't have to worry about > figuring out raw html. The parser has no idea what type of display or > font size it's formatting things to either. Ie, Narrow to largebold, or > resolution, 160x160, 240x320, 320x320, etc.
Hmmm. I wonder if you misunderstood my suggestion. Let me try one more time, if if this is what you understood me to mean, then I'll drop it. :) The parser doesn't care about the end resolution or formatting -- it simply puts "invisible" hyphens EVERYWHERE that word could possibly be broken by an EOL. Then, its up to the viewer application to actually determine where the line gets broken, and if it gets broken on one of those invisible hyphens, it draws the hyphen at EOL. For example, the following text might be generated by the parser: "The par-ser does-n't care a-bout the end re-so-lu-tion or for-matt-ing..." Then, the viewer would render it as follows: "The parser doesn't care a- bout the end resolution or formatting..." Notice only one of the hyphens actually got used, but the same text could be tastefully hyphenated at any resolution, such as: "The par- ser does- n't care about the end re- solution or for- matting.. ." It IS overkill, though, in that you are hyphenating for EVERY eventuality, but it does take all the work out of the viewer. I only worry about adding more work for the viewer because on the e-books I'm reading, it takes several seconds to render a page whenever I go to a new chapter, and I'd hate to see that delay increased. - Jamis -- Jamis Buck [EMAIL PROTECTED] http://hippa-potta.jamisandtarasine.net . "I'd horsewhip you if I had a horse." -- Groucho Marx
