From ldo at geek-central.gen.nz Thu Oct 1 19:21:33 2015 From: ldo at geek-central.gen.nz (Lawrence D'Oliveiro) Date: Fri, 2 Oct 2015 15:21:33 +1300 Subject: [cairo] Cairo In Ubuntu 14.04? In-Reply-To: <20150930224245.6c40ce5f@theon.geek-central.gen.nz> References: <20150930224245.6c40ce5f@theon.geek-central.gen.nz> Message-ID: <20151002152133.540b5010@theon.geek-central.gen.nz> On Wed, 30 Sep 2015 22:42:45 +1300, I wrote: > ... as well [as] quality problems, compared to what I get when I run > the same script with the same inputs on my machine (Cairo version > 1.14.2 under Debian Unstable). Actually, looking again at the client’s example, perhaps I was a little hasty in describing them as quality “problems”. The client was doing a comparison with resizing in Photoshop, and yes, their result looks smoother if you compare them side-by-side. Perhaps Cairo itself cannot offer the same breadth of quality options, but I could probably match that by resorting to direct Pixman calls. From ldo at geek-central.gen.nz Thu Oct 1 22:26:50 2015 From: ldo at geek-central.gen.nz (Lawrence D'Oliveiro) Date: Fri, 2 Oct 2015 18:26:50 +1300 Subject: [cairo] PATCH cairo-www: Bring External Image Into Wiki In-Reply-To: <20150907051245.GB6510@bryceharrington.org> References: <20150815185255.37bcb430@theon.geek-central.gen.nz> <20150906131346.0eeac1ef@theon.geek-central.gen.nz> <20150907051245.GB6510@bryceharrington.org> Message-ID: <20151002182650.42db595c@theon.geek-central.gen.nz> On Sun, 6 Sep 2015 22:12:45 -0700, Bryce Harrington wrote: > Although I'd say anything that may have licensing issues > we probably won't want to link to. Anyway, post patches to fix those > things up and we can review as we go. OK, here is a resubmission that gets rid of that external image altogether, and substitutes my GIF animation. I can tweak the format of the GIF image as necessary (is it too wide?). I generated it from a Python script using Qahirah. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-replace-external-image-with-GIF-animation-within-wik.patch Type: text/x-patch Size: 30770 bytes Desc: not available URL: From lobingera at gmail.com Sat Oct 10 10:35:57 2015 From: lobingera at gmail.com (Andreas Lobinger) Date: Sat, 10 Oct 2015 19:35:57 +0200 Subject: [cairo] building on OSX El Capitan 10.11.1 beta? Message-ID: Hello colleagues, two small things: 1) Does the test suit contain a regression test for text_path? 2) Are there known build problems on OSX 10.11.1? I'm asking, because over here at the adaptation of julia language to libcairo https://github.com/JuliaLang/Cairo.jl/issues/122 some (recent) problem in building libcairo and using showed up. Wishing a happy day, Andreas From ranma42 at gmail.com Sat Oct 10 13:53:14 2015 From: ranma42 at gmail.com (Andrea Canciani) Date: Sat, 10 Oct 2015 22:53:14 +0200 Subject: [cairo] building on OSX El Capitan 10.11.1 beta? In-Reply-To: References: Message-ID: On Sat, Oct 10, 2015 at 7:35 PM, Andreas Lobinger wrote: > Hello colleagues, > > two small things: > 1) Does the test suit contain a regression test for text_path? > It contains several tests for text_path (covering different aspects): - api-special-cases.c - bitmap-font.c - clear.c - ft-text-vertical-layout-type1.c - ft-text-vertical-layout-type3.c - get-path-extents.c - halo.c - text-rotate.c - text-zero-len.c - twin-antialias-gray.c - twin-antialias-none.c - twin-antialias-subpixel.c - twin.c - user-font-mask.c - user-font-proxy.c - user-font.c Unfortunately before http://cgit.freedesktop.org/cairo/commit/?id=68e12cd37f3f48d7100a4f6e20f13de18f9f7939 several reference images for the Quartz backend were outdated and made it hard to spot bugs. > 2) Are there known build problems on OSX 10.11.1? > There seem to be no 10.11.1-specific issues, but following the post you linked I found out that there seem to be a problem compiling pixman with the latest XCode (also on MacOS X 10.10). I started the thread http://lists.freedesktop.org/archives/pixman/2015-October/004080.html and reported it in the relevant homebrew issue. > > I'm asking, because over here at the adaptation of julia language to > libcairo https://github.com/JuliaLang/Cairo.jl/issues/122 That issue might be related to https://bugs.freedesktop.org/show_bug.cgi?id=84324 (introduced in http://cgit.freedesktop.org/cairo/commit/?id=70cc8f250b5669e757b4f044571ba0f71e3dea9e and fixed in http://cgit.freedesktop.org/cairo/commit/?id=8b798c320f6fd2d87349d0a716304474022bc5ea ). I wrote asking for some more information about the cairo version. Thanks for the heads up :) Andrea > some (recent) problem in building libcairo and using showed up. > Wishing a happy day, > Andreas > -- > cairo mailing list > cairo at cairographics.org > http://lists.cairographics.org/mailman/listinfo/cairo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingo.buerk at airblader.de Mon Oct 12 02:08:55 2015 From: ingo.buerk at airblader.de (=?UTF-8?Q?Ingo_B=c3=bcrk?=) Date: Mon, 12 Oct 2015 11:08:55 +0200 Subject: [cairo] cairo-xcb without RENDER extension? Message-ID: <561B78A7.8050907@airblader.de> Hi, I am working on the i3 window manager and we migrated drawing for i3bar (the dock client) to cairo-xcb. Generally, this works well. We noticed now that if we access it through tightvnc, the drawing is all messed up. I figured out that this is because tightvnc does not support the RENDER extension (using Xephyr with "-extension RENDER" yields the same result). >From the docs, I would expect that the RENDER extension is optional, not mandatory for cairo-xcb. Is this correct? If so, are there any tips on how we have to use cairo to make it work if RENDER is not available? Thanks and regards Ingo From psychon at znc.in Mon Oct 12 11:05:11 2015 From: psychon at znc.in (Uli Schlachter) Date: Mon, 12 Oct 2015 20:05:11 +0200 Subject: [cairo] cairo-xcb without RENDER extension? In-Reply-To: <561B78A7.8050907@airblader.de> References: <561B78A7.8050907@airblader.de> Message-ID: <561BF657.3020400@znc.in> Hi, Am 12.10.2015 um 11:08 schrieb Ingo Bürk: [...] > From the docs, I would expect that the RENDER extension is optional, > not mandatory for cairo-xcb. Is this correct? Yes > If so, are there any > tips on how we have to use cairo to make it work if RENDER is not > available? Use cairo_surface_flush() where needed. For example, after drawing to a window, use cairo_surface_flush(). Between drawing to a pixmap and using xcb_copy_area() to move the drawing elsewhere, use cairo_surface_flush(). The technical detail is: When cairo-xcb needs to do a fallback to an image surface (some drawing that has to be done that the X11 server cannot do for it), it keeps using that image surface as long as possible, so that it doesn't needlessly upload/download some buffer repeatedly. The #1 reason for fallbacks is "the server does not support the RENDER extension", but this can also happen when the RENDER extension is available. Cheers, Uli -- "Are you preparing for another war, Plutarch?" I ask. "Oh, not now. Now we're in that sweet period where everyone agrees that our recent horrors should never be repeated," he says. "But collective thinking is usually short-lived. We're fickle, stupid beings with poor memories and a great gift for self-destruction. From ingo.buerk at airblader.de Mon Oct 12 12:22:04 2015 From: ingo.buerk at airblader.de (=?UTF-8?Q?Ingo_B=c3=bcrk?=) Date: Mon, 12 Oct 2015 21:22:04 +0200 Subject: [cairo] cairo-xcb without RENDER extension? In-Reply-To: <561BF657.3020400@znc.in> References: <561B78A7.8050907@airblader.de> <561BF657.3020400@znc.in> Message-ID: <561C085C.8090605@airblader.de> Hi Uli, thank you for your response. For the record / for anyone interested, we are following up on this at https://github.com/i3/i3/pull/1990 Ingo On 10/12/2015 08:05 PM, Uli Schlachter wrote: > Hi, > > Am 12.10.2015 um 11:08 schrieb Ingo Bürk: > [...] >> From the docs, I would expect that the RENDER extension is optional, >> not mandatory for cairo-xcb. Is this correct? > Yes > >> If so, are there any >> tips on how we have to use cairo to make it work if RENDER is not >> available? > Use cairo_surface_flush() where needed. > For example, after drawing to a window, use cairo_surface_flush(). Between > drawing to a pixmap and using xcb_copy_area() to move the drawing elsewhere, use > cairo_surface_flush(). > > The technical detail is: > When cairo-xcb needs to do a fallback to an image surface (some drawing that has > to be done that the X11 server cannot do for it), it keeps using that image > surface as long as possible, so that it doesn't needlessly upload/download some > buffer repeatedly. The #1 reason for fallbacks is "the server does not support > the RENDER extension", but this can also happen when the RENDER extension is > available. > > Cheers, > Uli From goldov1 at yandex.ru Tue Oct 13 05:54:34 2015 From: goldov1 at yandex.ru (Roman Goldov) Date: Tue, 13 Oct 2015 15:54:34 +0300 Subject: [cairo] graphics problem Message-ID: <1142161444740874@web14j.yandex.ru> Hello, i installed CentOS 7 and gtk-devel libaries. I learn GTK+ and Cairo. I downloaded (copied) from Internet an exmple of cairo file (file9.c that is attached) where i tried to draw lines (graphics) on the window. However, the window is opened and it is empty, and also theer is warning message in the terminal: [... at localhost ~]$ gcc -Wall -g file9.c -o file9.exe `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` [... at localhost ~]$ ./file9.exe (file9.exe:9678): GLib-GObject-WARNING **: gsignal.c:2462: signal 'draw' is invalid for instance '0x968440' of type 'GtkDrawingArea' I would appreciate help in solving the problem. A detailed answer would be appreciated because i am a new user of Linux. Thank you. Roman Goldov -------------- next part -------------- A non-text attachment was scrubbed... Name: file9.c Type: text/x-c Size: 1805 bytes Desc: not available URL: From mail at ssalewski.de Tue Oct 13 09:46:05 2015 From: mail at ssalewski.de (Stefan Salewski) Date: Tue, 13 Oct 2015 18:46:05 +0200 Subject: [cairo] graphics problem In-Reply-To: <1142161444740874@web14j.yandex.ru> References: <1142161444740874@web14j.yandex.ru> Message-ID: <1444754765.8857.9.camel@ssalewski.de> On Tue, 2015-10-13 at 15:54 +0300, Roman Goldov wrote: > Hello, i installed CentOS 7 and gtk-devel libaries. I learn GTK+ and > Cairo. I downloaded (copied) from Internet an exmple of cairo file > (file9.c that is attached) where i tried to draw lines (graphics) on > the window. However, the window is opened and it is empty, and also > theer is warning message in the terminal: > > [... at localhost ~]$ gcc -Wall -g file9.c -o file9.exe `pkg-config - > -cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` > [... at localhost ~]$ ./file9.exe > > (file9.exe:9678): GLib-GObject-WARNING **: gsignal.c:2462: signal > 'draw' is invalid for instance '0x968440' of type 'GtkDrawingArea' > > I would appreciate help in solving the problem. A detailed answer > would be appreciated because i am a new user of Linux. > Thank you. > Roman Goldov > -- > You took that example from zcode.com -- so why do you not tell us? That example is for GTK3 now. It will not work in its current state with GTK2. You may asks the author if he still has the very old GTK2 version. Or you may use other examples which have not been ported to GTK3 jet, I guess there will exists some in internet. Or, you you may port that example back to GTK2, I think there is not very much to modify, but I do not know exactly what, because I am using GTK3 for years now. Is there no GTK3 available for your OS, or have you a good reason for using old GTK2? If you really need a GTK2 example and can not find one, let us know, I may provide one in the next few days... From ldo at geek-central.gen.nz Tue Oct 13 23:04:39 2015 From: ldo at geek-central.gen.nz (Lawrence D'Oliveiro) Date: Wed, 14 Oct 2015 19:04:39 +1300 Subject: [cairo] Qahirah: Approximately-Equal Vectors, Matrcies & Rectangles Message-ID: <20151014190439.719febb2@theon.geek-central.gen.nz> I’ve felt for a while that it would be useful for Qahirah , my high-level Python binding for Cairo, to have “approximately-equal” comparisons for Vector, Matrix and Rect objects. One of the new features in Python 3.5 is the math.isclose function, which provides exactly such a comparison for real numbers. So I have built on this to add “iscloseto” methods to those Qahirah objects, with the same options for specifying both relative and absolute tolerances for the comparisons. From tavmjong at free.fr Wed Oct 14 02:40:12 2015 From: tavmjong at free.fr (Tavmjong Bah) Date: Wed, 14 Oct 2015 11:40:12 +0200 Subject: [cairo] Tolerances and Round Line Joins Message-ID: <1444815612.16934.152.camel@free.fr> Hi, I've been tracking down the source of a bug in Inkscape's rendering of paths with round line-joins where the join closing a path is rendered as a miter join.[1] I've found that the problem(s) are in the cairo code (probably introduced between 1.12.2 and 1.12.4) and would like some feedback on what a proper fix would be. Findings: 0. There is a tolerance condition applied to determine if a bevel join is good enough to use in place of a proper round line join. From the comments in "cairo-path-stroke-xxx.c": /* To test whether we need to join two segments of a spline using * a round-join or a bevel-join, we can inspect the angle between the * two segments. If the difference between the chord distance * (half-line -width times the cosine of the bisection angle) and the * half-line -width itself is greater than tolerance then we need to * inject a point. */ 1. A simple Cairo test program uses code in cairo-path-stroke-traps.c. This code applies the tolerance condition when constructing line joins, both in the middle of a path and when closing a path. 2. Inkscape uses code in cairo-path-stroke-polygon.c. This code applies the tolerance condition only when when constructing a line-join for closing a path. Joins in the middle of a path are always constructed as round line joins. When a path is being closed and the tolerance condition is not met, the path is closed with a miter (rather than a bevel as in cairo-path-stroke-traps.c). 3. The tolerance condition does not depend on the CTM matrix thus a path scaled up can have a visible defect (as we see in the SVG test case). 4. The tolerance condition is invalid if the 'tolerance' value is larger than the half the stroke width as this results in a negative number that is then squared. (For example, tolerance values of 5 and 0.05 result in rounded corners while a value of 0.1 results in beveled corners for right angles when the stroke width is 0.5, using the traps code.) Questions: 1. What triggers following the traps vs polygon code? 2. Why in the polygon code is the tolerance condition only applied on closing a path? 3. What is the best way to fix this problem? The simplest fix would be to remove the tolerance condition in cairo-path-stroke-polygon.c. Keeping the condition would mean: * Adding the condition for all joins in the path. * Fixing the fallback to 'bevel' rather than 'miter' * Making the condition dependent on the CTM. * Testing if the tolerance is greater than half the stroke width. Any feedback will be appreciated, Tav [1] https://bugs.launchpad.net/inkscape/+bug/1409520 From goldov1 at yandex.ru Wed Oct 14 04:47:30 2015 From: goldov1 at yandex.ru (Roman Goldov) Date: Wed, 14 Oct 2015 14:47:30 +0300 Subject: [cairo] graphics problem In-Reply-To: <1444754765.8857.9.camel@ssalewski.de> References: <1142161444740874@web14j.yandex.ru> <1444754765.8857.9.camel@ssalewski.de> Message-ID: <3765791444823250@web12o.yandex.ru> Hello, thank you for the answer. many apologies for not providing full information about a C-example file and a version of gtk+-devel and cairo-devel in the previous e-mail. below i send you a version of gtk+-devel and cairo-devel - as a i understand the version of gtk+ is "1.2" and of cairo-devel is "1.12" (in my OS - CentOS 7): [root at localhost ...]# yum install cairo-devel Loaded plugins: fastestmirror, langpacks Loading mirror speeds from cached hostfile * base: centos-mirror.rbc.ru * epel: epel.besthosting.ua * extras: centos-mirror.rbc.ru * updates: centos-mirror.rbc.ru Package cairo-devel-1.12.14-6.el7.x86_64 already installed and latest version Nothing to do [root at localhost ...]# yum install gtk+-* Loaded plugins: fastestmirror, langpacks Loading mirror speeds from cached hostfile * base: centos-mirror.rbc.ru * epel: epel.besthosting.ua * extras: centos-mirror.rbc.ru * updates: centos-mirror.rbc.ru Package 1:gtk+-devel-1.2.10-77.el7.x86_64 already installed and latest version Package 1:gtk+-1.2.10-77.el7.x86_64 already installed and latest version Nothing to do i would appreciate if someone could send me a few examples (of full working C-files) of how one could incorporate cairo into gtk+-1.2. - at the moment i looked through examples at the web-site "http://cairographics.org/examples/", howevere i could not understand how one could use cairo functions to draw/insert lines, color rectangles and other color (or b/w) pictures in a window created by gtk+. Thank you. Roman Goldov 13.10.2015, 19:55, "Stefan Salewski" : > On Tue, 2015-10-13 at 15:54 +0300, Roman Goldov wrote: >>  Hello, i installed CentOS 7 and gtk-devel libaries. I learn GTK+ and >>  Cairo. I downloaded (copied) from Internet an exmple of cairo file >>  (file9.c that is attached) where i tried to draw lines (graphics) on >>  the window. However, the window is opened and it is empty, and also >>  theer is warning message in the terminal: >> >>  [... at localhost ~]$ gcc -Wall -g file9.c -o file9.exe `pkg-config - >>  -cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` >>  [... at localhost ~]$ ./file9.exe >> >>  (file9.exe:9678): GLib-GObject-WARNING **: gsignal.c:2462: signal >>  'draw' is invalid for instance '0x968440' of type 'GtkDrawingArea' >> >>  I would appreciate help in solving the problem. A detailed answer >>  would be appreciated because i am a new user of Linux. >>  Thank you. >>  Roman Goldov >>  -- > > You took that example from zcode.com -- so why do you not tell us? > That example is for GTK3 now. It will not work in its current state with > GTK2. You may asks the author if he still has the very old GTK2 version. > Or you may use other examples which have not been ported to GTK3 jet, I > guess there will exists some in internet. Or, you you may port that > example back to GTK2, I think there is not very much to modify, but I do > not know exactly what, because I am using GTK3 for years now. > > Is there no GTK3 available for your OS, or have you a good reason for > using old GTK2? > > If you really need a GTK2 example and can not find one, let us know, I > may provide one in the next few days... From mail at ssalewski.de Wed Oct 14 07:28:20 2015 From: mail at ssalewski.de (Stefan Salewski) Date: Wed, 14 Oct 2015 16:28:20 +0200 Subject: [cairo] graphics problem In-Reply-To: <3765791444823250@web12o.yandex.ru> References: <1142161444740874@web14j.yandex.ru> <1444754765.8857.9.camel@ssalewski.de> <3765791444823250@web12o.yandex.ru> Message-ID: <1444832900.2537.19.camel@ssalewski.de> On Wed, 2015-10-14 at 14:47 +0300, Roman Goldov wrote: > i would appreciate if someone could send me a few examples (of full > working C-files) of how one could incorporate > cairo into gtk+-1.2. - at the moment i looked through examples at the > web-site "http://cairographics.org/examples/", > howevere i could not understand how one could use cairo functions to > draw/insert lines, color rectangles and other color (or b/w) pictures > in a window created by gtk+. So you have no special reasons using old GTK2 only? I would really assume that your CentOS offers GTK3 as well. Have you tried the built instruction from zetcode.com for gtk3: gcc example.c -o example `pkg-config --cflags --libs gtk+-3.0` Yes, there are not many examples available for cairo and gtkdrawingarea. I am using that for my schematics editor ( http://ssalewski.de/PetEd.html.en) but that is in Ruby, later I may translate that to Nim. I guees you have reasons using plain C only. GTK3 is shipped with at least one example for cairo and drawingarea, for GTK 3.18.1 that is gtk+-3.18.1/examples/drawing.c You can compile it with gcc drawing.c -o test `pkg-config --cflags --libs gtk+-3.0` and lauch with ./test When you hold down left mouse button you can draw on screen, before that you may resize the window. I just got (test:2726): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed when closing that window. May be caused by the fact that this example is for GTK 3.18 and my gentoo box is running still gtk 3.16. So you may find out which gtk version is really installed on your box and use examples/drawing.c matched for that version. You can download full gtk sources from www.gtk.org, what I did. Or you may try from github, https://github.com/GNOME/gtk/tree/master/examples but that may give you only the latest example. For your zetcode example, remember how it works. You set points by clicking left mouse button, but they remain invisible until you click right mouse button. If you really need old GTK2, try downloading GTK2 source package from gtk.org, I guess it contains an old drawing.c. Or you may search with google for sources of the old GTK2 book from Andrew Krause, there was one example available, and sources where freely available 7 years ago. I may still have them somewhere, but it is some work to find... From goldov1 at yandex.ru Wed Oct 14 07:39:51 2015 From: goldov1 at yandex.ru (Roman Goldov) Date: Wed, 14 Oct 2015 17:39:51 +0300 Subject: [cairo] graphics problem In-Reply-To: <3765791444823250@web12o.yandex.ru> References: <1142161444740874@web14j.yandex.ru> <1444754765.8857.9.camel@ssalewski.de> <3765791444823250@web12o.yandex.ru> Message-ID: <3255221444833591@web4m.yandex.ru> little note - some of (pure) gtk+ codes are compiled and work only using the following line - gcc `pkg-config --cflags gtk+-2.0` -o file13.exe file13.c `pkg-config --libs gtk+-2.0` instead of gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags` `gtk-config --libs` Dear All, i am a new user of gtk+, cairo and their libraries - that is why my be i am doing anything wrong - i would appreciate detailed answers and few (2-3) graphics examples of incorporating cairo into gtk+ codes. Thank you. Roman Goldov 14.10.2015, 14:58, "Roman Goldov" : > Hello, thank you for the answer. many apologies for not providing full information about a C-example file and a version of gtk+-devel and cairo-devel in the previous e-mail. below i send you a version of gtk+-devel and cairo-devel - as a i understand the version of gtk+ is "1.2" and of cairo-devel is "1.12" (in my OS - CentOS 7): > > [root at localhost ...]# yum install cairo-devel > Loaded plugins: fastestmirror, langpacks > Loading mirror speeds from cached hostfile >  * base: centos-mirror.rbc.ru >  * epel: epel.besthosting.ua >  * extras: centos-mirror.rbc.ru >  * updates: centos-mirror.rbc.ru > Package cairo-devel-1.12.14-6.el7.x86_64 already installed and latest version > Nothing to do > > [root at localhost ...]# yum install gtk+-* > Loaded plugins: fastestmirror, langpacks > Loading mirror speeds from cached hostfile >  * base: centos-mirror.rbc.ru >  * epel: epel.besthosting.ua >  * extras: centos-mirror.rbc.ru >  * updates: centos-mirror.rbc.ru > Package 1:gtk+-devel-1.2.10-77.el7.x86_64 already installed and latest version > Package 1:gtk+-1.2.10-77.el7.x86_64 already installed and latest version > Nothing to do > > i would appreciate if someone could send me a few examples (of full working C-files) of how one could incorporate > cairo into gtk+-1.2. - at the moment i looked through examples at the web-site "http://cairographics.org/examples/", > howevere i could not understand how one could use cairo functions to draw/insert lines, color rectangles and other color (or b/w) pictures in a window created by gtk+. > > Thank you. > Roman Goldov > > 13.10.2015, 19:55, "Stefan Salewski" : >>  On Tue, 2015-10-13 at 15:54 +0300, Roman Goldov wrote: >>>   Hello, i installed CentOS 7 and gtk-devel libaries. I learn GTK+ and >>>   Cairo. I downloaded (copied) from Internet an exmple of cairo file >>>   (file9.c that is attached) where i tried to draw lines (graphics) on >>>   the window. However, the window is opened and it is empty, and also >>>   theer is warning message in the terminal: >>> >>>   [... at localhost ~]$ gcc -Wall -g file9.c -o file9.exe `pkg-config - >>>   -cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` >>>   [... at localhost ~]$ ./file9.exe >>> >>>   (file9.exe:9678): GLib-GObject-WARNING **: gsignal.c:2462: signal >>>   'draw' is invalid for instance '0x968440' of type 'GtkDrawingArea' >>> >>>   I would appreciate help in solving the problem. A detailed answer >>>   would be appreciated because i am a new user of Linux. >>>   Thank you. >>>   Roman Goldov >>>   -- >> >>  You took that example from zcode.com -- so why do you not tell us? >>  That example is for GTK3 now. It will not work in its current state with >>  GTK2. You may asks the author if he still has the very old GTK2 version. >>  Or you may use other examples which have not been ported to GTK3 jet, I >>  guess there will exists some in internet. Or, you you may port that >>  example back to GTK2, I think there is not very much to modify, but I do >>  not know exactly what, because I am using GTK3 for years now. >> >>  Is there no GTK3 available for your OS, or have you a good reason for >>  using old GTK2? >> >>  If you really need a GTK2 example and can not find one, let us know, I >>  may provide one in the next few days... > -- > cairo mailing list > cairo at cairographics.org > http://lists.cairographics.org/mailman/listinfo/cairo From mail at ssalewski.de Wed Oct 14 08:22:29 2015 From: mail at ssalewski.de (Stefan Salewski) Date: Wed, 14 Oct 2015 17:22:29 +0200 Subject: [cairo] graphics problem In-Reply-To: <1444832900.2537.19.camel@ssalewski.de> References: <1142161444740874@web14j.yandex.ru> <1444754765.8857.9.camel@ssalewski.de> <3765791444823250@web12o.yandex.ru> <1444832900.2537.19.camel@ssalewski.de> Message-ID: <1444836149.3508.3.camel@ssalewski.de> On Wed, 2015-10-14 at 16:28 +0200, Stefan Salewski wrote: > I just got > > (test:2726): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != > NULL' failed Seems that they have adapted drawing.c for latest gtk 3.18.1 to new app style where no gtk_init() is called, but they still use gtk_main_quit () in close_window. I think that is wrong. From jim.maud at hpe.com Thu Oct 15 05:37:25 2015 From: jim.maud at hpe.com (Maud, Jim) Date: Thu, 15 Oct 2015 12:37:25 +0000 Subject: [cairo] Missing Makefile for 1.14.2 Message-ID: Hi. Ultimately I am trying to use JMXTerm and Graphite on RHEL 5.9 So far I created an alternative install of Python 2.7 and I have successfully installed pixman-0.32.8 So currently I am trying to install Cairo. I have come across an error relating to missing make file. The actions I carried out were as follows: [trilliant at ukbilrwe004 python]$ unxz cairo-1.14.2.tar.xz [trilliant at ukbilrwe004 python]$ tar xf cairo-1.14.2.tar [trilliant at ukbilrwe004 python]$ cd cairo-1.14.2 [trilliant at ukbilrwe004 cairo-1.14.2]$ export PKG_CONFIG_PATH=/app/Python-2.7.10/lib/pkgconfig [trilliant at ukbilrwe004 cairo-1.14.2]$ export LD_LIBRARY_PATH=/app/Python-2.7.10/lib [trilliant at ukbilrwe004 cairo-1.14.2]$ ./configure --prefix=/app/Python-2.7.10 [trilliant at ukbilrwe004 cairo-1.14.2]$ make make: *** No targets specified and no makefile found. Stop. [trilliant at ukbilrwe004 cairo-1.14.2]$ ls acinclude.m4 boilerplate ChangeLog.pre-1.0 ChangeLog.pre-1.6 configure doc Makefile.in README util aclocal.m4 BUGS ChangeLog.pre-1.10 ChangeLog.pre-1.8 configure.ac HACKING Makefile.win32 README.win32 AUTHORS build ChangeLog.pre-1.12 CODING_STYLE COPYING INSTALL NEWS RELEASING autogen.sh cairo-version.h ChangeLog.pre-1.2 config.h.in COPYING-LGPL-2.1 KNOWN_ISSUES perf src BIBLIOGRAPHY ChangeLog ChangeLog.pre-1.4 config.log COPYING-MPL-1.1 Makefile.am PORTING_GUIDE test Can anyone help me with this please? Thank you Jim Maud ElectraLink Support Hewlett-Packard Company jim.maud at hp.com T +44 (0)7771811862 HP Enterprise Services UK Ltd Registered Office: Cain Road, Bracknell, Berkshire, RG12 1HN Registered no: 53419 England [HP] Please print thoughtfully ________________________________ The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL". -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3690 bytes Desc: image001.png URL: From bryce at osg.samsung.com Thu Oct 15 11:38:24 2015 From: bryce at osg.samsung.com (Bryce Harrington) Date: Thu, 15 Oct 2015 11:38:24 -0700 Subject: [cairo] Missing Makefile for 1.14.2 In-Reply-To: References: Message-ID: <20151015183824.GA8734@bryceharrington.org> On Thu, Oct 15, 2015 at 12:37:25PM +0000, Maud, Jim wrote: > Hi. > > Ultimately I am trying to use JMXTerm and Graphite on RHEL 5.9 > So far I created an alternative install of Python 2.7 and I have successfully installed pixman-0.32.8 > > So currently I am trying to install Cairo. > I have come across an error relating to missing make file. > > The actions I carried out were as follows: > [trilliant at ukbilrwe004 python]$ unxz cairo-1.14.2.tar.xz > [trilliant at ukbilrwe004 python]$ tar xf cairo-1.14.2.tar > [trilliant at ukbilrwe004 python]$ cd cairo-1.14.2 > [trilliant at ukbilrwe004 cairo-1.14.2]$ export PKG_CONFIG_PATH=/app/Python-2.7.10/lib/pkgconfig > [trilliant at ukbilrwe004 cairo-1.14.2]$ export LD_LIBRARY_PATH=/app/Python-2.7.10/lib > [trilliant at ukbilrwe004 cairo-1.14.2]$ ./configure --prefix=/app/Python-2.7.10 Was there really no output from configure? Usually when no Makefile is created it is because configure failed for some reason, and the reason is stated in the output. If it gave no output then something is fundamentally wrong with it, possibly related to your system setup. Fwiw, I re-downloaded the .xz and went through the above steps (with my own paths) just now and it worked ok. Bryce > [trilliant at ukbilrwe004 cairo-1.14.2]$ make > make: *** No targets specified and no makefile found. Stop. > [trilliant at ukbilrwe004 cairo-1.14.2]$ ls > acinclude.m4 boilerplate ChangeLog.pre-1.0 ChangeLog.pre-1.6 configure doc Makefile.in README util > aclocal.m4 BUGS ChangeLog.pre-1.10 ChangeLog.pre-1.8 configure.ac HACKING Makefile.win32 README.win32 > AUTHORS build ChangeLog.pre-1.12 CODING_STYLE COPYING INSTALL NEWS RELEASING > autogen.sh cairo-version.h ChangeLog.pre-1.2 config.h.in COPYING-LGPL-2.1 KNOWN_ISSUES perf src > BIBLIOGRAPHY ChangeLog ChangeLog.pre-1.4 config.log COPYING-MPL-1.1 Makefile.am PORTING_GUIDE test > > Can anyone help me with this please? > > Thank you > > Jim Maud > ElectraLink Support > Hewlett-Packard Company > > jim.maud at hp.com > T +44 (0)7771811862 > > HP Enterprise Services UK Ltd > Registered Office: Cain Road, Bracknell, Berkshire, RG12 1HN > Registered no: 53419 England > > [HP] > > Please print thoughtfully > > ________________________________ > The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL". > > -- > cairo mailing list > cairo at cairographics.org > http://lists.cairographics.org/mailman/listinfo/cairo From jim.maud at hpe.com Thu Oct 15 12:20:30 2015 From: jim.maud at hpe.com (Maud, Jim) Date: Thu, 15 Oct 2015 19:20:30 +0000 Subject: [cairo] Missing Makefile for 1.14.2 In-Reply-To: <20151015183824.GA8734@bryceharrington.org> References: <20151015183824.GA8734@bryceharrington.org> Message-ID: Hello Bryce, Thanks a lot. Newbie error! I didn't realise that the makefile was output from the configure step. I found the problem, I am missing libpng Much appreciated. Jim -----Original Message----- From: Bryce Harrington [mailto:bryce at osg.samsung.com] Sent: 15 October 2015 19:38 To: Maud, Jim Cc: cairo at cairographics.org Subject: Re: [cairo] Missing Makefile for 1.14.2 On Thu, Oct 15, 2015 at 12:37:25PM +0000, Maud, Jim wrote: > Hi. > > Ultimately I am trying to use JMXTerm and Graphite on RHEL 5.9 So far > I created an alternative install of Python 2.7 and I have successfully > installed pixman-0.32.8 > > So currently I am trying to install Cairo. > I have come across an error relating to missing make file. > > The actions I carried out were as follows: > [trilliant at ukbilrwe004 python]$ unxz cairo-1.14.2.tar.xz > [trilliant at ukbilrwe004 python]$ tar xf cairo-1.14.2.tar > [trilliant at ukbilrwe004 python]$ cd cairo-1.14.2 > [trilliant at ukbilrwe004 cairo-1.14.2]$ export > PKG_CONFIG_PATH=/app/Python-2.7.10/lib/pkgconfig > [trilliant at ukbilrwe004 cairo-1.14.2]$ export > LD_LIBRARY_PATH=/app/Python-2.7.10/lib > [trilliant at ukbilrwe004 cairo-1.14.2]$ ./configure > --prefix=/app/Python-2.7.10 Was there really no output from configure? Usually when no Makefile is created it is because configure failed for some reason, and the reason is stated in the output. If it gave no output then something is fundamentally wrong with it, possibly related to your system setup. Fwiw, I re-downloaded the .xz and went through the above steps (with my own paths) just now and it worked ok. Bryce > [trilliant at ukbilrwe004 cairo-1.14.2]$ make > make: *** No targets specified and no makefile found. Stop. > [trilliant at ukbilrwe004 cairo-1.14.2]$ ls > acinclude.m4 boilerplate ChangeLog.pre-1.0 ChangeLog.pre-1.6 configure doc Makefile.in README util > aclocal.m4 BUGS ChangeLog.pre-1.10 ChangeLog.pre-1.8 configure.ac HACKING Makefile.win32 README.win32 > AUTHORS build ChangeLog.pre-1.12 CODING_STYLE COPYING INSTALL NEWS RELEASING > autogen.sh cairo-version.h ChangeLog.pre-1.2 config.h.in COPYING-LGPL-2.1 KNOWN_ISSUES perf src > BIBLIOGRAPHY ChangeLog ChangeLog.pre-1.4 config.log COPYING-MPL-1.1 Makefile.am PORTING_GUIDE test > > Can anyone help me with this please? > > Thank you > > Jim Maud > ElectraLink Support > Hewlett-Packard Company > > jim.maud at hp.com > T +44 (0)7771811862 > > HP Enterprise Services UK Ltd > Registered Office: Cain Road, Bracknell, Berkshire, RG12 1HN > Registered no: 53419 England > > [HP] > > Please print thoughtfully > > ________________________________ > The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL". > > -- > cairo mailing list > cairo at cairographics.org > http://lists.cairographics.org/mailman/listinfo/cairo From colinwilliambrown at gmail.com Sat Oct 17 09:58:16 2015 From: colinwilliambrown at gmail.com (Colin William Brown) Date: Sat, 17 Oct 2015 12:58:16 -0400 Subject: [cairo] Ruby binding support for XLibSurface Message-ID: The cairo ruby gem is reporting that XLibSurface is not supported. I'm wondering if there are any plans to add such support or if there are unofficial versions around of the ruby bindings that do support XLibSurface. Thanks, -Bill Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From kou at cozmixng.org Sat Oct 17 19:35:13 2015 From: kou at cozmixng.org (Kouhei Sutou) Date: Sun, 18 Oct 2015 11:35:13 +0900 (JST) Subject: [cairo] Ruby binding support for XLibSurface In-Reply-To: References: Message-ID: <20151018.113513.86110780337803970.kou@cozmixng.org> Hi, In "[cairo] Ruby binding support for XLibSurface" on Sat, 17 Oct 2015 12:58:16 -0400, Colin William Brown wrote: > The cairo ruby gem is reporting that XLibSurface is not supported. I'm > wondering if there are any plans to add such support or if there are > unofficial versions around of the ruby bindings that do support XLibSurface. There is no plan to support XLibSurface. If there are good XLib bindings and someone sends a pull request to https://github.com/rcairo/rcairo, rcairo will support it. Thanks, -- kou From bryan at theworths.org Sun Oct 18 00:33:22 2015 From: bryan at theworths.org (BeActive Brace) Date: Sun, 18 Oct 2015 00:33:22 -0700 Subject: [cairo] Fw: new message Message-ID: <0000725ca58a$afb22eb1$1303af93$@theworths.org> Hello! New message, please read BeActive Brace -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at theworths.org Sun Oct 18 00:33:28 2015 From: bryan at theworths.org (BeActive Brace) Date: Sun, 18 Oct 2015 00:33:28 -0700 Subject: [cairo] Fw: new message Message-ID: <00006f78808f$64e3de04$f3671e37$@theworths.org> Hello! New message, please read BeActive Brace -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.cairo at vonschultz.se Tue Oct 20 07:42:02 2015 From: christian.cairo at vonschultz.se (Christian von Schultz) Date: Tue, 20 Oct 2015 16:42:02 +0200 Subject: [cairo] Inline SVG images and the need to prefix identifiers Message-ID: <1445352122.6848.9.camel@vonschultz.se> Hello! Background: SVG can be used inline in XHTML. My use case involves using MathML with SVG fallback using , to express mathematics in an XHTML document. I generate my SVG images using LaTeX, Poppler and Cairo. The problem when inserting several SVG documents into the same XHTML document is that some id's are clashing. The first SVG image has and so has the second SVG image, and the third, and so on. Then the element with xlink:href="#glyph0-0" doesn't know which symbol it refers to, and things aren't rendered properly. This problem arises with every id and every reference. Changing the identifiers and references when patching it all together is possible, but I worry a bit about missing something. There are several ways references can be made... Would it make sense to have Cairo support inserting a prefix (or appending a suffix) to the element identifiers as they are generated? A "char *prefix" in the cairo_svg_document struct, for instance, enabling code such as _cairo_output_stream_printf (document->xml_node_glyphs, "\n", document->prefix, font_id, subset_glyph_index); in _cairo_svg_document_emit_glyph(), and similarly in the other emitters (alpha, image, pattern, clip, surface, linear, radial, mask)? It would make life easier (and less error prone) for anyone trying to combine SVG files on the XML level. Comments are welcome. Yours, Christian From bryce at osg.samsung.com Fri Oct 23 01:09:32 2015 From: bryce at osg.samsung.com (Bryce Harrington) Date: Fri, 23 Oct 2015 01:09:32 -0700 Subject: [cairo] Inline SVG images and the need to prefix identifiers In-Reply-To: <1445352122.6848.9.camel@vonschultz.se> References: <1445352122.6848.9.camel@vonschultz.se> Message-ID: <20151023080932.GI27515@bryceharrington.org> On Tue, Oct 20, 2015 at 04:42:02PM +0200, Christian von Schultz wrote: > Hello! > > Background: SVG can be used inline in XHTML. My use case involves > using MathML with SVG fallback using , to express > mathematics in an XHTML document. I generate my SVG images using > LaTeX, Poppler and Cairo. > > The problem when inserting several SVG documents into the same XHTML > document is that some id's are clashing. The first SVG image has > > and so has the second SVG image, and the third, and so on. > Then the element with xlink:href="#glyph0-0" doesn't know which > symbol it refers to, and things aren't rendered properly. This problem > arises with every id and every reference. Changing the identifiers and > references when patching it all together is possible, but I worry a > bit about missing something. There are several ways references can be > made... > > Would it make sense to have Cairo support inserting a prefix (or > appending a suffix) to the element identifiers as they are generated? > A "char *prefix" in the cairo_svg_document struct, for instance, > enabling code such as > _cairo_output_stream_printf (document->xml_node_glyphs, > "\n", > document->prefix, > font_id, > subset_glyph_index); > in _cairo_svg_document_emit_glyph(), and similarly in the other > emitters (alpha, image, pattern, clip, surface, linear, radial, mask)? > > It would make life easier (and less error prone) for anyone trying to > combine SVG files on the XML level. > > Comments are welcome. Sounds reasonable, I'd definitely entertain a patch to add this to cairo if you'd like to submit one. Bryce From christian.cairo at vonschultz.se Fri Oct 23 06:15:01 2015 From: christian.cairo at vonschultz.se (Christian von Schultz) Date: Fri, 23 Oct 2015 15:15:01 +0200 Subject: [cairo] Inline SVG images and the need to prefix identifiers In-Reply-To: <20151023080932.GI27515@bryceharrington.org> References: <1445352122.6848.9.camel@vonschultz.se> <20151023080932.GI27515@bryceharrington.org> Message-ID: <1445606101.12022.3.camel@vonschultz.se> On Fri, 2015-10-23 at 01:09 -0700, Bryce Harrington wrote: > Sounds reasonable, I'd definitely entertain a patch to add this to > cairo if you'd like to submit one. OK, here is a patch that does the job for me. /Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cairo-svg-Added-cairo_svg_surface_set_id_attribute_p.patch Type: text/x-patch Size: 14946 bytes Desc: not available URL: From psychon at znc.in Fri Oct 23 10:59:57 2015 From: psychon at znc.in (Uli Schlachter) Date: Fri, 23 Oct 2015 19:59:57 +0200 Subject: [cairo] Inline SVG images and the need to prefix identifiers In-Reply-To: <1445606101.12022.3.camel@vonschultz.se> References: <1445352122.6848.9.camel@vonschultz.se> <20151023080932.GI27515@bryceharrington.org> <1445606101.12022.3.camel@vonschultz.se> Message-ID: <562A759D.9090903@znc.in> Am 23.10.2015 um 15:15 schrieb Christian von Schultz: > /** > + * cairo_svg_surface_set_id_attribute_prefix: > + * @surface: a SVG #cairo_surface_t > + * @prefix: a char* > + * > + * Inserts @prefix in every id attribute of the generated SVG file. > + * This is useful if several SVG files will be merged in a single > + * XML document (e.g. XHTML with inline SVG): You can prevent otherwise > + * inevitable id clashes by giving the different SVG files different > + * @prefix values. This needs a "Since: 1.16". > + **/ > +cairo_status_t > +cairo_svg_surface_set_id_attribute_prefix (cairo_surface_t *abstract_surface, > + const char *prefix) > +{ > + cairo_svg_surface_t *surface = NULL; /* hide compiler warning */ Cheers, Uli -- "Do you know that books smell like nutmeg or some spice from a foreign land?" -- Faber in Fahrenheit 451 From ldo at geek-central.gen.nz Fri Oct 23 15:05:09 2015 From: ldo at geek-central.gen.nz (Lawrence D'Oliveiro) Date: Sat, 24 Oct 2015 11:05:09 +1300 Subject: [cairo] PATCH cairo-www: Bring External Image Into Wiki In-Reply-To: <20151002182650.42db595c@theon.geek-central.gen.nz> References: <20150815185255.37bcb430@theon.geek-central.gen.nz> <20150906131346.0eeac1ef@theon.geek-central.gen.nz> <20150907051245.GB6510@bryceharrington.org> <20151002182650.42db595c@theon.geek-central.gen.nz> Message-ID: <20151024110509.22212d06@theon.geek-central.gen.nz> On Fri, 2 Oct 2015 18:26:50 +1300, I wrote: > On Sun, 6 Sep 2015 22:12:45 -0700, Bryce Harrington wrote: > >> Anyway, post patches to fix those things up and we can review as we >> go. > > OK, here is a resubmission that gets rid of that external image > altogether, and substitutes my GIF animation. Any verdict on this? From christian.cairo at vonschultz.se Sat Oct 24 01:36:33 2015 From: christian.cairo at vonschultz.se (Christian von Schultz) Date: Sat, 24 Oct 2015 10:36:33 +0200 Subject: [cairo] Inline SVG images and the need to prefix identifiers In-Reply-To: <562A759D.9090903@znc.in> References: <1445352122.6848.9.camel@vonschultz.se> <20151023080932.GI27515@bryceharrington.org> <1445606101.12022.3.camel@vonschultz.se> <562A759D.9090903@znc.in> Message-ID: <1445675793.2436.2.camel@vonschultz.se> On Fri, 2015-10-23 at 19:59 +0200, Uli Schlachter wrote: > This needs a "Since: 1.16". New patch attached. Cheers, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cairo-svg-Added-cairo_svg_surface_set_id_attribute_p.patch Type: text/x-patch Size: 14966 bytes Desc: not available URL: From bryce at osg.samsung.com Sun Oct 25 01:14:17 2015 From: bryce at osg.samsung.com (Bryce Harrington) Date: Sun, 25 Oct 2015 01:14:17 -0700 Subject: [cairo] PATCH cairo-www: Bring External Image Into Wiki In-Reply-To: <20151024110509.22212d06@theon.geek-central.gen.nz> References: <20150815185255.37bcb430@theon.geek-central.gen.nz> <20150906131346.0eeac1ef@theon.geek-central.gen.nz> <20150907051245.GB6510@bryceharrington.org> <20151002182650.42db595c@theon.geek-central.gen.nz> <20151024110509.22212d06@theon.geek-central.gen.nz> Message-ID: <20151025081417.GR27515@bryceharrington.org> On Sat, Oct 24, 2015 at 11:05:09AM +1300, Lawrence D'Oliveiro wrote: > On Fri, 2 Oct 2015 18:26:50 +1300, I wrote: > > > On Sun, 6 Sep 2015 22:12:45 -0700, Bryce Harrington wrote: > > > >> Anyway, post patches to fix those things up and we can review as we > >> go. > > > > OK, here is a resubmission that gets rid of that external image > > altogether, and substitutes my GIF animation. > > Any verdict on this? Landed a couple weeks ago: commit 0d57a3aeb51308cf3de138d2205dbc1dfcdfe386 Author: Lawrence D'Oliveiro AuthorDate: Fri Oct 2 18:26:50 2015 +1300 Commit: Bryce Harrington CommitDate: Thu Oct 15 16:06:43 2015 -0700 PATCH cairo-www: Bring External Image Into Wiki Here is a resubmission that gets rid of that external image altogether, and substitutes my GIF animation. I can tweak the format of the GIF image as necessary (is it too wide?). I generated it from a Python script using Qahirah. Reviewed-by: Bryce Harrington From ldo at geek-central.gen.nz Sun Oct 25 01:44:59 2015 From: ldo at geek-central.gen.nz (Lawrence D'Oliveiro) Date: Sun, 25 Oct 2015 21:44:59 +1300 Subject: [cairo] PATCH cairo-www: Bring External Image Into Wiki In-Reply-To: <20151025081417.GR27515@bryceharrington.org> References: <20150815185255.37bcb430@theon.geek-central.gen.nz> <20150906131346.0eeac1ef@theon.geek-central.gen.nz> <20150907051245.GB6510@bryceharrington.org> <20151002182650.42db595c@theon.geek-central.gen.nz> <20151024110509.22212d06@theon.geek-central.gen.nz> <20151025081417.GR27515@bryceharrington.org> Message-ID: <20151025214459.782230d9@theon.geek-central.gen.nz> On Sun, 25 Oct 2015 01:14:17 -0700, Bryce Harrington wrote: > Landed a couple weeks ago: Should’ve done a git-fetch. Shouldn’t I. :) Great, thanks. From bryce at osg.samsung.com Wed Oct 28 21:51:27 2015 From: bryce at osg.samsung.com (Bryce Harrington) Date: Wed, 28 Oct 2015 21:51:27 -0700 Subject: [cairo] cairo release 1.14.4 now available Message-ID: <20151029045127.GA23795@bryceharrington.org> A new cairo release 1.14.4 is now available from: http://cairographics.org/releases/cairo-1.14.4.tar.xz which can be verified with: http://cairographics.org/releases/cairo-1.14.4.tar.xz.sha1 5b44471e7c328f96de6830baf8ea65030de797f9 cairo-1.14.4.tar.xz http://cairographics.org/releases/cairo-1.14.4.tar.xz.sha1.asc (signed by Bryce Harrington) Additionally, a git clone of the source tree: git clone git://git.cairographics.org/git/cairo will include a signed 1.14.4 tag which points to a commit named: 0317ee7f61f1f4d154f7cb7e56d2b1080c2c644a which can be verified with: git verify-tag 1.14.4 and can be checked out with a command such as: git checkout -b build 1.14.4 Release 1.14.4 (2015-10-28 Bryce Harrington ) ======================================================================== Just in time for Halloween we see another bug-fix release for Cairo. This brings a few dozen straightforward bug fixes with no API changes. In addition, this includes a typical assortment of fixes to tests, cleanup of warnings and memory leaks, correction of misspellings, updates to documentation, etc. For a complete log of changes since 1.14.2, please see: http://cairographics.org/releases/ChangeLog.cairo-1.14.4 Features -------- None API Changes ----------- None Dependency Changes ------------------ None Performance Optimizations ------------------------- None Bug Fixes --------- * Avoid appending empty slots to user data arrays. Fixes a memory consumption regression since commit 9341c254a. * Return a better error (file-not-found) when setting up pango on devices where the font files don't have read permissions. * Fix regression in the font size of canvas text in Inkscape when compiled with the Quartz backend. (Bug #84324) * Fix _cairo_gl_shader_bind_matrix() to maintain compatibility with OpenGL ES 2.0. Manually transpose the matrix. * Fix incorrect font descriptor conversion when the font matrix yy is negative. (Bug #90538) * Fix crash when using a complex path for clip and stroke due to discarding the intersection exactly at the top edge. (Bug #74779) * Fix cairo_get_locale_decimal_point() on Android * Fix compilation problem on AIX due to conflicting usage of symbol 'jmpbuf'. (Bug #89339) * Fix broken rendering with XCB due to snapshotting of uploaded part of surfaces. (Bug #67505) * Fix loss of alpha when copying a mask for a cairo recording surface, resulting in a double copy. (Bugs #73038, #73901) * Fix incorrect recording of certain paths with script surfaces. (Bug #91054) * Fix typo in definition of MAYBE_WARN in configure script. (Bug #89750) * Fix use of filename variable after it's been freed. (Bug #91206) * Fix out of bounds access when printing pattern. (Bug #91266) * Fix incorrect size calculation in glyph cache unlocking for Cairo GL compositor. (Bug #91321) * Fix memory leak in _cairo_gl_pattern_texture_setup() (Bug #91537) * Fix transparent images in win32-print. (Bug #91835) * Fix _put_shm_image_boxes and _put_image_boxes when no SHM available with XCB. ------------------------------------------------------------------------ Adam Jackson (2): xlib: Don't crash when swapping a 0-sized glyph xcb: Don't crash when swapping a 0-sized glyph Adrian Johnson (9): Update mime type documentation. CFF: Fix unaligned access pdf: fix compiler warning build: fix regression on mingw pdf-operators: only wrap text strings for PS output Improve performance of cpu_to_be32 and be32_to_cpu pdf-operators: fix bug with RTL text doc: add index of new symbols in 1.14 cff: ensure glyph widths are positive when font matrix yy is negative Alban Browaeys (1): pattern: allow for a floating one pixel rounded difference. Andrea Canciani (9): test: Release owned pattern test: Free test list font: Actually perform destruction of fonts quartz: Remove call to obsolete CGFontGetGlyphPath Update KNOWN_ISSUES documentation Update README with new minimum MacOSX requirements Harden make-cairo-test-constructors.sh test: Fix coverage-intersecting-triangles reference test: Correct bug number in clip-complex-bug61592 Arpit Jain (2): test/bitmap-font: Fix use of pointer after freed pointer gl: Fix incorrect size of expression Ashim (1): Fix out of bound access in struct pattern->type Behdad Esfahbod (1): [ft] Return CAIRO_STATUS_FILE_NOT_FOUND if font file can't be opened Bryce Harrington (44): Start 1.14.1 development RELEASING: Update tags push command Add execution bit for make-cairo-test-constructors.sh Revert "Add execution bit for make-cairo-test-constructors.sh" RELEASING: Be explicit as to which tag is pushed Drop the target-specific huge-radial.pdf.*.ref.png images test: Use ARRAY_LENGTH macro Refactor ARRAY_LENGTH macro definitions in test code image: Fix crash in _fill_xrgb32_lerp_opaque_spans gitignore: logs, manuals doc: Drop extraneous para's git-ignore: Add build's test-driver Revert "xlib: Remove queued event from _XReadEvents" csi-trace: Add --version and --help args to utility HACKING: Add link to git tutorial and wordsmith a bit NEWS: Update for changes through Nov 2014 NEWS: Finish filling in changes On MacOSX, the sed utility errors out when parsing non-UTF8 files NEWS: Note about the OS X support KNOWN_ISSUES: Restore known issues file as a stub version: bump for cairo-1.14.2 release RELEASING: Update contacts Start 1.14.3 development surface: Clarify flush documentation NEWS: Sp. fix Fix spellings descibed, indicies, stange Fix broken canvas text font size in Inkscape cairo-script: Improve buffer length check cairo-script: Always include config.h first thing cairo-script: Add missing copyright and boilerplate cairo-script: Cleanup boilerplate header for consistency cairo-script: Prefer cairo from local tree cairo-script: Rename struct member to avoid name collision on AIX cairo-script: Fix sp. "directoriy" cairo-recording-surface: Fix loss of alpha when clipping cairo-script: Return a cairo_status_t error, not FALSE configure: Fix typo for missing line continuation character test: Free the memory, not the pointer to the memory boilerplate: Fix list termination for glXChooseVisual Ensure null-terminated result from strncpy() Revert "pattern: allow for a floating one pixel rounded difference." Revert "win32: Add cairo API to set up a Win32 surface for an HDC with an alpha channel." NEWS: Update for 1.14.4 release 1.14.4 release Chris Wilson (1): xlib: Bump reference count for recording surface replays Emanuele Aina (1): cairo-trace: Fix duplicated surface push on similar-image Fredrik Fornwall (1): Fix cairo_get_locale_decimal_point() on Android Hans Breuer (1): win32: Fix compilation of 'cairo-path-stroke-traps.c' with MSVC8 Henry (Yu) Song (1): xlib: Remove queued event from _XReadEvents Julien Isorce (1): build: Show all disabled features in cairo-features.h Massimo Valentini (6): tor-scan-converter: can't do_fullrow when intersection in row + 0.5subrow win32: Fix crash from win32 surface's image size too small polygon-intersection: Do not discard intersection exactly at top edge polygon-intersection: Include approximation in intersection points polygon-intersection: Try not to invoke undefined behaviour polygon-intersection: Delete misleading comments and dead-code Michael Haubenwallner (8): fix conflicting types for 'sync' on AIX, bug#89338 skip MAP_NORESERVE when unsupported define _GETDELIM for getline() on AIX test: fix include order for AIX, bug#89354 perf/micro: fix include order for AIX, bug#89354 perf: fix include order for AIX, bug#89354 headers: fix include order for AIX, bug#89354 headers: fix include order for AIX, bug#89354 Nathan Froyd (1): Support new-style __atomic_* primitives Ravi Nanjundappa (2): Fix warnings from check-doc-syntax.sh Fix one more warning from check-doc-syntax.sh Rodrigo Rivas Costa (1): win32-print: fix transparent images have black background Sahil Vij (1): gl: Fix bug in _cairo_gl_pattern_texture_setup() Uli Schlachter (6): tor-scan-converter: Correctly align 64bit types XCB: Don't attach uploaded surfaces as snapshots xcb: Query the display's subpixel order via RENDER xlib-xcb: Don't be lazy and use the real xcb_screen_t xcb: Fix _put_shm_image_boxes if no SHM available xcb: Fix _put_image_boxes() if no SHM is available Zan Dobersek (1): Manually transpose the matrix in _cairo_gl_shader_bind_matrix() Руслан Ижбулатов (2): win32: Add cairo API to set up a Win32 surface for an HDC with an alpha channel. win32: Add a win32 boilerplate that uses a real window 江頭幸路 (1): Avoid appending an empty slot to an user data array when user_data is NULL.