interest check: MaestroSBTfix

[talechaser]

I am writing two programs that give MaestroSBT the ability to handle simultaneous subtitles correctly by changing the text color and moving the subs. MaestroSBT handles this imperfectly requiring some manual editing of the SSA file beforehand and producing inverted colors in the collision bitmaps.

One program is run before bitmap rendering and scans the SSA file and sets it up correctly for simultaneous subtitle support in SBTMaestro and stores some data for my 2nd program. The next program is run after bitmap rendering and fixes the bitmap colors.

I will attempt to release the programs if there is any interest. Even if there is not enough interest to "release" these, please feel free to PM me for the programs. They are written in C/WIN32. They are small and simple. I will release the source on request (for non-commercial use of course).

[ukendt]

You are wellcome to realese ur small proggies.
I hardly believe there could be any "non private" use of them.

[Liisachan]

As a side note, MaestroSBT has this bug when handling .SSA in Chinese/Japanese/Korean, related to MultiByteChars:

- If, in the Dialogue, the trailing byte of the 2-byte char is 0x7B, which would be the special char for SSA { if in ASCII, MaestroSBT will be fooled by this 0x7B and will mess up the Dialogue.

Example:
A 2-letter word <BO> <KU> &#x30dc;&#x30af; is
83 7B 83 4E
in the Code Page 932 (Shift_JIS).
83 7B is a two-byte char for U+30DC <BO> &#x30dc; and 83 4E is for U+30AF <KU> &#x30af;

In ascii, however, 7B is U+007B { as in the control code {\i1} and MaestroSBT mistakes the above sequence as
83 &#x007b; 83 4E

If MaestroSBT is being updated, I hope it will use WCHAR (unicode) internally by always calling MultiByteToWideChar, so that { has its own unique Code Point in 2 bytes (U+007B), not the Short 7B.

Personally, this problem is not so serious, as I have a workaround. Just so you know anyway :)