\h tag displays incorrectly with GB2312 encoded non-unicode fonts

[GoogleCodeExporter]

\h tag displays incorrectly with Chinese character, but works fine with English 
character. 

I have attached the script. The second picture is rendered by xy-vsfilter. 

Original issue reported on code.google.com by River1...@gmail.com on 6 Mar 2012 at 11:47

Attachments:

• 1.png
• 2.png
• test.ass

[GoogleCodeExporter]

The problem seems to be in the fonts you used. I get the first picture when I 
try to render it with xy-vsfilter / regular one in aegi.
Howerver, when I change the font to Arial, everything works right everywhere.

Original comment by tp7...@gmail.com on 7 Mar 2012 at 2:28

Attachments:

• 1.png
• 2.png

[GoogleCodeExporter]

So it may have something to do with the font encoding. 
Using fonts encoded in GB2312 will have the problem. 
Arial is encoded in ANSI, and doesn't contain any Chinese character. 

Original comment by River1...@gmail.com on 7 Mar 2012 at 8:37

[GoogleCodeExporter]

It doesn't appear to occur with with Unicode(?) font's like Adobe's Chinese 
fonts and Microsoft's Arial Unicode MS, so I've changed the title to assume 
this is a problem with GB2312 encoded non-unicode fonts (GB2312 -> Unicode) 
rather than the actual GB2312 code page (Unicode -> GB2312).

Original comment by cyber.sp...@gmail.com on 8 Mar 2012 at 2:47

• Changed title: \h tag displays incorrectly with GB2312 encoded non-unicode fonts

[GoogleCodeExporter]

Original comment by cyber.sp...@gmail.com on 28 Apr 2012 at 10:50

• Changed state: Started

[GoogleCodeExporter]

I feel I need to offer a bit of explanation about this issue.

As it turns out, VSFilter 2.39 and 2.40 contained a stupid mistake in their 
implementation of \h which caused it to not follow the ASS spec. A long time 
ago, YuZhuoHuang fixed the stupid mistake of the original VSFilter 
implementation, causing the \h tag to work as described in the ASS spec. 

Issue #84 is caused by the fact that the glyph normally used for the \h tag 
doesn't exist in GB2312. VSFilter had different behavior since their 
implementation of \h was broken (bug of a bug).

So basically the fix in xy-VSFilter 3.0.0.8 for this issue isn't truly a bug 
fix, but rather a VSFilter compatibility fix. To maintain compatibility with 
VSFilter's 2.39/2.40 incorrect behavior, we needed to once again break the \h 
tag implementation as it was originally broken in VSFiler. xy-VSFilter and 
VSFilter 2.39/2.40 should now behave identically with \h.

Original comment by cyber.sp...@gmail.com on 30 Apr 2012 at 1:27

• Changed state: Fixed