[cairo-commit] 11 commits - BIBLIOGRAPHY doc/bibliography.md doc/releasing.md KNOWN_ISSUES NEWS perf/cairo-perf-graph-files.c perf/cairo-perf-graph-widget.c PORTING_GUIDE README README.md RELEASING src/cairo-version.h version.py
GitLab Mirror
gitlab-mirror at kemper.freedesktop.org
Thu Feb 2 10:24:34 UTC 2023
BIBLIOGRAPHY | 109 ----------------
KNOWN_ISSUES | 3
NEWS | 52 +++++++-
PORTING_GUIDE | 265 -----------------------------------------
README | 184 ----------------------------
README.md | 177 +++++++++++++++++++++++++++
RELEASING | 215 ---------------------------------
doc/bibliography.md | 103 +++++++++++++++
doc/releasing.md | 175 +++++++++++++++++++++++++++
perf/cairo-perf-graph-files.c | 2
perf/cairo-perf-graph-widget.c | 2
src/cairo-version.h | 2
version.py | 60 ++++++---
13 files changed, 548 insertions(+), 801 deletions(-)
New commits:
commit 260f0fd9eca387ffa9fc45eef8e74b5e7dce7b5d
Merge: 365bec1f7 b1a18123e
Author: Emmanuele Bassi <ebassi at gmail.com>
Date: Thu Feb 2 10:24:31 2023 +0000
Merge branch 'ebassi/snapshot-release' into 'master'
Cairo 1.17.8 snapshot
See merge request cairo/cairo!436
commit b1a18123edf3f6f01d2c818c02b9bf9f55a09c0d
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Thu Feb 2 10:45:25 2023 +0100
Post-release version bump to 1.17.9
diff --git a/src/cairo-version.h b/src/cairo-version.h
index 422360741..3ac065f68 100644
--- a/src/cairo-version.h
+++ b/src/cairo-version.h
@@ -3,6 +3,6 @@
#define CAIRO_VERSION_MAJOR 1
#define CAIRO_VERSION_MINOR 17
-#define CAIRO_VERSION_MICRO 8
+#define CAIRO_VERSION_MICRO 9
#endif
commit c3b672634f0635af1ad0ffa8c15b34fc7c1035cf
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 14:51:28 2023 +0000
Release Cairo 1.17.8 (snapshot)
diff --git a/NEWS b/NEWS
index a6b14d937..29e4a0aa0 100644
--- a/NEWS
+++ b/NEWS
@@ -1,16 +1,58 @@
+Release 1.17.8 (2023-01-30 Emmanuele Bassi <ebassi at gnome.org>)
+==============================================================
+
+A new cairo snapshot! And it only took less than one year, this time!
+
+Many thanks to everyone who contributed to cairo, and especially
+to (in no particular order):
+
+- Adrian Johnson
+- Khaled Hosny
+- Behdad Esfahbod
+- Matthias Clasen
+- Uli Schlachter
+- Manuel Stoeckl
+- Fujii Hironori
+- Tim-Philipp Müller
+- Luca Bacci
+- Caolán McNamara
+- John Ralls
+
+In a continuing effort to reduce the amount of legacy code, and increase
+the long-term maintainability of cairo, the following backends have been
+removed:
+
+- GL and GLES drawing
+
+Additionally, cairo's Autotools build system has been removed; from now on,
+cairo will only support the Meson build system. While the end result should
+be identical, further testing is appreciated.
+
+In this snapshot, cairo gained support for rendering COLRv1 fonts, and
+rendering SVG and COLRv1 fonts with custom palettes.
+
+Support for macOS and Windows has been improved, with lots of build and bug
+fixes.
+
+Lots of safety issues have been fixed, with array bounds checking and
+plugging memory leaks, as well as fixes for bugs identified via fuzzying.
+
+This is going to be the last snapshot of the 1.17 development cycle; we only
+expect minor bug fixing and improvements until the 1.18.0 release.
+
Release 1.17.6 (2022-03-18 Emmanuele Bassi <ebassi at gnome.org>)
==============================================================
-I spy with my little eye… a Cairo snapshot!
+I spy with my little eye… a cairo snapshot!
-First of all, many, many thanks to everyone who contributed to Cairo
+First of all, many, many thanks to everyone who contributed to cairo
during this development cycle. A special thank you goes to:
- Adrian Johnson
- Uli Schlachter
for their tireless efforts in ensuring that the lights are still on
-in the Cairo project.
+in the cairo project.
This snapshot sees the removal of the following backends and platform
support:
@@ -24,7 +66,7 @@ support:
- OpenVG
Thanks to all past contributors for their work on them. If you were using
-any of these backends then you will need to stick to Cairo 1.16.
+any of these backends then you will need to stick to cairo 1.16.
To offset the removal of the backends above, Adrian Johnson landed the
DWrite font rendering backend on Windows.
@@ -34,7 +76,7 @@ John Ralls.
Tim-Philipp Müller has kept the Meson build in top shape.
-This snapshot is going to be the **last** release of Cairo with the
+This snapshot is going to be the **last** release of cairo with the
Autotools build system. The Meson build has seen many improvements and
it is considerably easier to maintain and faster to build.
diff --git a/src/cairo-version.h b/src/cairo-version.h
index b64b48902..422360741 100644
--- a/src/cairo-version.h
+++ b/src/cairo-version.h
@@ -3,6 +3,6 @@
#define CAIRO_VERSION_MAJOR 1
#define CAIRO_VERSION_MINOR 17
-#define CAIRO_VERSION_MICRO 7
+#define CAIRO_VERSION_MICRO 8
#endif
commit cd988448f9ed0aa3bf8e0441549bee77149d7317
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 15:32:40 2023 +0000
docs: Port the README to Markdown
And clean it up a little bit.
diff --git a/README b/README
deleted file mode 100644
index 40df870f2..000000000
--- a/README
+++ /dev/null
@@ -1,184 +0,0 @@
-Cairo - Multi-platform 2D graphics library
-https://cairographics.org
-
-What is cairo
-=============
-Cairo is a 2D graphics library with support for multiple output
-devices. Currently supported output targets include the X Window
-System (via both Xlib and XCB), quartz, win32, and image buffers,
-as well as PDF, PostScript, and SVG file output. Experimental backends
-include OpenGL.
-
-Cairo is designed to produce consistent output on all output media
-while taking advantage of display hardware acceleration when available
-(for example, through the X Render Extension).
-
-The cairo API provides operations similar to the drawing operators of
-PostScript and PDF. Operations in cairo include stroking and filling
-cubic Bézier splines, transforming and compositing translucent images,
-and antialiased text rendering. All drawing operations can be
-transformed by any affine transformation (scale, rotation, shear,
-etc.).
-
-Cairo has been designed to let you draw anything you want in a modern
-2D graphical user interface. At the same time, the cairo API has been
-designed to be as fun and easy to learn as possible. If you're not
-having fun while programming with cairo, then we have failed
-somewhere---let us know and we'll try to fix it next time around.
-
-Cairo is free software and is available to be redistributed and/or
-modified under the terms of either the GNU Lesser General Public
-License (LGPL) version 2.1 or the Mozilla Public License (MPL) version
-1.1.
-
-Where to get more information about cairo
-=========================================
-The primary source of information about cairo is:
-
- https://cairographics.org/
-
-The latest versions of cairo can always be found at:
-
- https://cairographics.org/download
-
-Documentation on using cairo and frequently-asked questions:
-
- https://cairographics.org/documentation
- https://cairographics.org/FAQ
-
-Mailing lists for contacting cairo users and developers:
-
- https://cairographics.org/lists
-
-Roadmap and unscheduled things to do, (please feel free to help out):
-
- https://cairographics.org/roadmap
- https://cairographics.org/todo
-
-Dependencies
-============
-The set of libraries needed to compile cairo depends on which backends
-are enabled when cairo is configured. So look at the list below to
-determine which dependencies are needed for the backends of interest.
-
-For the surface backends, we have both "supported" and "experimental"
-backends. Further, the supported backends can be divided into the
-"standard" backends which can be easily built on any platform, and the
-"platform" backends which depend on some underlying platform-specific
-system, (such as the X Window System or some other window system).
-
-As an example, for a standard Linux build similar to what's shipped by
-your distro, (with image, png, pdf, PostScript, svg, and xlib surface
-backends, and the freetype font backend), the following sample commands
-will install necessary dependencies:
-
- Debian (and similar):
-
- apt-get build-dep cairo
-
- Fedora (and similar):
-
- yum install libpng-devel zlib-devel libXrender-devel fontconfig-devel
-
-Technically you probably don't need pixman from the distribution since
-if you're manually compiling Cairo you probably want an updated pixman
-as well. However, if you follow the default settings and install pixman
-to /usr/local, your Cairo build should properly use it in preference to
-the system pixman.
-
-
-Supported, "standard" surface backends
-------------------------------------
- image backend (required)
- ------------------------
- pixman >= 0.30.0 https://cairographics.org/releases
-
- png support (can be left out if desired, but many
- ----------- applications expect it to be present)
- libpng http://www.libpng.org/pub/png/libpng.html
-
- pdf backend
- -----------
- zlib http://www.gzip.org/zlib
-
- postscript backend
- ------------------
- zlib http://www.gzip.org/zlib
-
- svg backend
- -----------
- [none]
-
-Supported, "platform" surface backends
------------------------------------
- xlib backend
- ------------
- X11 https://freedesktop.org/Software/xlibs
-
- xlib-xrender backend
- --------------------
- Xrender >= 0.6 https://freedesktop.org/Software/xlibs
-
- quartz backend
- --------------
- MacOS X >= 10.4 with Xcode >= 2.5
-
- win32 backend
- -------------
- Microsoft Windows 2000 or newer[*].
-
- xcb backend
- -----------
- XCB https://xcb.freedesktop.org
-
-Font backends (required to have at least one)
----------------------------------------------
- freetype font backend
- ---------------------
- freetype >= 2.1.9 http://freetype.org
- fontconfig http://fontconfig.org
-
- quartz-font backend
- -------------------
- MacOS X >= 10.4 with Xcode >= 2.4
-
- win32 font backend
- ------------------
- Microsoft Windows 2000 or newer[*].
-
- [*] The Win32 backend should work on Windows 2000 and newer
- (excluding Windows Me.) Most testing has been done on
- Windows XP. While some portions of the code have been
- adapted to work on older versions of Windows, considerable
- work still needs to be done to get cairo running in those
- environments.
-
- Cairo can be compiled on Windows with either the gcc
- toolchain (see http://www.mingw.org) or with Microsoft
- Visual C++. If the gcc toolchain is used, the standard
- build instructions using configure apply, (see INSTALL).
- If Visual C++ is desired, GNU make is required and
- Makefile.win32 can be used via 'make -f Makefile.win32'.
- The compiler, include paths, and library paths must be set
- up correctly in the environment.
-
- MSVC versions earlier than 7.1 are known to miscompile
- parts of cairo and pixman, and so should be avoided. MSVC
- 7.1 or later, including the free Microsoft Visual Studio
- Express editions, produce correct code.
-
-
-Compiling
-=========
-See the INSTALL document for build instructions.
-
-
-History
-=======
-Cairo was originally developed by Carl Worth <cworth at cworth.org> and
-Keith Packard <keithp at keithp.com>. Many thanks are due to Lyle Ramshaw
-without whose patient help our ignorance would be much more apparent.
-
-Since the original development, many more people have contributed to
-cairo. See the AUTHORS files for as complete a list as we've been able
-to compile so far.
diff --git a/README.md b/README.md
new file mode 100644
index 000000000..025f8486d
--- /dev/null
+++ b/README.md
@@ -0,0 +1,177 @@
+# Cairo: Multi-platform 2D graphics library
+
+<https://cairographics.org>
+
+What is cairo
+-------------
+
+Cairo is a 2D graphics library with support for multiple output
+devices. Currently supported output targets include the X Window
+System (via both Xlib and XCB), quartz, win32, and image buffers,
+as well as PDF, PostScript, and SVG file output. Experimental backends
+include OpenGL.
+
+Cairo is designed to produce consistent output on all output media
+while taking advantage of display hardware acceleration when available
+(for example, through the X Render Extension).
+
+The cairo API provides operations similar to the drawing operators of
+PostScript and PDF. Operations in cairo include stroking and filling
+cubic Bézier splines, transforming and compositing translucent images,
+and antialiased text rendering. All drawing operations can be
+transformed by any affine transformation (scale, rotation, shear,
+etc.).
+
+Cairo has been designed to let you draw anything you want in a modern
+2D graphical user interface. At the same time, the cairo API has been
+designed to be as fun and easy to learn as possible. If you're not
+having fun while programming with cairo, then we have failed
+somewhere---let us know and we'll try to fix it next time around.
+
+Cairo is free software and is available to be redistributed and/or
+modified under the terms of either the GNU Lesser General Public
+License (LGPL) version 2.1 or the Mozilla Public License (MPL) version
+1.1.
+
+Where to get more information about cairo
+-----------------------------------------
+
+The primary source of information about cairo is its website:
+
+- <https://cairographics.org>
+
+The latest versions of cairo can always be found at:
+
+- <https://cairographics.org/download>
+
+Documentation on using cairo and frequently-asked questions:
+
+- <https://cairographics.org/documentation>
+- <https://cairographics.org/FAQ>
+
+Mailing lists for contacting cairo users and developers:
+
+- <https://cairographics.org/lists>
+
+Roadmap and unscheduled things to do, (please feel free to help out):
+
+- https://cairographics.org/roadmap
+- https://cairographics.org/todo
+
+Dependencies
+------------
+
+The set of libraries needed to compile cairo depends on which backends are
+enabled when cairo is configured. So look at the list below to determine
+which dependencies are needed for the backends of interest.
+
+For the surface backends, we have both "supported" and "experimental"
+backends. Further, the supported backends can be divided into the "standard"
+backends which can be easily built on any platform, and the "platform"
+backends which depend on some underlying platform-specific system, (such as
+the X Window System or some other window system).
+
+As an example, for a standard Linux build similar to what's shipped by your
+distro, (with image, png, pdf, PostScript, svg, and xlib surface backends,
+and the freetype font backend), the following sample commands will install
+necessary dependencies:
+
+- Debian (and similar):
+ - `apt-get build-dep cairo`
+
+- Fedora (and similar):
+ - `dnf builddep cairo`
+
+Technically you probably don't need pixman from the distribution since if
+you're manually compiling Cairo you probably want an updated pixman as well.
+However, if you follow the default settings and install pixman to
+/usr/local, your Cairo build should properly use it in preference to the
+system pixman.
+
+
+### Supported, "standard" surface backends
+
+#### image backend (required)
+
+- [pixman](https://cairographics.org/releases) >= 0.30.0
+
+#### PNG support (preferred)
+
+- [libpng](http://www.libpng.org/pub/png/libpng.html)
+
+#### PDF backend
+
+- [zlib](http://www.gzip.org/zlib)
+
+#### PostScript backend
+
+- [zlib](http://www.gzip.org/zlib)
+
+#### SVG backend
+
+- none
+
+### Supported, "platform" surface backends
+
+#### Xlib backend
+
+- [X11](https://freedesktop.org/Software/xlibs)
+
+#### xlib-xrender backend
+
+- [Xrender](https://freedesktop.org/Software/xlibs) >= 0.6
+
+#### Quartz backend
+
+- macOS >= 10.4 with Xcode >= 2.5
+
+#### Windows backend
+
+- Microsoft Windows 2000 or newer.
+
+#### XCB backend
+
+- [XCB](https://xcb.freedesktop.org)
+
+### Font backends (required)
+
+#### freetype font backend
+
+- [freetype](https://freetype.org) >= 2.1.9
+- [fontconfig](https://www.freedesktop.org/wiki/Software/fontconfig/)
+
+#### Quartz-font backend
+
+- MacOS X >= 10.4 with Xcode >= 2.5
+
+#### Windows GDI font backend
+
+- Microsoft Windows 2000 or newer
+
+#### Windows DirectWrite font backend
+
+- Microsoft Windows 7 or newer
+
+Compiling
+---------
+
+See the [`INSTALL`](./INSTALL) document for build instructions.
+
+Licensing
+---------
+
+Cairo is released under the terms of either the GNU Lesser General Public
+License version 2.1, or the terms of the Mozilla Public License version 1.1.
+
+See the [`COPYING`](./COPYING) document for more information.
+
+History
+-------
+
+Cairo was originally developed by Carl Worth <cworth at cworth.org> and Keith
+Packard <keithp at keithp.com>. Many thanks are due to Lyle Ramshaw without
+whose patient help our ignorance would be much more apparent.
+
+Since the original development, many more people have contributed to cairo.
+See the [`AUTHORS`](./AUTHORS) document for as complete a list as we've been
+able to compile so far.
commit 08688d5c9864f3796fb7fa0393e075b8f0d90041
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 15:18:44 2023 +0000
docs: Remove KNOWN_ISSUES
Cairo is perfect, and has no known issues outside of the ones that are
listed in the issue tracker.
diff --git a/KNOWN_ISSUES b/KNOWN_ISSUES
deleted file mode 100644
index c367f918e..000000000
--- a/KNOWN_ISSUES
+++ /dev/null
@@ -1,3 +0,0 @@
-Known Issues
-------------
-None
commit af5fa7973acff8ddef0ea17cd34ee96cda8124cb
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 15:17:52 2023 +0000
docs: Drop the pre-1.0 porting guide
It's been nearly 20 years; time to let it go.
diff --git a/PORTING_GUIDE b/PORTING_GUIDE
deleted file mode 100644
index 7488173c4..000000000
--- a/PORTING_GUIDE
+++ /dev/null
@@ -1,265 +0,0 @@
- ...-----=======-----...
- Cairo 1.0 Porting Guide
- ...-----=======-----...
-
-Here are some notes on more easily porting cairo_code from cairo 0.4
-to cairo 1.0. It is sorted roughly in order of importance, (the items
-near the top are expected to affect the most people).
-
-Automated API renamings
-=======================
-There have been a lot of simple renamings where the functionality is
-the same but the name of the symbol is different. We have provided a
-script to automate the conversion of these symbols. It can be found
-within the cairo distribution in:
-
- util/cairo-api-update
-
-This script is used by installing it somewhere on your PATH, and the
-running it and providing the names of your source files on the command
-line. For example:
-
- cairo-api-update *.[ch]
-
-The script will first save backup copies of each file (renamed with a
-.bak extension) and then will perform all of the simple renamings.
-
-For your benefit, the script also produces messages giving filenames
-and line numbers for several of the manual API updates that you will
-need to perform as described below.
-
-
-Manual API changes
-==================
-This section of the porting guide describes changes you will have to
-manually make to your source code. In addition to the information in
-this guide, the cairo-api-update script will notify you of some of
-these issues as described above.
-
-Cairo's deprecation warnings
-----------------------------
-Also, if your compiler provides warnings for implicit declarations of
-functions, (eg. "gcc -Wall"), then simply attempting to compile your
-program will cause cairo to generate messages intended to guide you
-through the porting process.
-
-For example, if you neglect to update an old call to
-cairo_set_target_drawable, you might see an error message as follows:
-
- foo.c:10: warning: implicit declaration of function
- ‘cairo_set_target_drawable_DEPRECATED_BY_cairo_xlib_surface_create’
-
-This message is indicating to you that the deprecatd function
-cairo_set_target_drawable appears in your program foo.c on line 10,
-and you should rewrite your program to call cairo_xlib_surface_create
-instead.
-
-The remainder of this porting guide is arranged as a set of common
-code patterns that appear in old (cairo-0.4) code and how it should be
-transformed to new (cairo-0.5) code.
-
-cairo_create
-------------
-Was: cr = cairo_create ();
- cairo_set_target_foo (cr, args);
- /* draw */
- cairo_destroy (cr);
-
-Now: cairo_surface_t *surface;
-
- surface = cairo_foo_surface_create (args);
- cr = cairo_create (surface);
- /* draw */
- cairo_destroy (cr);
- cairo_surface_destroy (surface);
-
-Or: cairo_surface_t *surface;
-
- surface = cairo_foo_surface_create (args);
- cr = cairo_create (surface);
- cairo_surface_destroy (surface);
- /* draw */
- cairo_destroy (cr);
-
-NOTE: Many of the cairo_foo_surface_create functions accept the
- identical arguments as the the old cairo_set_target_foo
- functions, (minus the cairo_t*), making this transformation
- quite easy. One notable exception is cairo_set_target_drawable
- which, when it becomes cairo_xlib_surface_create must pickup new
- arguments for the Visual*, the width, and the height.
-
-cairo_set_alpha (1)
--------------------
-Was: cairo_set_rgb_color (cr, red, green, blue);
- cairo_set_alpha (cr, alpha);
-
-Now: cairo_set_source_rgba (cr, red, green, blue, alpha);
-
-cairo_show_surface
-------------------
-Was: cairo_show_surface (cr, surface, width, height);
-
-Now: cairo_set_source_surface (cr, surface, x, y);
- cairo_paint (cr);
-
-NOTE: The type signatures of cairo_show_surface and cairo_set_source
- are the same, but pay attention that cairo_show_surface required
- the width and height, while cairo_set_source_surface requires
- the X,Y location to where the surface will be placed.
-
-cairo_set_alpha (2)
--------------------
-Was: cairo_set_alpha (cr, alpha);
- cairo_show_surface (cr, surface, width, height);
-
-Now: cairo_set_source_surface (cr, surface, x, y);
- cairo_paint_with_alpha (cr, alpha);
-
-filling and stroking
---------------------
-Was: cairo_save (cr);
- /* set fill color */
- cairo_fiill (cr);
- cairo_restore (cr);
- /* set stroke color */
- cairo_stroke (cr);
-
-Now: /* set fill color */
- cairo_fill_preserve (cr);
- /* set stroke color */
- cairo_stroke (cr);
-
-NOTE: The current path is no longer saved/restored by
- cairo_save/cairo_restore. This can lead to some subtle
- surprises, so look out.
-
-cairo_matrix_t
---------------
-Was: cairo_matrix_t *matrix;
-
- matrix = cairo_matrix_create ();
- /* Do stuff with matrix */
- cairo_matrix_destroy (matrix);
-
-Now: cairo_matrix_t matrix;
- cairo_matrix_init_identity (&matrix);
- /* Do stuff with &matrix */
-
-NOTE: If you are really lazy, you can still use a cairo_matrix_t* and
- avoid putting the &matrix all over by just replacing
- cairo_matrix_create() with malloc() and cairo_matrix_destroy()
- with free(). That's not as nice, and you still need to be
- careful to see if you need to initialize it to an identity
- matrix as cairo_matrix_create() did for you.
-
-Rendering to a temporary surface
---------------------------------
-Was: cairo_save (cr);
- {
- cairo_set_target_surface (cr, temporary);
- /* draw through cr onto temporary */
- }
- cairo_restore (cr);
- /* use temporary as source on cr */
-
-Now: {
- cr2 = cairo_create (temporary);
- /* draw through cr2 onto temporary */
- cairo_destory (cr2);
- }
- /* use temporary as source on cr */
-
-NOTE: Having to create another cairo_t is a bit annoying, but having
- to invent a new name for it is just awful, (imagine a deeply
- nested version of this code). Fortunately, the style above is
- just a stop-gap measure until the new group API comes along.
-
-Iterating over a path
----------------------
-Was: cairo_current_path (cr,
- my_move_to,
- my_line_to,
- my_curve_to,
- my_close_path,
- closure);
-
-Now: int i;
- cairo_path_t *path;
- cairo_path_data_t *data;
-
- path = cairo_copy_path (cr);
-
- for (i=0; i < path->num_data; i += path->data[i].header.length) {
- data = &path->data[i];
- switch (data->header.type) {
- case CAIRO_PATH_MOVE_TO:
- my_move_to (closure, data[1].point.x, data[1].point.y);
- break;
- case CAIRO_PATH_LINE_TO:
- my_line_to (closure, data[1].point.x, data[1].point.y);
- break;
- case CAIRO_PATH_CURVE_TO:
- my_curve_to (closure, data[1].point.x, data[1].point.y,
- data[2].point.x, data[2].point.y,
- data[3].point.x, data[3].point.y);
- break;
- case CAIRO_PATH_CLOSE_PATH:
- my_close_path (closure);
- break;
- }
- }
- cairo_path_destroy (path);
-
-NOTE: This version makes it looks like the new form is a _lot_ more
- verbose than the old version. But realize that the old version
- required the support of 4 additional functions. The new approach
- allows great flexibility including the ability to inline the
- entire operation within the switch statement when appropriate.
-
-Erasing a surface to transparent
---------------------------------
-Was: cairo_set_rgb_color (cr, 0., 0., 0.);
- cairo_set_alpha (cr, 0.)
- cairo_set_operator (cr, CAIRO_OPERATOR_SRC);
- cairo_rectangle (cr, 0., 0., surface_width, surface_height);
- cairo_fill (cr);
-
- or: cairo_set_rgb_color (cr, 0., 0., 0.);
- cairo_set_operator (cr, CAIRO_OPERATOR_CLEAR);
- cairo_rectangle (cr, 0., 0., surface_width, surface_height);
- cairo_fill (cr);
-
-Now: cairo_set_source_rgba (cr, 0., 0., 0., 0.);
- cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
- cairo_paint (cr);
-
- or: cairo_set_operator (cr, CAIRO_OPERATOR_CLEAR);
- cairo_paint (cr);
-
-NOTE: Using cairo_rectangle and fill would still work just fine. It's
- just a lot more convenient to use cairo_paint now, (particularly
- as it doesn't require you to even know what the bounds of the
- target surface are).
-
-Drawing to a PNG file
----------------------
-Was: file = fopen (filename, "w");
- cr = cairo_create ();
- cairo_set_target_png (cr, file, format, width, height);
- /* draw image */
- cairo_destroy (cr);
- fclose (file);
-
-Now: surface = cairo_image_surface_create (format, width, height);
- cr = cairo_create (surface);
- /* draw image */
- cairo_surface_write_to_png (surface, filename);
- cairo_destroy (cr);
- cairo_surface_destroy (surface);
-
-NOTE: The png backend is gone. So there is no cairo_png_surface_create
- to take the place of cairo_set_target_png. And notice that we
- used an image surface here, but it is just as easy to use
- cairo_surface_write_to_png with an xlib or other surface, (but
- not PDF at the moment). This is one of the big advantages of
- this approach as opposed to a PNG surface.
commit 98fa4be56b80a2add1d1f65325c060b1f4cae7e2
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 15:17:26 2023 +0000
docs: Update the bibliography
Port to Markdown.
diff --git a/doc/bibliography.md b/doc/bibliography.md
index 90a6cef20..f3452243a 100644
--- a/doc/bibliography.md
+++ b/doc/bibliography.md
@@ -1,109 +1,103 @@
+# Bibliography
+
Here's an effort to document some of the academic work that was
referenced during the implementation of cairo. It is presented in the
context of operations as they would be performed by either
-cairo_stroke() or cairo_fill():
+`cairo_stroke()` or `cairo_fill()`:
Given a Bézier path, approximate it with line segments:
- The deCasteljau algorithm
- "Outillages methodes calcul", P de Casteljau, technical
- report, - Andre Citroen Automobiles SA, Paris, 1959
+- The deCasteljau algorithm
+ "Outillages methodes calcul", P de Casteljau, technical
+ report, - Andre Citroen Automobiles SA, Paris, 1959
- That technical report might be "hard" to find, but fortunately
- this algorithm will be described in any reasonable textbook on
- computational geometry. Two that have been recommended by
- cairo contributors are:
+Note: That technical report might be "hard" to find, but fortunately this
+algorithm will be described in any reasonable textbook on computational
+geometry. Two that have been recommended by cairo contributors are:
- "Computational Geometry, Algorithms and Applications", M. de
- Berg, M. van Kreveld, M. Overmars, M. Schwarzkopf;
- Springer-Verlag, ISBN: 3-540-65620-0.
+- "Computational Geometry, Algorithms and Applications", M. de
+ Berg, M. van Kreveld, M. Overmars, M. Schwarzkopf;
+ Springer-Verlag, ISBN: 3-540-65620-0.
- "Computational Geometry in C (Second Edition)", Joseph
- O'Rourke, Cambridge University Press, ISBN 0521640105.
+- "Computational Geometry in C (Second Edition)", Joseph O'Rourke,
+ Cambridge University Press, ISBN 0521640105.
Then, if stroking, construct a polygonal representation of the pen
approximating a circle (if filling skip three steps):
- "Good approximation of circles by curvature-continuous Bezier
- curves", Tor Dokken and Morten Daehlen, Computer Aided
- Geometric Design 8 (1990) 22-41.
+- "Good approximation of circles by curvature-continuous Bezier
+ curves", Tor Dokken and Morten Daehlen, Computer Aided
+ Geometric Design 8 (1990) 22-41.
-Add points to that pen based on the initial/final path faces and take
-the convex hull:
+Add points to that pen based on the initial/final path faces and take the
+convex hull:
- Convex hull algorithm
+- Convex hull algorithm
- [Again, see your favorite computational geometry
- textbook. Should cite the name of the algorithm cairo uses
- here, if it has a name.]
+[Again, see your favorite computational geometry textbook. Should cite the
+name of the algorithm cairo uses here, if it has a name.]
Now, "convolve" the "tracing" of the pen with the tracing of the path:
- "A Kinetic Framework for Computational Geometry", Leonidas
- J. Guibas, Lyle Ramshaw, and Jorge Stolfi, Proceedings of the
- 24th IEEE Annual Symposium on Foundations of Computer Science
- (FOCS), November 1983, 100-111.
+- "A Kinetic Framework for Computational Geometry", Leonidas
+ J. Guibas, Lyle Ramshaw, and Jorge Stolfi, Proceedings of the
+ 24th IEEE Annual Symposium on Foundations of Computer Science
+ (FOCS), November 1983, 100-111.
The result of the convolution is a polygon that must be filled. A fill
operations begins here. We use a very conventional Bentley-Ottmann
pass for computing the intersections, informed by some hints on robust
implementation courtesy of John Hobby:
- John D. Hobby, Practical Segment Intersection with Finite
- Precision Output, Computation Geometry Theory and
- Applications, 13(4), 1999.
-
- http://cm.bell-labs.com/who/hobby/93_2-27.pdf
+- John D. Hobby, Practical Segment Intersection with Finite
+ Precision Output, Computation Geometry Theory and
+ Applications, 13(4), 1999.
+ <http://cm.bell-labs.com/who/hobby/93_2-27.pdf>
Hobby's primary contribution in that paper is his "tolerance square"
algorithm for robustness against edges being "bent" due to restricting
intersection coordinates to the grid available by finite-precision
arithmetic. This is one algorithm we have not implemented yet.
-We use a data-structure called Skiplists in the our implementation
-of Bentley-Ottmann:
-
- W. Pugh, Skip Lists: a Probabilistic Alternative to Balanced Trees,
- Communications of the ACM, vol. 33, no. 6, pp.668-676, 1990.
+We use a data-structure called Skiplists in the our implementation of
+Bentley-Ottmann:
- http://citeseer.ist.psu.edu/pugh90skip.html
+- W. Pugh, Skip Lists: a Probabilistic Alternative to Balanced Trees,
+ Communications of the ACM, vol. 33, no. 6, pp.668-676, 1990.
+ <http://citeseer.ist.psu.edu/pugh90skip.html>
-The random number generator used in our skip list implementation is a
-very small generator by Hars and Petruska. The generator is based on
-an invertable function on Z_{2^32} with full period and is described
-in
+The random number generator used in our skip list implementation is a very
+small generator by Hars and Petruska. The generator is based on an
+invertable function on Z_{2^32} with full period and is described in
- Hars L. and Petruska G.,
- ``Pseudorandom Recursions: Small and Fast Pseurodandom
- Number Generators for Embedded Applications'',
- Hindawi Publishing Corporation
- EURASIP Journal on Embedded Systems
- Volume 2007, Article ID 98417, 13 pages
- doi:10.1155/2007/98417
+- Hars L. and Petruska G.,
+ Pseudorandom Recursions: Small and Fast Pseurodandom
+ Number Generators for Embedded Applications,
+ Hindawi Publishing Corporation
+ EURASIP Journal on Embedded Systems
+ Volume 2007, Article ID 98417, 13 pages
+ doi:10.1155/2007/98417
+ <http://www.hindawi.com/getarticle.aspx?doi=10.1155/2007/98417&e=cta>
- http://www.hindawi.com/getarticle.aspx?doi=10.1155/2007/98417&e=cta
-
-From the result of the intersection-finding pass, we are currently
-computing a tessellation of trapezoids, (the exact manner is
-undergoing some work right now with some important speedup), but we
-may want to rasterize directly from those edges at some point.
+From the result of the intersection-finding pass, we are currently computing
+a tessellation of trapezoids, (the exact manner is undergoing some work
+right now with some important speedup), but we may want to rasterize
+directly from those edges at some point.
Given the set of tessellated trapezoids, we currently execute a
-straightforward, (and slow), point-sampled rasterization, (and
-currently with a near-pessimal regular 15x17 grid).
+straightforward, (and slow), point-sampled rasterization, (and currently
+with a near-pessimal regular 15x17 grid).
We've now computed a mask which gets fed along with the source and
-destination into cairo's fundamental rendering equation. The most
-basic form of this equation is:
-
- destination = (source IN mask) OP destination
+destination into cairo's fundamental rendering equation. The most basic form
+of this equation is:
-with the restriction that no part of the destination outside the
-current clip region is affected. In this equation, IN refers to the
-Porter-Duff "in" operation, while OP refers to a any user-selected
-Porter-Duff operator:
+ destination = (source IN mask) OP destination
- T. Porter & T. Duff, Compositing Digital Images Computer
- Graphics Volume 18, Number 3 July 1984 pp 253-259
+with the restriction that no part of the destination outside the current
+clip region is affected. In this equation, IN refers to the Porter-Duff "in"
+operation, while OP refers to a any user-selected Porter-Duff operator:
- http://keithp.com/~keithp/porterduff/p253-porter.pdf
+- T. Porter & T. Duff, Compositing Digital Images Computer
+ Graphics Volume 18, Number 3 July 1984 pp 253-259
+ <http://keithp.com/~keithp/porterduff/p253-porter.pdf>
commit d86a22db6d512b344a61843107f888d6f12c98fe
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 15:12:42 2023 +0000
docs: Update the release instruction
Mainly drop the Autotools-related stuff, and use Markdown.
diff --git a/doc/releasing.md b/doc/releasing.md
index 04c78e20a..ab5abb62b 100644
--- a/doc/releasing.md
+++ b/doc/releasing.md
@@ -1,215 +1,175 @@
-Here are the steps to follow to create a new cairo release:
+# Releasing Cairo
-0) Decide type of release and checkout the appropriate branch.
+Here are the steps to follow to create a new cairo release:
- The Cairo project makes three types of releases: Development
- snapshot releases, stable minor releases, and stable micro (aka
- "point") releases. Micro releases should be only bugfixes and
- no API additions. If there are API additions consider making a
- Minor release. Snapshot releases can be done of the current
- development tree between Minor releases, as desired.
+## 0. Decide type of release and checkout the appropriate branch
- For stable releases (both minor and micro), the work should be
- done on the given release branch. E.g. for 1.14.12, check out
- the 1.14 branch via "git checkout origin/1.14 -b 1.14".
+The Cairo project makes three types of releases: Development snapshot
+releases, stable minor releases, and stable micro (aka "point") releases.
+Micro releases should be only bugfixes and no API additions. If there are
+API additions consider making a Minor release. Snapshot releases can be
+done of the current development tree between Minor releases, as desired.
-1) Ensure that there are no local, uncommitted/unpushed mods.
+For stable releases (both minor and micro), the work should be done on the
+given release branch. E.g. for 1.14.12, check out the 1.14 branch via "git
+checkout origin/1.14 -b 1.14".
- You're probably in a good state if both "git diff
- HEAD" and "git log master..origin/master" give no output. Also make
- sure you have libglib2.0-doc installed (else you'll get
- excessive gtk-doc cross reference warnings in the next step).
+## 1. Ensure that there are no local, uncommitted/unpushed mods
-2) Verify that the code passes "make distcheck"
+You're probably in a good state if both "git diff HEAD" and "git log
+master..origin/master" give no output.
- First, make sure you have 'nm' and 'readelf' commands in PATH.
- this should be OK with any Linux distro.
+## 2. Verify that the code passes `meson dist`
- Running "make distcheck" should result in no warnings or
- errors and end with a message of the form:
+First, make sure you have 'nm' and 'readelf' commands in `PATH`. this
+should be OK with any Linux distro.
- =============================================
- cairo-X.Y.Z archives ready for distribution:
- cairo-X.Y.Z.tar.gz
- =============================================
+Running "meson dist" should result in no warnings or errors and end with a
+message of the form:
- (But the tar file isn't actually ready yet, as we still have
- some more steps to follow).
+ Created source/cairo/_build/meson-dist/cairo-1.17.8.tar.xz
- Note that it's allowed (and perhaps recommended) to run the
- "make distcheck" step against an all-software X server such as
- Xvfb to avoid getting tripped up by any X-server-driver-specific
- bugs. See test/README for details
+If the test suite does not pass, you can use:
- If you get errors about local PLT entries, you get the list of
- cairo entries with the error. For each of these, a call to
- slim_hidden_def and slim_hidden_proto is needed in the cairo
- implementation in the style of other similar calls.
+ meson dist --no-tests
- In the unfortunate case that you have to push a snapshot out
- (note, I said snapshot, not release) without the entire test
- suite passing, here's the magic env vars to set when doing
- 'make distcheck' and 'make release-publish' that will let you
- get away with it. At any cost, never ever release without
- (implied) distchecking. Every time we got around it, it turned
- out to be a disaster. Anyway, here's the pass code:
+But this should only be allowed for development snapshots. Please, always
+check the state of the CI pipeline on GitLab.
- DISPLAY= CAIRO_TEST_TARGET=" "
+## 3. Decide what the new version number for the release will be.
-3) Decide what the new version number for the release will be.
+Cairo uses even numbers for official releases, and odd numbers for
+development snapshots. Thus, for a Minor release it would be:
- Cairo uses even numbers for official releases, and odd numbers
- for development snapshots. Thus, for a Minor release it would
- be:
+ LAST_RELEASE="X.Y.Z" # e.g. 1.12.0
+ THIS_RELEASE="X.Y+2.0" # e.g. 1.14.0
- LAST_RELEASE="X.Y.Z" # e.g. 1.12.0
- THIS_RELEASE="X.Y+2.0" # e.g. 1.14.0
+While for a Micro release the version numbers should be:
- While for a Micro release the version numbers should be:
+ LAST_RELEASE="X.Y.Z" # e.g. 1.14.0
+ THIS_RELEASE="X.Y.Z+2" # e.g. 1.14.2
- LAST_RELEASE="X.Y.Z" # e.g. 1.14.0
- THIS_RELEASE="X.Y.Z+2" # e.g. 1.14.2
+Snapshots are similar but have odd minor versions. Also, the first snapshot
+release in a new series will be .2 rather than .0, e.g.:
- Snapshots are similar but have odd minor versions. Also, the
- first snapshot release in a new series will be .2 rather than
- .0, e.g.:
+ LAST_RELEASE="X.Y.Z" # e.g. 1.14.0
+ THIS_RELEASE="X.Y+1.0" # e.g. 1.15.2
- LAST_RELEASE="X.Y.Z" # e.g. 1.14.0
- THIS_RELEASE="X.Y+1.0" # e.g. 1.15.2
+and subsequent snapshots in that series are just normal micro releases:
- and subsequent snapshots in that series are just normal micro
- releases:
+ LAST_RELEASE="X.Y.Z" # e.g. 1.15.2
+ THIS_RELEASE="X.Y.Z+2" # e.g. 1.15.4
- LAST_RELEASE="X.Y.Z" # e.g. 1.15.2
- THIS_RELEASE="X.Y.Z+2" # e.g. 1.15.4
+## 4. Fill out an entry in the NEWS file
-4) Fill out an entry in the NEWS file
+Sift through the logs since the last release. This is most easily done with
+a command such as:
- Sift through the logs since the last release. This is most
- easily done with a command such as:
+ git log --stat ${LAST_RELEASE}..
- git log --stat ${LAST_RELEASE}..
+Summarize major changes briefly in a style similar to other entries in NEWS.
+Take special care to note any additions in the API. These should be easy to
+find by noting modifications to .h files in the log command above. And more
+specifically, the following command will show each patch that has changed a
+public header file since the given version:
- Summarize major changes briefly in a style similar to other
- entries in NEWS. Take special care to note any additions in
- the API. These should be easy to find by noting modifications
- to .h files in the log command above. And more specifically,
- the following command will show each patch that has changed a
- public header file since the given version:
+```
+find src/ -name '*.h' ! -name '*-private.h' \
+ ! -name 'cairoint.h' ! -name 'cairo-*features*.h' | \
+ xargs git diff ${LAST_RELEASE}.. --
+```
- find src/ -name '*.h' ! -name '*-private.h' \
- ! -name 'cairoint.h' ! -name 'cairo-*features*.h' | \
- xargs git diff ${LAST_RELEASE}.. --
- Include a link to the incremental ChangeLog for this release,
- which we'll be uploading in a later step:
+## 5. Increment `CAIRO_VERSION_{MINOR|MICRO}` in `src/cairo-version.h`:
- https://cairographics.org/releases/ChangeLog.cairo-${THIS_RELEASE}
+If there are backward-incompatible changes in the API, stop now and don't
+release. Go back and fix the API instead. Cairo is intended to remain
+backwards-compatible as far as API.
-4) Increment cairo_version_{minor|micro} in src/cairo-version.h:
+So `CAIRO_VERSION_MAJOR` will not be incremented unless we come up with a
+new versioning scheme to take advantage of it.
- If there are backward-incompatible changes in the API, stop
- now and don't release. Go back and fix the API instead. Cairo
- is intended to remain backwards-compatible as far as API.
+If there are API additions, then increment `CAIRO_VERSION_MINOR` and reset
+`CAIRO_VERSION_MICRO` to 0. **NOTE**: The minor version is only incremented
+for releases, not for snapshots.
- So cairo_version_major will not be incremented unless we come
- up with a new versioning scheme to take advantage of it.
+Otherwise, (i.e. there are only bug fixes), increment `CAIRO_VERSION_MICRO`
+to the next larger (even) number.
- If there are API additions, then increment cairo_version_minor
- and reset cairo_version_micro to 0. NOTE: The minor version is
- only incremented for releases, not for snapshots.
+## 6. For Minor releases, add an index entry to `doc/public/cairo-docs.xml`
- Otherwise, (i.e. there are only bug fixes), increment
- cairo_version_micro to the next larger (even) number.
+Towards the end of the file, add a new section for the stable release.
+It'll look something like:
-5) For Minor releases, add an index entry to doc/public/cairo-docs.xml
+```xml
+<index id="api-index-X-Y">
+ <title>Index of new symbols in X.Y</title>
+ <xi:include href="xml/api-index-X.Y.xml"/>
+</index>
+```
- Towards the end of the file, add a new section for the stable
- release. It'll look something like:
+## 7. Commit the changes to `NEWS` and `src/cairo-version.h`
- <index id="index-X.Y" role="X.Y">
- <title>Index of new symbols in X.Y</title>
- </index>
+It's especially important to mention the new version number in your commit
+log.
-6) Commit the changes to NEWS and src/cairo-version.h
+## 8. Generate the release archive
- It's especially important to mention the new version number in your
- commit log.
+The `meson dist` command will:
-7) Run "make release-publish" which will perform the following steps
- for you:
+ * Generate the final tar file
+ * Generate an sha1sum file
- * Generate ChangeLog files out of git repository
- * Check that ChangeLog files were generated properly
- * Check that the version number ends with an even micro component
- * Check that no release exists with the current version
- * Verify that make distcheck completes successfully
- * Generate the final tar file
- * Generate an sha1sum file
- * Sign the sha1sum using your GPG setup (asks for your GPG password)
- * scp the three files to appear on https://cairographics.org/releases
- * Generate a versioned manual and upload it to appear as both:
- https://cairographics.org/manual-${THIS_RELEASE}
- https://cairographics.org/manual
- * Place local copies of the three files in the releases directory
- * Create a LATEST-package-version file (after deleting any old one)
- * Tag the entire source tree with a ${THIS_RELEASE} tag, and sign
- the tag with your GPG key (asks for your GPG password, and you
- may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
- your public-key's setting or this fails.)
- * Provide some text for the release announcement (see below).
- If for some reason you lost this message, "make release-publish-message"
- prints it for you.
+Once you have the release archive you will need to:
- Upload the incremental ChangeLog generated by the above. For
- minor stable releases, this is:
+ * Sign the sha1sum using your GPG setup (asks for your GPG password)
+ * `scp` the three files to appear on https://cairographics.org/releases
+ * Generate a versioned manual and upload it to appear as both:
+ - `https://cairographics.org/manual-${THIS_RELEASE}`
+ - `https://cairographics.org/manual`
+ * Place local copies of the three files in the releases directory
+ * Create a `LATEST-{package_version}` file (after deleting any old one)
+ * Tag the entire source tree with a `${THIS_RELEASE}` tag, and sign the
+ tag with your GPG key (asks for your GPG password, and you may need to
+ set `GIT_COMMITTER_NAME` and `GIT_COMMITTER_EMAIL` to match your
+ public-key's setting or this fails.)
+ * Provide some text for the release announcement (see below).
- scp ChangeLog \
- cairographics.org:/srv/cairo.freedesktop.org/www/releases/ChangeLog.cairo-${THIS_RELEASE}
+## 9. Update master (or the stable branch) version number.
- for micro and snapshot releases, the command is:
+For Micro releases (X.Y.Z+2), increment `CAIRO_VERSION_MICRO` to the next
+larger (odd) number in `src/cairo-version.h`.
- scp ChangeLog.cache-${LAST_RELEASE}.. \
- cairographics.org:/srv/cairo.freedesktop.org/www/releases/ChangeLog.cairo-${THIS_RELEASE}
+ DEVEL_VERSION="X.Y.Z+1" # e.g. 1.15.10 -> 1.15.11
- To undo a release-publish, before you've sent any emails or
- pushed changes to master, delete the locally created tag (git
- tag -d ${THIS_RELEASE}); then log into the webserver, repoint
- the manual and LATEST-cairo-${THIS_RELEASE} symlinks to the
- previous versions, remove manual-${THIS_RELEASE} and
- release/cairo-${THIS_RELEASE}.
+For Minor releases (X.Y.0), increment `CAIRO_VERSION_MINOR` to the next
+larger (odd) number, and set `CAIRO_VERSION_MICRO` to 1.
-8) Push the new tag out to the central tree with a command like:
+ DEVEL_VERSION="X.Y.Z+1" # e.g. 1.16.0 -> 1.17.1
- git push origin master ${THIS_RELEASE}
+Then, commit:
-9) Update master (or the stable branch) version number.
+ git commit src/cairo-version.h -m "Bump version for ${DEVEL_VERSION}"
- For Micro releases (X.Y.Z+2), increment cairo_version_micro to
- the next larger (odd) number in src/cairo-version.h, commit, and
- push.
+## 9. Push the new tag out
- DEVEL_VERSION="X.Y.Z+1" # e.g. 1.15.10 -> 1.15.11
+Use:
- For Minor releases (X.Y.0), increment cairo_version_minor to the
- next larger (odd) number, and set cairo_version_micro to 1. Then
- commit and push.
+ git push --atomic origin master ${THIS_RELEASE}
- DEVEL_VERSION="X.Y.Z+1" # e.g. 1.16.0 -> 1.17.1
+to ensure that both the tag and the latest changes in your tree are uploaded
+at the same time.
- git commit src/cairo-version.h -m "Bump version for ${DEVEL_VERSION}"
+## 10. Send out an announcement message.
-10) Send out an announcement message.
+Send a message to cairo-announce at cairographics.org and CC
+cairo at cairographics.org, and ftp-release at lists.freedesktop.org (pr at lwn.net
+as well for major releases) to announce the release, adding the excerpt from
+NEWS and the shortlog of all changes since last release, generated by:
- Send a message to cairo-announce at cairographics.org and CC
- cairo at cairographics.org, gnome-announce-list at gnome.org and
- ftp-release at lists.freedesktop.org (pr at lwn.net as well for major
- releases) to announce the new release using the text provided from
- "make release-publish", adding the excerpt from NEWS and
- the shortlog of all changes since last release, generated by:
+ git shortlog ${LAST_RELEASE}...
- git shortlog ${LAST_RELEASE}...
+## 11. Add the announcement to the website
-11) Add the announcement to the website as a new entry in the news/
- dir. It will automatically get indexed onto the homepage when the
- site refreshes.
+Add a new entry in the `news` directory. It will automatically get indexed
+onto the homepage when the site refreshes.
commit d54e908c98672e20e4970d8e807b8138f7d50b20
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 14:56:29 2023 +0000
Move documentation files to the doc directory
diff --git a/BIBLIOGRAPHY b/doc/bibliography.md
similarity index 100%
rename from BIBLIOGRAPHY
rename to doc/bibliography.md
diff --git a/RELEASING b/doc/releasing.md
similarity index 100%
rename from RELEASING
rename to doc/releasing.md
commit e29ede58d3161f46b0cde57c36709c7bc18502a0
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 14:32:55 2023 +0000
perf: Disable deprecation warnings for the perf widget
We're using an EOL version of GTK; we know we are using deprecated API.
Until somebody shows up with a replacement, or until we drop the perf
widget, we should avoid unnecessary compiler warnings.
diff --git a/perf/cairo-perf-graph-files.c b/perf/cairo-perf-graph-files.c
index ef98da973..9a2a325e6 100644
--- a/perf/cairo-perf-graph-files.c
+++ b/perf/cairo-perf-graph-files.c
@@ -25,6 +25,8 @@
* Authors: Chris Wilson <chris at chris-wilson.co.uk>
*/
+#define GLIB_DISABLE_DEPRECATION_WARNINGS
+
#include "cairo-perf.h"
#include "cairo-perf-graph.h"
diff --git a/perf/cairo-perf-graph-widget.c b/perf/cairo-perf-graph-widget.c
index e56eee1bc..9da0abbfe 100644
--- a/perf/cairo-perf-graph-widget.c
+++ b/perf/cairo-perf-graph-widget.c
@@ -25,6 +25,8 @@
* Authors: Chris Wilson <chris at chris-wilson.co.uk>
*/
+#define GLIB_DISABLE_DEPRECATION_WARNINGS
+
#include "cairo-perf.h"
#include "cairo-perf-graph.h"
commit 2be68fb4e001608c3c0d19d9f98b831f109bbc5a
Author: Emmanuele Bassi <ebassi at gnome.org>
Date: Mon Jan 30 14:31:04 2023 +0000
build: Turn version.py into idiomatic Python
While it's possible to write C code in Python, it's better to actually
write Python code in Python.
Use regular expressions, instead of counting characters, to allow a
little bit more leeway when editing the cairo-version.h header file.
Use a context manager to handle the lifetime of a file object.
Use f-strings instead of the obsolete format() method.
diff --git a/version.py b/version.py
index 7e0ded0d7..aabc20593 100755
--- a/version.py
+++ b/version.py
@@ -5,27 +5,49 @@
# Extracts the version from cairo-version.h for the meson build files.
#
import os
+import re
import sys
-if __name__ == '__main__':
- srcroot = os.path.dirname(__file__)
- version_major = None
- version_minor = None
- version_micro = None
+MAJOR_RE = re.compile(
+ r'^\s*#\s*define\s+CAIRO_VERSION_MAJOR\s+(?P<number>[0-9]+)\s*$',
+ re.UNICODE)
- f = open(os.path.join(srcroot, 'src', 'cairo-version.h'), 'r', encoding='utf-8')
+MINOR_RE = re.compile(
+ r'^\s*#\s*define\s+CAIRO_VERSION_MINOR\s+(?P<number>[0-9]+)\s*$',
+ re.UNICODE)
+
+MICRO_RE = re.compile(
+ r'^\s*#\s*define\s+CAIRO_VERSION_MICRO\s+(?P<number>[0-9]+)\s*$',
+ re.UNICODE)
+
+version_major = None
+version_minor = None
+version_micro = None
+
+srcroot = os.path.dirname(__file__)
+version_h = os.path.join(srcroot, "src", "cairo-version.h")
+
+with open(version_h, "r", encoding="utf-8") as f:
for line in f:
- if line.startswith('#define CAIRO_VERSION_MAJOR '):
- version_major = line[28:].strip()
- if line.startswith('#define CAIRO_VERSION_MINOR '):
- version_minor = line[28:].strip()
- if line.startswith('#define CAIRO_VERSION_MICRO '):
- version_micro = line[28:].strip()
- f.close()
-
- if not (version_major and version_minor and version_micro):
- print('ERROR: Could not extract cairo version from cairo-version.h in', srcroot, file=sys.stderr)
- sys.exit(-1)
-
- print('{0}.{1}.{2}'.format(version_major, version_minor, version_micro))
+ res = MAJOR_RE.match(line)
+ if res:
+ assert version_major is None
+ version_major = res.group('number')
+ continue
+ res = MINOR_RE.match(line)
+ if res:
+ assert version_minor is None
+ version_minor = res.group('number')
+ continue
+ res = MICRO_RE.match(line)
+ if res:
+ assert version_micro is None
+ version_micro = res.group('number')
+ continue
+
+if not (version_major and version_minor and version_micro):
+ print(f"ERROR: Could not extract version from cairo-version.h in {srcroot}", file=sys.stderr) # noqa
+ sys.exit(-1)
+
+print(f"{version_major}.{version_minor}.{version_micro}")
More information about the cairo-commit
mailing list