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

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2008-10-30, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On 29 Oct 2008, at 17:41, Elias Pschernig wrote:
> 
> > 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. :)

One thing about supporting multiple charsets/encodings is that any addon
needs to be prepared for any type of string coming from the user, by
using the ustr* functions, but hardly any of them do it properly.

The ustr* API probably isn't as bad as I thought, but I'd prefer it to
be type safer (not using char* so much) and less reliant on fixed length
buffers.

It probably needs to be easier to work with multiple encodings at a
time. e.g. the filesystem encoding should not be tied to the application
encoding.  Even with the path API -- what encoding are path components
in?

Peter