Position/rotation incorrect for some characters in horizontal text for some fonts

[GoogleCodeExporter]

What steps will reproduce the problem?
1. try the next subtitle line
{\fn@MotoyaLMaru\frz-90\an5}涙のブルー
2. compare with
{\fn@IPAGothic\frz-90\an5}涙のブルー

What is the expected output? What do you see instead?
Apart from the different font face both texts should appear the same. However 
in the first case the ー character is incorrectly rotated. Same goes 
positioning and/or rotation of characters like 
「」、。…(punctuation)ゅょゃっ (small kana), etc.

What version of the product are you using? On what operating system?
libass-0.10.1 on Fedora 18 (gnu/linux)

Please provide any additional information below. If relevant, please attach
the ASS/SSA script file and any fonts used in it.
The exact result depends on font used, e.g. with EPSON fonts this seem to 
happen only if the text contains kanji (but I'm not sure whether I can 
distribute EPSON fonts here, hence only the Motoya example). It's probably not 
a bug in font, as LibreOffice and pango renders this correctly.

$ pango-view --margin 30  --gravity east --rotate -90 --font "MotoyaLMaru" -t 
"涙のブルー"
gives correct result. The same with IPAGothic.
$ pango-view --margin 30  --gravity east --rotate -90 --font "@MotoyaLMaru" -t 
"涙のブルー"
gives incorrect result. The same with @IPAGothic, so this isn't probably the 
root of the problem.

I attach both fonts.

Original issue reported on code.google.com by martin.s...@gmail.com on 16 Jan 2013 at 12:55

Attachments:

• MTLmr3m.ttf
• ipag.ttf

[GoogleCodeExporter]

One more detail I forgot to mention --> the pango-view uses --backend cairo.

Original comment by martin.s...@gmail.com on 16 Jan 2013 at 1:14

[GoogleCodeExporter]

Looks like I've made a mistake in the title: it should have been *vertical* 
text, not horizontal -- i.e. from top to bottom. Sorry for the confusion.

Original comment by martin.s...@gmail.com on 19 Jan 2013 at 5:19

[GoogleCodeExporter]

This might be an issue with the shaping code. There are two OpenType features 
for vertical text layout, and I think I'm only activating one of it.

By the way, which version of HarfBuzz are you using? HarfBuzz support is 
required for correct @font vertical layout.

Original comment by g...@chown.ath.cx on 19 Jan 2013 at 5:49

[GoogleCodeExporter]

I'm using harfbuzz-0.9.9.

Original comment by martin.s...@gmail.com on 19 Jan 2013 at 9:24

[GoogleCodeExporter]

I have analysed the MotoyaLMaru font, and it looks like it does not have a 
functioning vertical substitution feature. Either it's broken or HarfBuzz does 
not correctly parse the GSUB table. Maybe uniscribe applies fallback 
substitutions so that doesn't matter, I don't really know.

Original comment by g...@chown.ath.cx on 4 Feb 2013 at 12:28

[GoogleCodeExporter]

On second look (with ttfdump), the font *does* have a number of substitutions. 
For some reason HarfBuzz doesn't recognize them. I'll ask Behdad, maybe he 
knows what's going on.

Original comment by g...@chown.ath.cx on 4 Feb 2013 at 12:31

[GoogleCodeExporter]

Found it. The font does not define a default language or default script. This 
is what HarfBuzz reports:

  Table  0 of 16: GSUB (0x0000010c+0x0000016c)
    1 script(s) found in table
    Script  0 of  1: kana
      No default language system
      1 language system(s) found in script
      Language System  0 of  1: JAN 
        No required feature
        1 feature(s) found in language system
        Feature index  0 of  1: 0
    1 feature(s) found in table
    Feature  0 of  1: vert; 1 lookup(s)
        1 lookup(s) found in feature
        Lookup index  0 of  1: 0
    1 lookup(s) found in table
    Lookup  0 of  1: type 1, props 0x0001

That means substitution only works if the script is forced to Katakana and the 
language to Japanese. At the moment libass does not do proper script run 
separation and does not determine a sample language, either. So it mostly 
relies on default script and default language being set up in the font. I have 
long planned to implement this and no I have a good reason for doing it, too. 
It's the right thing to do.

Note that I am not sure if this entirely fixes the problem, because punctuation 
characters are not part of the Katakana script.

Original comment by g...@chown.ath.cx on 4 Feb 2013 at 3:22

[GoogleCodeExporter]

I have implemented this now. The test case works fine, but it is not possible 
to fix this in all cases. The font really should be fixed.

Original comment by g...@chown.ath.cx on 4 Mar 2013 at 7:54

• Changed state: Fixed