pango +quartz cannot build 64-bit

[pguyot@…]

64 bits versions of Carbon framework does not have the atsui functions that cairo needs (see #17040). The attached patch introduces a new variant, +no_atsui, that removes support for atsui in pango. This variant is automatically selected when +universal is set and a 64bits platform is in the list of architectures.

Please note that this is not as satisfying as it could be. cairo +universal includes the functions that pango needs for 32bits architectures, and ideally pango +universal should do the same, i.e. provide atsui support for 32 bits and not for 64 bits (the +no_atsui disables it for all archs).

[pguyot@…]

Actually, disabling atsui means that no font will be displayed with +no_x11, so it's no such a good idea. I ported pango to use CoreText. However, the result isn't as good as the 32bits version with ATSUI. See screenshots.

[pguyot@…]

gtk-demo 32bits (left) and 64bits with pango +core_text (right)

[pguyot@…]

Simple test program that checks ascent, descent, underline position and thickness for ATS and CoreText APIs. They provide the same values.

[pguyot@…]

New screen shot with the bug fix in the patch. Still not as good as the ATS version.

[pguyot@…]

There was a bug in my core_text patch for pango. I attached the new one (patch-pango-coretext.diff). I did put -ascent instead of descent.

I checked with a small program (test_coretext.m) that ATS and CoreText return the same values for all the functions used in the patch (I tested with LucidaGrande and GillSans fonts).

However, this still isn't perfect (see pango-core_text-2.png). I cannot figure out why the lines height differ, or why the patched pango does not handle as well as the ATS pango unicode text (see the Greek sample) or rendering of ligatures (fi). It might be a problem with cairo.

Maybe it's time to transmit this issue upstream...

[pguyot@…]

Yet another bug fix in the patch (forgot a * PANGO_SCALE).

[jmr@…]

Has this been sent upstream? I gather from comments in various places that they want to support Core Text.

[ryandesign@…]

I had not yet attempted to deal with a 64-bit pango since 64-bit cairo was still problematic.

[ryandesign@…]

I have now  reported this to the pango mailing list.

[ryandesign@…]

Has duplicate #19115.

[mcalhoun@…]

Cc Me!

[anonymous]

Milestone Port Bugs deleted

[ryandesign@…]

Has duplicate #20022.

[jmr@…]

This patch doesn't work any more. I have 1.24.2 installed i386/x86_64 universal, so it worked with that version.

[jmr@…]

Replying to jmr@…:

This patch doesn't work any more. I have 1.24.2 installed i386/x86_64 universal, so it worked with that version.

Sorry, false alarm, it was actually a bug in muniversal. The patch still seems to work fine.

[ryandesign@…]

Has duplicate #20416 which was reported against Snow Leopard which builds 64-bit by default so this becomes a bigger problem there.

[ryandesign@…]

Replying to ryandesign@…:

I have now  reported this to the pango mailing list.

Behdad advised me to file a  pango bug report.

[macports@…]

Cc Me!

[ken@…]

Replying to ryandesign@…:

Behdad advised me to file a  pango bug report.

Behdad's reply said that it'd be in 1.26, but it looks like it's in 1.25.5 (and perhaps an even earlier version). But it still didn't work for me; the pango-basic-atsui.so library was being built for i386 only.

I got it working by monkeying with the Portfile (my first attempt at Portfile hacking) and removing the line that forced ac_cv_header_Carbon_Carbon_h=no for x86_64.

[ken@…]

Patch against Portfile from 1.24.5

[ken@…]

Cc Me!

[whitley@…]

Cc Me!

[Damien@…]

Cc Me!

[MacPorts@…]

Cc Me!

[eh88@…]

Cc Me!

[whitley@…]

I note that pango 1.26.0 was released today, which ostensibly fixes this issue. I haven't had time to try it out yet, however.

 http://ftp.gnome.org/pub/GNOME/sources/pango/1.26/pango-1.26.0.tar.bz2

[vitaly@…]

Cc Me!

[vitaly@…]

Portfile for pango-1.26. At least it builds on Snow Leopard

[markus@…]

Cc Me!

[ryandesign@…]

I did not look at your 1.26 portfile but I did update the port to 1.26 in r58293. Does that fix anything?

[whitley@…]

pango 1.26 +no_x11+quartz works for me on 10.6.1. Thanks!

[ken@…]

Replying to ryandesign@…:

I did not look at your 1.26 portfile but I did update the port to 1.26 in r58293. Does that fix anything?

This still isn't quite complete; the current portfile still only builds the ATSUI for the i386 architecture. Please see the 3rd chunk of my 1_25_5.diff file for the solution. Specifically, the portfile needs to omit the following line:

lappend merger_configure_env(x86_64) ac_cv_header_Carbon_Carbon_h=no

This forcibly omits the ATSUI module on x86_64, which used to be correct when the ATSUI module really ... well, used ATSUI. Now the "ATSUI" module uses CoreText and can be built on x86_64 without problems.

[perry@…]

Replying to ken@…:

This still isn't quite complete; the current portfile still only builds the ATSUI for the i386 architecture. Please see the 3rd chunk of my 1_25_5.diff file for the solution. Specifically, the portfile needs to omit the following line: lappend merger_configure_env(x86_64) ac_cv_header_Carbon_Carbon_h=no

Removing this line worked for me.

[ryandesign@…]

Ken, I did see that change in your diff but did not apply it because a) it didn't make sense to me why that change would be needed for x86_64 but not for ppc64, and b) the only pango-using program I use, graphviz, produced worse output and a bunch of error messages when I made that change. But I guess this just means graphviz has some bugs relating to pango quartz.

