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

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Wednesday 29 October 2008, Peter Wang wrote:
> 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?

whatever is the current... It currently should handle unicode incoming 
strings. If it doesn't, sorry, my-bad.

What should happen is the fshook api should send in "native" format strings, 
which could be ASCII, some codepage, 16bit unicode or UTF8 depending on the 
platform and "locale". And fshook should be able to take in whatever format 
the user gives it that allegro supports.

>
> Peter
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx