[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#894159: OpenTTD, icu and ParagraphLayout



On Sun, Apr 29, 2018 at 10:27 PM Matthijs Kooijman <matthijs@stdin.nl>
wrote:
> I'm the maintainer of the OpenTTD package, and stumbled on this bug
> report, which refers to my package as the last user of the
> ParagraphLayout API in icu.
   Indeed. That's why I need the icu-le-hb loop which seems to be a dying
project.

> First off: I have a pending new upstream version of OpenTTD that I'd
> like to upload, but I don't want to interfere with this transition.
> Should I hold it off, or do we expect that resolving these issues will
> take a while and should I just upload it now (and have it build against
> the current icu version)?
   The transition will happen soon. I'm re-recompiled almost everything to
really start it.
I'm biased a bit. The current OpenTTD version in Sid compiles fine. If you
can make the package available before upload or can check the compilation
yourself with the experimental version of ICU then it would be good.
I think there's still a day or two before the actual transition so I think
you can upload OpenTTD after the mentioned test above.

> As for the layout issue, AFAIU the following is the case (but correct me
> if I'm wrong):
>    - ICU used to offer a layout API (which handles the layout of a single
>      line of text).
>    - Harfbuzz offers a similar layouting engine.
>    - icu-le-hb is a separate piece of code that offers the (now removed)
>      ICU layout API, by using Harfbuzz
>    - ICU offers a ParagraphLayout API (which handles wordwrapping a piece
>      of text). This code needs the (now removed) layout API, so currently
>      it can only be built on top of icu-le-hb.
  This is the exact case. ICU removed the (long [since the 54.1 release]
deprecated) Layout Engine API[1] and please don't ask me why they kept the
dependent Paragraph Layout API.

> This gives a dependency chain where Harfbuzz optionally depends on ICU,
> icu-le-hb depends on Harfbuzz and (I presume) ICU, and where
> ParagraphLayout depends on icu-le-hb. Since ICU and ParagraphLayout live
> in the same source package, this results in a circular dependency, which
> needs two successive builds of the ICU package (once without
> ParagraphLayout and once with), building icu-le-hb in between, to make
> this work.
  This is also correct and described by ICU upstream[2].

> This does seem like a weird situation, also for ICU upstream. Do they
> have any plans to resolve this?
  I don't know more about this. I still need to check the ICU 61.1 release
though. But I think it was not really used and they just step over it. At
last there's no alternative recommendation from ICU upstream.

> One suggested solution (by László) is to integrate icu-le-hb into the
> ICU source package, so the double compilation could at least happen
> inside the ICU source package instead of having to be managed
> externally. I do wonder: If icu-le-hb is properly integrated into the
> ICU build system (probably needs integration upstream to be feasible),
> this double build could be removed, right?
  I meant the double source package compilation (our tools can handle
multiple sources for one package for a while).
The whole story is the following. ICU removes the Layout Engine part due to
its bunch of bugs and not being maintained. Someone takes the last version
and begin fixing bugs. Then it's abandoned as well, last release is from
2015. It was me who patch it for ICU 60.2 so I've doubts there's any plan
to re-integrate icu-le-hb back to ICU itself.

> One alternative I can imagine is to move the ParagraphLayout code from
> the ICU library (where it seems a bit out of place now) into the
> icu-le-hb code. AFAICS that would resolve the circular dependency (or
> does Harfbuzz need ICU and is that still a problem? That seems hard to
> fix in any case...).
  As icu-le-hb is quite dead at the moment you need to find someone who
would fix its bugs first and may integrate the Paragraph Layout API into
it. I don't have any resources to do it, but if you know anybody then
please tell.

> Another solution is of course to disable ParagraphLayout. László also
> asked if OpenTTD, being the only user of this API, could migrate to
> another solution. I've discussed this with OpenTTD upstream yesterday,
> and they were already aware of the layout API removal and have been
> casually looking at Harfbuzz and Pango as a replacement, but they do not
> see an easy solution yet. ParagraphLayout seems to fit their usecase
> quite neatly: they need internationalized word-wrapping of text (e.g.
> also supporting right-to-left locales). Harfbuzz does not seem to offer
> that, and Pango seems heavy-handed (and might not be easy to adapt to
> OpenTTD's SDL renderer, and might not be portable enough).
  This is bad to read. I had the hope there's an easy solution and/or the
replacement might be already in the making.

> Neither me or upstream has much experience in this field, perhaps you
> have a different suggestion for an alternative?
  I don't know any other alternative. Only OpenTTD uses the Paragraph Layout
API and it makes me wonder what other solution the other projects use? I
may think other games like Lincity-NG[3] also need internationalized text
placement and/or LibreOffice still need to handle this as well. Do these
have an alternative solution?

Cheers,
Laszlo/GCS
[1] http://userguide.icu-project.org/layoutengine
[2] http://userguide.icu-project.org/layoutengine/paragraph
[3] https://github.com/lincity-ng/lincity-ng


Reply to: