Freitag, 19. August 2011

VLC win32 test build

I've built VLC for Windows against the latest code of the fonts branch, and of course with the FriBidi and HarfBuzz support from mainline. This means:

  • Arabic and Hebrew text works correctly (but no HarfBuzz support)
  • OpenType shaping works
  • The annoying "Building font cache" message is gone
However, currently only embedded fonts are supported. Usually most fonts are embedded in Matroska files, so this often is not a big issue.

Download the test build

Update: Download replaced by a new build with HarfBuzz support.

9 Kommentare:

  1. I tried the build but it seems a little strange. I tried MKVs with embedded fonts with no luck. I tried separate ASS files with no luck. Nothing appears on the video. And SRT rendering still relies completely on buggy FriBiDi. Maybe it's because I'm using a 64bit Win7? Or does it require some changes in the registry for the new dlls?

    AntwortenLöschen
  2. MKVs with embedded fonts should work fine, external ASS/SSA subtitles should not (no fonts available). However, the embedded fonts need to actually cover the glyphs/codepoints that are needed for rendering, maybe that is your issue here?

    SRT rendering doesn't use libass at all (yet?).

    Windows 7 64-bit shouldn't be an issue at all. I'm using this as well.

    I'll likely post a new build that can use system fonts soon.

    AntwortenLöschen
  3. My bad. The files I was testing didn't have any fonts. MKVs with embedded fonts work well, but does it use a different way of telling the direction of a line than FriBiDi's 'auto-detection'?

    Any plans/intentions to use libass to render SRT in VLC?

    Keep up the good work.

    AntwortenLöschen
  4. Yes. The "font encoding" in the style is used as a hint. It can also be overridden with the \fe tag.

    Arabic or Hebrew encodings (177/178) force RTL base direction and ANSI encoding (1) forces LTR base direction. Everything else uses autodetection.

    AntwortenLöschen
  5. By the way, FriBidi does not just use some kind of proprietary autodetection. This is specified in rules P1-P3 of the Unicode Bidirectional Algorithm.

    Regarding SRT using libass, see the recent posts by Mathieu Velten on vlc-devel.

    AntwortenLöschen
  6. Forcing RTL base direction with those encodings causes some VSFilter compatibility problems. People have been using punctuations in a reversed order as a workaround for VSFilter's default LTR direction. I believe that can not be rendered correctly unless the base direction remains LTR, which can be achieved with auto-detection. I know this seems bizarre but I think users will need some sort of backwards compatibility for their old subtitles.

    Mathieu's patch sounds interesting. Can't wait to test it.

    AntwortenLöschen
  7. Yes, VSFilter seems to assume LTR base direction in most cases. I'm not planning do the same in libass to get "bug-for-bug" compatibility - VSFilter is horribly broken with to bidirectional text anyway.

    However, you can simply use ANSI font encoding. I didn't have any issues with non-latin text with that encoding under VSFilter. This seems to be a pretty useless setting nowadays.

    MPlayer already has an interface for overriding this, something similar should probably be added to VLC.

    AntwortenLöschen
  8. I know that VSFilter is horrible at bidi and I wasn't asking for a bug-for-bug solution. I just didn't understand the reason behind forcing certain base directions instead of letting it up to the auto-detector. Setting it to auto-detect will (AFAIK) provide compatibility with VSFilter subs as well as proper ones. But if what you did was necessary then never mind VSFilter.

    AntwortenLöschen
  9. Well, punctuation at the end of the line is definitely a problem. LTR base direction places a punctuation character at the logical start of the string at the very left, autodetection treats punctuation as a neutral character and includes it in the following run of RTL text, so it has to come at the logical end of the string. For proper rendering with VSFilter, you have to reverse the placement of the punctuation.

    I have an Arabic fansub sample with exactly that problem, which shows most end-of-line punctuation at right instead of at the left with libass. Forcing LTR base direction fixes it.

    AntwortenLöschen