[Matroska-devel] mmg.exe 2 Bugs Related to Charset

Moritz Bunkus moritz at bunkus.org
Wed Dec 29 12:06:44 CET 2004


> Hmmmm, in theory you don't have to change mkvmerge,
> if mmg can order mkvmerge via a file in UTF-8.

True, but mmg uses the same framework that mkvmerge uses. So I have to
at least extend that framework for wide char strings. Ok, that does not
mean that I have to rewrite the rest of mkvmerge to use wide strings,
too. Converting mmg to Unicode would be much less of a problem than
converting mkvmerge.

Another "problem" is that I started with mmg over half a year after I
started mkvmerge. Therefore I already had at least half a framework of
self-written functions. Instead I could have based everything on
wxWidgets. So at the moment I even have code duplication in mmg for
wxString based stuff while the same exists in mkvmerge for the "normal"
C++ "string" class...

This design still allows for building mkvmerge without wxWidgets (which
is good for e.g. MacOS X because wxWidgets has some serious issues on
that platform), but it also makes for a lot of duplicated work / strange
conversions etc.

> Of course it would be great if mkvmerge supported Unicode 
> directly, but in reality, it is almost impossible to type in 
> Unicode in the dos-box.


> Maybe I should have posted the first report in doom9 not in this 
> list, but you devs don't like doom9 now ;_;

I do :)

> This 'cosmetic' problem will be gone, if you use the default 
> charset for the commandline on Windows platform.

Only as long as users don't take a look at those 'option' files I
create. Those are in UTF-8; maybe I can add an option to create those in
UTF-16, too.


If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds

More information about the Matroska-devel mailing list