¶The "subtitler" filter, screen size, and font encodings
I don't remember why I originally wrote the subtitling filter. I'd like to say it was because I fansubbed some anime, but my Japanese skills are extremely minimal and my access to unsubtitled anime even less, so that couldn't have been it. I think it may have actually just been to display some on-screen lyrics to music -- probably Yuzurenai Negai from the Magic Knight Rayearth opening. Or something like that.
The two most common questions I get about the subtitler filter I wrote are:
- Why are my font sizes and border widths screwed up?
- Why does my foreign-language text appear garbled?
- Why don't my pictures and animations show up?
Fortunately, both of these are easy to fix.
Why are my font sizes and border widths screwed up?
This generally happens due to a missing or mis-set "PlayResY:" statement at the top of the file:
Title: VirtualDub 'subtitler' filter demonstration
Original Script: Avery Lee
ScriptType: v4.00
Collisions: Normal
PlayResY: 240
PlayDepth: 0
Timer: 100.0000
This field indicates the vertical height of the subtitling screen. Sub Station Alpha was meant to be used with a genlock, so it displayed your subtitles at desktop resolution and the entire screen was overlaid on top of the incoming video. Unfortunately, all of the sizes in an SSA script are in pixels, so the size of the screen is relevant; SSA stores the height of the screen in the PlayResY field.
The subtitler filter assumes that you want to subtitle your video as though it were a full screen, so it scales all measurements in the script to match the screen resolution in the script. For most values of PlayResY it assumes a 4:3 aspect ratio, except for 1024, where it assumes 5:4 to fit the common 1280x1024 resolution. The catch is that if the PlayResY field is altered, all values in the script will be scaled. This is probably not what you want. If you are using Sub Station Alpha, remember that it was meant to be WYSIWYG, so the width of your screen will be shrunk to the width of your video!
If the PlayResY: field is missing entirely, the subtitler simply uses the border and size fields verbatim as pixels.
Why does my foreign-language text appear garbled?
The subtitler does not assume the encoding of a font by its name. Nor should you rely on this behavior when making your scripts, even if your script creation program does so.
When a font is selected in Windows, it can either be created with a specific character set or with a generic character set, such as DEFAULT_CHARSET (1). The character set specifies the encoding used for 8-bit text that is rendered through that font. This is necessary because SSA scripts are narrow (8-bit) text and thus the text itself is not sufficient to determine the character set of the text. If you choose the wrong encoding, the OS won't know that it doesn't match, and will display missing character boxes or gibberish instead. You can tell the subtitler renderer to use a particular font by using the {/fe} override, or by setting the Encoding field of the style. The necessary values are GDI character set values and are given in the subtitler filter's README.
So what's wrong with setting encoding to 0 or 1, and letting the OS decide automatically?
First, Windows 95/98 and NT/2000/XP react differently when mapping fonts, so this may cause the script to malfunction on one of those platforms. More importantly, the font may not have a single encoding in it, or may have a different encoding on different language editions of the OS. Arial and MS Sans Serif are generic OS fonts that change on different language editions; Arial Unicode MS is a mammoth font that contains glyphs for nearly any supported language in Windows. Setting the font encoding on the style or dialogue text ensures that the script displays properly.
The third problem is that the subtitler filter works in Unicode, and thus has to know the character set beforehand instead of letting the font system do it. There are many benefits to doing this, one being that the word wrapping code is simpler because it doesn't have to worry about DBCS, and the other being that it fixes some display errors caused by accidentally interpreting follow bytes as the starts of style overrides. However, the side effect of this is that the subtitler must know the correct encoding. If you try to rely on the font system's remapping, or worse, try to use a program that intercepts GDI calls like NJWIN to display foreign language text, the subtitler filter will display trash in the video frame.
As a side note, parsing SSA scripts can be very nasty, because the text encoding can change in the middle of a line. You have to parse the text using DBCS-friendly code, but switch the character set the moment you see an {fe} tag.
I suspect there is a disconnect (bug) between the way the subtitler filter and SSA handles font encoding 0, but haven't gotten a concrete repro case for such a bug yet. If you wish to report such a bug, please give a script file with the problem that uses stock Windows XP fonts and also indicate which language edition of OS you are using.
Why don't my pictures and animations show up?
I don't have image or animation loading code in the filter. Images aren't too bad and I could probably support them, but animations are a real problem; the way SSA supported them was simply to spawn a control to play them on-screen, and that obviously doesn't work when you need the animation in a memory bitmap. Also, I'd have needed my image resampling code, which until recently was not modular. I don't plan to add support for these anytime soon because they basically amount to shoving crappy NLE support into the filter, and I have another program that would be a much better place to add that functionality *cough*.