RFC: Support Pango text rendering by default

[filipnavara]

Currently there are two text rendering backends, a Cairo based one and Pango based one. Historically the Pango backend was incomplete and buggy, so it was hidden under --with-pango option. I think the code is now mature enough that we should remove all the warnings about it being unsupported. I'd even go one step further and make it the default as long as the Pango libraries are installed on the system.

Rationale:

• The Pango code handles complex layouts and it has RTL support. The Cairo code does not support this and most likely never will. Now that libgdiplus is used by System.Drawing.Common in CoreFX there's some demand for this feature (Ref.: https://github.com/dotnet/corefx/issues/28352).
• The Cairo backend uses text API that is called "toy" API not suitable for production use (Ref.: https://cairographics.org/manual/cairo-text.html)
• There are long standing issues with the Cairo code (PR cairo backend: MeasureString line wrap fix #5, PR Corrections to MeasureCharacterRanges, improvements to DrawString / MeasureString #137)
• Unit tests are slowly being added to verify the Pango backend behaviour (PR Add initial tests for GdipMeasureString and fix Pango text backend to pass them #268) and they fail completely on Cairo backend

cc @kasper3

[ghost]

make it the default as long as the Pango libraries are installed on the system

Should --with-pango option be removed so there is no opt-in or opt-out and on a build machine, autoconfig/cmake should fail without the required dependency present?

[filipnavara]

I don't think we should remove the Cairo support entirely yet. Accordingly it should be possible to specify --without-pango on machines with Pango installed to be able to test the Cairo code. Also, I have no idea how wide-spread is the use of --with-pango option in packing systems, so it's safer to keep it.

As for the reasons to keep the Cairo code for now:

• Pango is heavy dependency
• No Win32 build support for Pango
• Ubuntu 14.04 LTS on the build machines has too old Pango
• Distribution of Pango-based builds on macOS as part of other packages (eg. Mono) is not tested

[ghost]

so it's safer to keep it

If we are requiring a dependency, then apt, yum, emerge, pkgsrc, fbsdports, aports etc. will add it under required section of their package manifest. If we keep it optional, then they may or may not.

If this is the plan then I think then we need to have some API for System.Drawing to query if pango (an optional dependency) is available.

Otherwise what we are being presented inaccurate information in System.Drawing docs.
Otherwise we need to tell dotnet/docs guys to add this fact in remarks.

Much easier to make this dependency mandatory. cc @akoeplinger, @safern

[filipnavara]

Ok, I looked at various places where libgdiplus is built and I am starting to lean towards making Pango a required dependency. Here's what I found:

• Bockbuild (used to build Mono) already builds Pango. It's an ancient version, but at least that makes an excuse to update it and drop all the custom patches that were already merged and/or superseded by better patches.
• Vcpkg can build Pango, so it should be simple to use it there! (Thanks @hughbe & @akoeplinger!)
• Homebrew has a Pango formula, so it's a matter of simple reference.
• All Linux distributions supported by CoreFX have Pango in the package management system.

The only problem I found is that we now require Pango version >= 1.38 for pango_fc_font_map_set_config. That is not available on Debian Jessie, Ubuntu 14.04 and possibly other systems. At the expense of some performance penalty it should be possible to use FcConfigSetCurrent and some mutexes as a substitute.

[qmfrederik]

That is not available on Debian Jessie, Ubuntu 14.04 and possibly other systems.

One reason to keep support for Debian Jessie would be that the default Docker container images for both Mono and .NET Core are based off Debian Jessie.

If the pango_fc_font_map_set_config method is difficult to subsitute, another option may be to just create a Pango 1.38 or later package for Jessie/Ubuntu 14.04.

[filipnavara]

Dropping support for Jessie/Ubuntu 14.04 is not an option as long as they are supported by .NET Core. Since Ubuntu 14.04 is LTS release we talking at least another year. I'm not familiar with the packaging systems and the respective policies of these distributions, so I didn't really consider it an option to get newer Pango on these systems.

I'll look at the possibility of substituting pango_fc_font_map_set_config, but it may be difficult. Other option is just not to support custom font collections and return an error.

[qmfrederik]

Other option is just not to support custom font collections and return an error.

That sounds reasonable - I'm not sure how often custom font collections are used, getting a PlatformNotSupportedException or something similar (on the managed side of things) indicating this feature is available on a newer version of Debian/Ubuntu sounds acceptable, plus the problem will be void a year from now when support for these distros is removed.

[filipnavara]

I'd also consider it reasonable. However, two things should be considered:

• It would change behaviour if the library is updated on these systems. Previously they would support custom fonts, but have broken rendering of complex layouts. Now it would be able to render complex layouts, but it would lose custom font support. (No one will update the official libgdiplus packages on these platforms though :D)
• The CI machines running Jenkins and Travis are currently running on Ubuntu 14.04, so we would lose part of the tests. May not be a big deal since they would still run on Travis+macOS at least.

[marek-safar]

/cc @migueldeicaza please review

[migueldeicaza]

This is fine