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

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 29 Oct 2008, at 17:41, Elias Pschernig wrote:
> 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.)

Best take a week to iron out all cases and come up with alternatives. ;)

> 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).
>
> 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?

Well, that is the question. About the naming scheme we use: it is  
nice and it does fit very well with libc naming, of which this is  
really just an extension. How independent are the unicode text  
functions from the rest of Allegro? I can see reasons why we might  
want to fork them off in a separate package (or a package that can be  
separate, not an addon though, since Allegro's core depends on them)  
if something similar is not easily available. If we did that, there's  
also no reason to rename them to al_something because it's a separate  
API. ;)
As for what to support, I personally see no reason to use anything  
other than UTF8, but that doesn't mean others won't ('cause they  
will). Codepages I think are definitely a thing of the past. On the  
other hand, the code is there and if it works, leave it be. At best,  
you're putting effort into removing something that isn't in the way,  
at worst you're creating more work to work to put things back in at a  
later date. :)

Evert