For now, pango has been downgraded back to 1.24.5; see #21624. When that's resolved and we can upgrade to 1.26.x again, I believe I will address your concerns by removing the muniversal portgroup from the portfile entirely. It was only added originally in order to allow us to differentiate between 32-bit and 64-bit builds to allow the former to have quartz while the latter did not; with that distinction no longer necessary, using the muniversal portgroup is no longer necessary either.

[ken@…]

Replying to ryandesign@…:

a) it didn't make sense to me why that change would be needed for x86_64 but not for ppc64

Good point. The core issue is that there is no ATSUI in 64-bit Carbon, but now that Pango's "atsui" backend uses CoreText, it should be safe to enable it for ppc64 also.

b) the only pango-using program I use, graphviz, produced worse output and a bunch of error messages when I made that change. But I guess this just means graphviz has some bugs relating to pango quartz.

Can't help you there. :)

I believe I will address your concerns by removing the muniversal portgroup from the portfile entirely.

OK, I'm still green on all of this, but I think removing "universal" here would not be workable for me; I need a universal Pango because I'm linking to it from both 32-bit and 64-bit binaries. With the offending configure line removed, I'm able to write code that uses Pango for both architectures.

[ryandesign@…]

Replying to ken@…:

OK, I'm still green on all of this, but I think removing "universal" here would not be workable for me; I need a universal Pango because I'm linking to it from both 32-bit and 64-bit binaries. With the offending configure line removed, I'm able to write code that uses Pango for both architectures.

I'm not suggesting removing universal support. I'm saying I want to remove the code from the port that uses the muniversal portgroup for universal support, thus allowing the port to return to using the default universal variant like it used before.

[pf_moll@…]

Cc Me!

[ryandesign@…]

Has duplicate #21812.

[ryandesign@…]

Has duplicate #21954.

[jpenney@…]

Cc Me!

[palimm@…]

Cc Me!

[markdigital69@…]

Cc Me!

[jmr@…]

r59767

[macports@…]

This downgrade to 1.24.5 doesn't help much. Yes it builds, but it is too old to work with the other ports:

dyld: Library not loaded: /opt/local2/lib/libpangocairo-1.0.0.dylib
  Referenced from: /opt/local2/bin/gtk-demo
  Reason: Incompatible library version: gtk-demo requires version 2601.0.0 or later, but libpangocairo-1.0.0.dylib provides version 2401.0.0
Trace/BPT trap
$ port installed gtk2
The following ports are currently installed:
  gtk2 @2.18.2_0+no_x11+quartz (active)
$ port installed cairo
The following ports are currently installed:
  cairo @1.8.8_0+macosx+no_x11+quartz (active)
$ port installed pango
The following ports are currently installed:
  pango @1.24.5_0+macosx+no_x11+quartz (active)

[macports@…]

Never mind, forcefully rebuilding gtk2 solved the issue.