Optional bidi support

[tot-to]

If possible, please make the dependency on fribidi optional. There is no point to install it for those, who don't use and understand languages with right-to-left direction.

[realfinder]

Duplicate here https://code.google.com/p/libass/issues/detail?id=82

[tot-to]

Sorry, I didn't know, there are two bugtrackers for libass.
Anyway, not being a Google user, I can't post there.

From the point of view of a user or a distribution maintainer it's actually another way around: less libraries and less code means less potential problems.

I probably can survive with fribidi hard dependency. But I usually try to exclude unusable (for me) software. And in most cases such a possibility is provided.

[astiob]

Don’t worry about not knowing about the old tracker, that’s fine. (It’s going to go down soon anyway thanks to Google’s incredible generosity, sigh. Hopefully we’ll make an archive copy somewhere before it does.)

But, as said in the linked discussion, fribidi is a really simple and small library that’s easy to get and install. If you think otherwise, we’ll be curious to hear why.

And while dependencies can (in general) make life harder for maintainers, it’s easier for everyone when there’s less choice. If there isn’t a choice of enabling or disabling fribidi, a maintainer who isn’t an expert in this area doesn’t need to think whether they should enable it, a user doesn’t need to figure out why there are two different libass versions and what makes them different, and a user who does need bidirectional writing doesn’t need to check carefully whether the libass package they’re getting has fribidi enabled and to find out where they can get one that does. Less choice means fewer potential problems. You mentioned less code: that does mean fewer potential problems, too, but more choice means more code.

---

And now for a completely separate perspective. Does any of your Web browsers support building without bidirectional writing support? In my opinion, and I’m sure I’m far from the only one who thinks so, software that doesn’t support bidirectional writing doesn’t just have fewer optional features; it’s wrong. It has a bug. A missing mandatory feature. Even if you don’t currently expect yourself to require bidirectional writing, you never know what files you may encounter in practice. And if you’re a maintainer, it’s awfully bold to assume that none of your users will ever encounter bidirectional writing. In any case, if it so happens that a user (be it you or someone else using your build) does encounter bidirectional writing, merely skipping the bidirectional algorithm and rendering the text left-to-right is just flat-out wrong.

(Usually, when you disable a feature in a program or library, it means you can’t do something in the program: if you try, it tells you support is not compiled in. This can’t be done for bidirectional writing. Without fribidi, we’d have no way to even detect when applying the full bidirectional algorithm would make any changes at all—even if we wanted to refuse to render the whole line or file, we’d still need to be able to do that much.)

Of course, you can argue that it’s your right as a user to shoot yourself in the foot and get incorrect rendering. I… think I can agree with that! But from a developer’s perspective, this has plenty of drawbacks and no benefits in the case of fribidi: users who forget they chose to shoot themselves in the foot can and will file bogus bug reports; users who unknowingly use builds made by other people who’d chosen to shoot themselves in the foot will be disappointed in libass, file bogus bug reports, ask unnecessary questions such as “how do I enable correct display of Arabic?”—or even spread word about how horrible libass is without even bothering to ask us first and find out that it’s actually their own problem; and we actually need to add extra code and perform extra testing to support all of this! I hope you can see why we’re reluctant to do this. (And we also simply like our software to be correct regardless of the user’s choices.)

[ghost]

