>>>> 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. That is a common and valid approach. One small disadvantage is that you can end up with bugs that only affect people in certain locales. In that case, you might receive a bug report and spend some time trying to figure out why the bug does not occur on your system. You may have to ask the user what locale they are running in. For example, some systems can have a filesystem encoding that is different than the default encoding - so a valid file name string may not work properly with fopen(). But even if you set a policy that all input to MLT must be utf-8, you will probably still end up fielding those questions :) I agree, this policy should reduce the number of conversions and should make the required conversions more understandable. The most important thing is that every string within MLT is consistent. We don't want to mix-and-match string encodings internally from one module to the next. ~BM ------------------------------------------------------------------------------ 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
