First is to ensure we do not get our terminology mixed up. When we're talking about 'pages' let's limit that to the discussion of the pages of CEGUI::FontGlyph structures that get created (which are I believe always 256 to a page), and when talking about textures (and the related discussion about video memory and other memory concerns), let's be sure to call those textures and not mix or confuse the two concepts together.
Second, we need a test case. It need not be networked, since that's overkill, but we need to have a small test where the app is set up and we can trigger creation and rendering of the the 'attack' string by way of pressing a button or key. This serves to first demonstrate that the issue is real (although we all accept this as the case already) and more importantly, allows us to know that modifications made are having the desired effect. Without such empirical evidence, I would be extremely reluctant to start changing things.
With regards to textures and why we maximise the use of the available space, that is to first ensure that texture space - and therefore video memory - is not wasted and secondly it potentially helps to minimise texture changes thereby increasing the size of the geometry batch we can send to the GPU - thus maximising performance.
I think overall, we need to either have an option to enable / disable the rasterisation to texture of entire ranges of glyphs in response to needing a single glyph in a given range and just rasterise them one at a time as needed (which is how it used to be), and / or to be able to specify such control more granularly - so we might be able to specify that certain ranges be rasterised as ranges (such as glyphs in the latin ranges) and that other ranges be rasterised one glyph at a time.
It's something that I would need to think a lot more on - but the test case is absolutely required, this way it's far easier to play about with suff and guage the effects of what we're doing
CE.
