layoutex (Paragraph Layout) - allow to build against HarfBuzz
Description
Attachments
relates to
Activity
UnicodeBot June 30, 2018 at 11:27 PM
Trac Comment 10 by —2014-09-12T16:45:25.922Z
Added a new section (linked from the layoutengine page on the userguide) - http://userguide.icu-project.org/paragraph-layout
UnicodeBot June 30, 2018 at 11:27 PM
Trac Comment 7.9 by —2014-09-11T01:29:29.477Z
Note that I actually shouldn't be breaking anyone by default. ICU 54 does NOT disable layout by default.
m1 did, but I reverted that as it would be more disruptive.
Replying to (Comment 7 dougfelt@…):
1) This looks like it enables layoutex by default if layout is set, in order that people using --enable-layout get the same behavior as before.
Defaults are same as before. If layout is on (default) you get layoutex. If layout is off (disable-layout), you don't get layoutex. Also same as before.
I think it would be better to transition people earlier rather than later. (Does ICU consider changes to people's make/config rules to be breaking changes for dot-releases?)
This mostly applies to whether `layout` is built by default or not.
If `--disable-layout` is chosen, I think it would be surprising to get `layoutex` without asking for it just because harfbuzz was installed, especially given the complex process for building layoutex.
I'm thinking that you should not build layoutex unless --enable-layoutex is explicitly set, and not build (and use with layoutex) layout unless --enable-layout is explicitly set.
Harfbuzz doesn't use `layout`. `icu-hb-le` replaces `layout`.
This way people who want to use layoutex with harfbuzz can switch their existing --enable-layout to --enable-layoutex, those who want to use layoutex with icu layout as currently will keep --enable-layout and add --enable-layoutex, and those who just use layout still get it (for now, at least) as before. People who switch early to layoutex+harfbuzz can do so and they don't need to change their flags again. This is the end state for people using layout-- the state you're supporting going forward-- and they just get there immediately with clean flags, which I think is a win.
OK, but people using layoutex today won't get it if it is off by default, because they will have to add --enable-layoutex. Right now people don't have to have --enable-layout to get layout or layoutex.
You can't just add `--enable-layoutex` to get layoutex-with-harfbuzz. It's more complex because icu-le-hb depends on icuuc. I think what probably should happen is to fold icu-le-hb into ICU, that way if HarfBuzz is detected, the default state can be that icu-le-hb is built and layoutex on top of it. If HarfBuzz is not detected, by default (in the future) it will build neither.
The way it's set up now, the early adopters have to add --enable-layoutex and switch to --disable-layout, and then when layout is dropped completely, they would want to remove --disable-layout (since it's a no-op, and just cruft at that point). True, existing users of ParagraphLayout don't have to change anything for now and they'll get the current behavior, but in the future they'd have to switch to --enable-layoutex anyway (because --disable-layout would cause it not to be built, and that's what they'd have to to in the interim to use harfbuzz).
Early adopters have to all of comment:4 actually. I don't think we are helping anything by disabling layout by default.
I just think the transition path is a bit cleaner if you transition the layoutex users now.
2) So I'm not completely sure how pkgconfig works. Is it only possible to build layoutex+harfbuzz using a copy of harfbuzz that has been installed on your system?
That is correct. However, they could actually set `ICULEHB_CFLAGS` and `ICULEHB_LIBS` to override whatever `pkg-config` finds (I can add this to the documentation).
What if you want to build layoutex for deployment on a system with a different version of harfbuzz? Or statically link harfbuzz in for deployment on systems that don't have it installed? Does this work for those scenarios?
You could statically link to HarfBuzz.. or, just build layoutex using your own build process.
UnicodeBot June 30, 2018 at 11:27 PM
Trac Comment 8 by —2014-09-11T00:22:03.981Z
(Does ICU consider changes to people's make/config rules to be breaking changes for dot-releases?)
ICU 54, labeled 54.1, is a full, major release, not a "dot release". (See http://userguide.icu-project.org/design#TOC-Version-Numbers-in-ICU)
UnicodeBot June 30, 2018 at 11:27 PM
Trac Comment 7 by dougfelt@f74d39fa044aa309—2014-09-11T00:08:29.640Z
1) This looks like it enables layoutex by default if layout is set, in order that people using --enable-layout get the same behavior as before. I think it would be better to transition people earlier rather than later. (Does ICU consider changes to people's make/config rules to be breaking changes for dot-releases?)
I'm thinking that you should not build layoutex unless --enable-layoutex is explicitly set, and not build (and use with layoutex) layout unless --enable-layout is explicitly set. This way people who want to use layoutex with harfbuzz can switch their existing --enable-layout to --enable-layoutex, those who want to use layoutex with icu layout as currently will keep --enable-layout and add --enable-layoutex, and those who just use layout still get it (for now, at least) as before. People who switch early to layoutex+harfbuzz can do so and they don't need to change their flags again. This is the end state for people using layout-- the state you're supporting going forward-- and they just get there immediately with clean flags, which I think is a win.
The way it's set up now, the early adopters have to add --enable-layoutex and switch to --disable-layout, and then when layout is dropped completely, they would want to remove --disable-layout (since it's a no-op, and just cruft at that point). True, existing users of ParagraphLayout don't have to change anything for now and they'll get the current behavior, but in the future they'd have to switch to --enable-layoutex anyway (because --disable-layout would cause it not to be built, and that's what they'd have to to in the interim to use harfbuzz).
I just think the transition path is a bit cleaner if you transition the layoutex users now.
2) So I'm not completely sure how pkgconfig works. Is it only possible to build layoutex+harfbuzz using a copy of harfbuzz that has been installed on your system? What if you want to build layoutex for deployment on a system with a different version of harfbuzz? Or statically link harfbuzz in for deployment on systems that don't have it installed? Does this work for those scenarios?
UnicodeBot June 30, 2018 at 11:27 PM
Trac Comment 4 by —2014-09-10T02:23:11.826Z
TODO: update the docs with how to build layoutex-with-harfbuzz. Briefly it works like this
Build and install a complete ICU with `--disable-layout`.
Build and install [HarfBuzz](http://harfbuzz.org).
Build and install the [icu-le-hb](http://harfbuzz.org) library.
Now, REBUILD the same ICU again, with `--disable-layout --enable-layoutex` (set pkg-config so it finds icu-le-hb AND the original ICU)
next, run `make install` JUST in the source/layoutex directory, to just intsall `libiculx` and `icu-lx.pc`
Now that layout is deprecated, we need to do something with layoutex.
It's a higher level layout library, which uses other ICU services (layout doesn't depend on ICU).
I think we should:
add a build option that still builds layoutex but not layout.
this build option will ''require'' HarfBuzz
fix the tests to only test layoutex but not layout directly in this case (or, test the harfbuzz wrapper!)
For those hitting this issue, here's what I recommended on the HB mailing list: