The liftiff-based workaround is not as bad as it sounds since python's PIL requires it. That Image.show() works at all means libtiff is around. Writing with FT_Bitmap_Convert likely will be slower.

Apparently Ubuntu/Debian has been shipping the region_t addition for some years for python 3 for the overlap check, so if you are on Ubuntu/Debian and using python 3, the wordle example may work as is without upgrading pycairo. Fedora certainly does not ship the patch.

under pycairo 1.11+

with older pycairo.

alpha drawing with older pycairo

alpha drawing with current pycairo.

This fixes the last issue; I don't particularly want to workaround the libtiff dependency for mono(1-bit) drawing, so this is all.

To try to get an exact match, I changed the number of words back to 100, seed the random number to be the same, plus this change (the original example flp the y axis a few times...):

--- a/examples/wordle-cairo.py
+++ b/examples/wordle-cairo.py
@@ -153,7 +153,7 @@ if __name__ == '__main__':
             for dx,dy in spiral():
                 c = .25+.75*random.random()
                 x = int(x0+dx)
-                y = int(y0+dy)
+                y = H - int(y0+dy)
                 checked = False
                 I.flush()
                 if not (x <= w//2 or y <= h//2 or x >= (W-w//2) or y >= (H-h//2)):

and get this comparison from imagemagick's compare.

This shows that the first few tiles from the center of the spiral are identical, but pixel differences do accumulate, and after about 5 tiles, the differences are enough that the tiling of the spirals no longer matches. Just for interest.

I cannot get a time comparison - the cairo based example is possibly about 20x faster,

output of lcd example. I added the lcd_v case also.

The output of the re-written glyh-vector example. I'll tidy up the code and push at some point.
However I found the outlines is strictly speaking wrong (#58)
and the relative scale of glyph-vector-2 between the outline and the bitmap is also wrong
( #59 ) .

edit correct figure

The bitmap + outline example; currently still in png; need to add some svg related code...

Finished. Please review and merge. @rougier

@rougier Added 8 commits, a few to do with the review and a few fixes the cubic curve/alignments. I don't think there are any important issues; so I'd say just merge.

Nope, still need to test.

And to test, I need to instal pycairo > 1.10. Unfortunately the "official" version from https://www.cairographics.org/pycairo/ seems to be stuck at 1.10.0. What version do you use actually?

No luck in installing pycairo on OSX. Need to investigate. I'll merge and see that later.

That's a pity. Do you already have cairo instead from homebrew or macport? It is not trivial to build cairo by hand. The last time I cross-compile cairo for mac was a bit over a year ago. You need to have libpng, freetype, fontconfig, pixman, first, in that order. and possibly some of g*, such as glib2 . After that then you can talk about pycairo. I suspect you can get pycairo via homebrew/macport? That's easier. May not be the latest but as I said, if you use python 2.x, the antique version pycairo works. Seems max os x still ships multiple versions of python? So many things on linux depend on cairo, it is quite trivial on linux.

Oh, and now they are on github, and fairly responsive/active again under a new team, https://github.com/pygobject/pycairo , I am sure they want to know about difficulty of installing.

I'm using Python 3. I tried the homebrew version (that works) but it is stuck at 1.10. Same from pip.

From latest release, I got an error when building:

duplicate symbol _Pycairo_Content_Type in:
    build/temp.macosx-10.12-x86_64-3.6/cairo/error.o
    build/temp.macosx-10.12-x86_64-3.6/cairo/cairomodule.o
...
    (lot more duplicate symbols)

I need to investigate when I've some free time.

It was a missing extern in the end. Build is fine now.

Shadow is missing in the emoji-color-cairo.py in the final png output. But the Image.open(...).show() tends to suggest it is here (even if display is wrong)

Image.open(...).show():

emoji-color-cairo.png:

Note there are spurious pixels below smileys (you have to zoom to see them)

I see you already filled the sierra build issue and had it merged ( pygobject/pycairo#36 ). I was going to filed & @ you to supply the details. Turn out I haven't pulled since clone so my pycairo is still at v1.12.0-5-g29805af at two weeks ago; the line affecting you was added on Tuesday this week. Wouldn't have helped as that still builds fine on linux.

You have found an interesting issue with the emoji font. version 10.0d3e2 (shipped with Yosemite I think, the one I usually test with) is okay; I grabbed a ttc from the internet, supposedly 12.0d17e1 , and it shows as yours - Image.open(...).show() shows the extra shadows below, and indeed there are a few stray pixels.

The stray pixels are real; but the Image.open(...).show() extra-shadow appearance seems to be a bug with Image.open(...).show(). On Linux, Image.open(...).show() seems to be calling pngtopam and convert to a pam in the /tmp directory, them run imagemagick's display on the temp file. I can get the extra shadow by running the pngtopam on the 12.x version png mannually. I think it is a bug with pngtopam. gimp shows the transparent background, the stray pixels, but not the extra-shadow; flattening the image does not make the shadow appear.

So the couple of stray pixels seems to be apple's flaw in updating the font bettween Yosemite and Sierra; the extra-shadow is a bug in pngtopam (at least on Linux). Do you have pngtopam on Mac OS X? try 'pngtopam emoji-color-cairo.png > broken.ppm' then display the latter.

Using ImageMagick and converting the png to ppm I get the broken image so it's unlikely a bug if the same extra shadow appears using two different converters.

It is not two different converters - imagemagick calls pngto* . Try moving your pngto* programs aside, and you will find that imagemagick stops working. You are seeing the same bug. It is one bug, in pngtopam . Try using somerthing that does not call pngto* .

On linux, imagemagick calls pngto* inside libMagickCore .

Didn't know that. Using the -flatten flag seems to fix the bug but still now shadow.

I used xv and gimp to looked at it also. xv is older than imagemagick so I am fairly sure it doesn't use it, but I don't expect you to have xv since it is X11 based. gimp doesn't show the extra shadow either. Surely on Mac OS X there are image viewers which does not use imagemagick?

Since python PIL's Image.open("emoji-color-cairo.png").show() calls imagemagick's display, I am fairly sure they are just the same thing. At what point imagemagick get confused, I don't know. On linux, Image.open("emoji-color-cairo.png").show() results in a temportory file in /tmp which is opened by display.

It seems that I was wrong. PIL has its own png reader ( PIL/PngImagePlugin.py ) . So we do have two sets of applications, PIL and imagemagick on oneside, xv and gimp on the other, which reads the png differently.

Image.show 's docstring mentions that it uses display to to display on unices.

        On Unix platforms, this method saves the image to a temporary
        PPM file, and calls either the **xv** utility or the **display**
        utility, depending on which one can be found.
 
        On macOS, this method saves the image to a temporary BMP file, and opens
        it with the native Preview application.

Okay, I think I got to the problmem with the alpha channel. PIL Image has its own image writing code ( PIL/PpmImagePlugin.py , PIL/BmpImagePlugin.py ) to saves to bmp or ppm , before launching the display code. The image writing code ignore alphas. So the thing is that programs which ignores the alpha channel sees the extra shadow. And you do have 3 programs which ignore the alpha channel, convert in its default mode, PIL, and netpbm-progs.

Apple put some garbage there and also says that part is transparent, that's pretty much it.

Issuing a pull for the display problem - @rougier : would be nice if you get it a try on Mac os .
python-pillow/Pillow#2509