Re: [AD] al_font_textprintf() and uvszprintf()

[Ron Novy <ron.novy@xxxxxxxxxx>]

>> Currently, al_font_textprintf() allocates a static buffer of size 512  
>> characters. While I'm sure that's plenty for any line of text anyone  
>> is likely to want to display on a monitor in ASCII on a current  
>> monitor, it's an arbitrary limit and it's probably not particularly  
>> safe when having unicode output. Should this be increased? Or better  
>> yet, a way found to increase the size of the buffer dynamically as  
>> needed?
>
>Yes, we should not hardcode sizes if there is a chance they are too
>small. Before the A5 release we probably should reserve a day or so
>where we check all code for hardcoded limits used in that way. (Another
>one I remember is the config system, it sets a limit on the size of
>entry names/values right now.)

I'm working with a similar problem in 4.2.  I've been trying to add support 
for get text style formatting, but haven't started it yet.  I think it would 
require a re-write of the function.  My plan is to parse it once to load 
and convert the format specifiers into text and then parse again to put 
text and options into the correct order in the output string.  So far
I've created a dynamic fifo buffer to make things a bit easier, but other
than that I have no testable printf function yet... Don't know it'd be right 
for allegro, but just thought I'd mention it.

>> Secondly, it uses uvszprintf(), which is fine in principle, but  
>> uvszprintf() is an Allegro function that is missing the al_ prefix.  
>> Should it acquire one? I can think of reasons why maybe it shouldn't,  
>> but it does seem to violate A5's intention of not polluting the  
>> global namespace.
>
>We never came to a final conclusion yet what to do about unicode I
>think. Prefixing the A4 API with al_ seems to be a good start to me -
>however there's some unsolved problems with it (e.g. a proper
>implementation of ustricmp needs to do more than the A4 one).

Are there any cases where these unicode functions cause problems
with other libraries?  I like the way the functions are named currently
but if it could cause problems I wouldn't mind the al_ prefix...


On Wed, 2008-10-29 at 16:58 +0100, Elias Pschernig wrote:
>Also, do we want to keep support for codepages? Support for UTF16? Or is
>just UTF8 (with 7-bit ASCII included as a subset) enough?

It might be nice to be able to convert a Windows-1252 codepage to UTF8 or 
UTF16.  Also might be cool to have endianness specific versions of UNICODE
for converting text loaded from files.  Even though UTF8 is probably a better
choice it would be nice to include it in the distribution.  I've created my own
UNICODE functions that are endianness specific, but they haven't been 
fully tested.