To be fair, I wouldn't mind a small embedded copy of fribid or something similar, since fribidi's build system is really damn broken, and most things in the fribidi git repo are probably unneeded. (Or even better, make some sort of fribidi fork that doesn't suck.)

[grigorig]

If we skip Arabic fallback shaping, coming up with a fribidi replacement may not be very hard. Just saying... maybe such a thing could even be added to HarfBuzz. What do you think, @behdad? Do you think bidi is out of scope for HarfBuzz or would you accept code that provides APIs for bidi?

[khaledhosny]

What is so broken about fribidi?

[ghost]

Most annoyingly, we've reported a severe bug 1 year ago (caused by a dumb anti-feature): https://bugs.freedesktop.org/show_bug.cgi?id=79385
It was fixed after 2 months, but even after 1 year after the fix, there is still no new release, even though we requested a new release. Such a semi-broken, stale dependency is not nice.

[ghost]

(And yes, this was the main blocker for the new entirely stale libass threading branch.)

[khaledhosny]

A friendly reminder about the release does not hurt (and it is maintained by the same person maintaining HarfBuzz anyway). cc @behdad

[behdad]

I don't have time to make a release. Khaled, feel like doing?

[behdad]

If we skip Arabic fallback shaping, coming up with a fribidi replacement may not be very hard. Just saying... maybe such a thing could even be added to HarfBuzz. What do you think, @behdad? Do you think bidi is out of scope for HarfBuzz or would you accept code that provides APIs for bidi?

It's out of scope in HarfBuzz, exactly because FriBidi exists. It needs someone to give it some love. I don't have time for it.

[behdad]

To my defence, the tone of comments on https://bugs.freedesktop.org/show_bug.cgi?id=79385 didn't inspire me to go out of my way to find time to make a release either...

[khaledhosny]

Sure, why not.
On Aug 3, 2015 1:35 PM, "Behdad Esfahbod" notifications@github.com wrote:

I don't have time to make a release. Khaled, feel like doing?

—
Reply to this email directly or view it on GitHub
#180 (comment).

[ghost]

To my defence, the tone of comments on https://bugs.freedesktop.org/show_bug.cgi?id=79385 didn't inspire me to go out of my way to find time to make a release either...

That was me. But it's not my problem if Linux infrastructure is regarded a total joke.

[astiob]

@wm4 Calm down, please. Being rude isn’t going to (and didn’t) help this issue or our relations in the future either.

Besides, you don’t seem to have any issues with harfbuzz, and the only actual objection you have provided against fribidi is that it hasn’t been released since the threading fix. That’s certainly an issue, but it’s nowhere near as bad as you made it sound earlier. Personally, I have never had any issues with fribidi, and I see no sign of brokenness in the Homebrew formula for it either (unlike a lot of other software).

[astiob]

@behdad @khaledhosny May I ask, though, out of genuine interest, what makes releasing fribidi different to releasing harfbuzz?

[ghost]

Calm down, please. Being rude isn’t going to (and didn’t) help this issue or our relations in the future either.

Except there isn't really an excuse in letting fribidi, which is apparently a major part of the Linux desktop core infrastructure, bitrot like this. It was hard to get them fix a trivial issue (that was really a badly designed anti-feature that just had to be disabled by default), and it was even harder to get them make a release that includes the fix. Now there's still no release, and pushing a bit made it less likely that this problem gets resolved. What could you reasonably do? Just wait 2 more years? Stop your own development? This is like a lazy person who gets deeply offended when someone else tells the person to get some work done. Now tell me that's not ridiculous.

In general, it's our fault for depending on such a library, of course. Indeed, other important and central Linux software isn't depending on it, but has its own embedded copy (e.g. https://git.gnome.org/browse/pango/tree/pango/mini-fribidi). Pango/GTK is not just some 3rd party library like libass, but it's something everyone uses - and they chose not to have a dependency on the "official" fribidi package. I wonder why.

[ghost]

May I ask, though, out of genuine interest, what makes releasing fribidi different to releasing harfbuzz?

Nothing important depends on the "official" fribidi.

[khaledhosny]

That is not the kind of “friendly” reminder I had in mind, and it makes me (someone who has no stack in this at all) much less enthusiastic about volunteering to make a release.

[astiob]

Pango/GTK […] chose not to have a dependency on the "official" fribidi package. I wonder why.

So do I. Guess what, @behdad should know, seeing as it is himself who made Pango’s copy judging by the README.

Nothing important depends on the "official" fribidi.

I don’t know how you define important, but doing zypper rm fribidi on my (old) openSUSE offered me to delete some 38 packages other than libass that depended on it, including a whole bunch of GNOME, gstreamer packages and libraries I’ve never heard of. Admittedly, far from all of these packages likely have direct dependencies on fribidi, but it is nevertheless a vital component for all of them.

[ghost]

If there's anything factually wrong about what I said, please correct me.

Sorry about feeling a bit sour after trying to get this bug fixed for 14 months, only to get reactions that you are apparently mad about not being asked "nicely" about it, despite never doing anything.

[khaledhosny]

FYI, fribidi 0.19.7 has been released.

[behdad]

Thanks Khaled.

[astiob]

Thanks!