On Sun, Jan 22, 2012 at 10:15 PM, Dan Dennedy <d...@dennedy.org> wrote: > On Sun, Jan 22, 2012 at 9:56 PM, Dan Dennedy <d...@dennedy.org> wrote: >>> I thought of a new policy to add to docs/policies.txt and somewhere in >>> doxygen comments: >>> >>> The standard for strings in MLT is UTF-8. Applications must provide >>> valid UTF-8. That means, melt would be responsible for converting from >>> environment locale's encoding to UTF-8. >> >> And melt would be responsible for converting from UTF-8 to environment >> locale's encoding for output. > > makes sense > >>> For dependent libraries, if >>> their API or documentation discloses character the encoding we need to >>> convert it to UTF-8 (and filtered by icon along the way), and if it >>> unknown (e.g. av_dict), then we should assume UTF-8 and filter it. >>> Comments accepted.
I changed my mind about this policy because some libc functions like the mbrtowc() I just added uses the locale's encoding. If we require UTF-8 within MLT strings, then any libc function that uses locale would require string conversion from and to UTF-8. Naturally, libc is used much more broadly and pervasively than any other lib. I am now thinking that MLT should be using the current locale's encoding, and if a library like libxml has a specific encoding requirement we should convert it at that interface. I think this policy would reduce the number of overall changes and confine changes to more obvious and well-understood locations. -- +-DRD-+ ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
