[Matroska-devel] mmg.exe 2 Bugs Related to Charset
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
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
> 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
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