From stuaxo2 at yahoo.com Thu May 6 16:23:30 2021 From: stuaxo2 at yahoo.com (Stuart Axon) Date: Thu, 6 May 2021 16:23:30 +0000 (UTC) Subject: [cairo] Output SVG with fill and alpha stroke, but without inline images ? In-Reply-To: <546075598.257544.1616694904526@mail.yahoo.com> References: <1898324485.3459862.1616548945379.ref@mail.yahoo.com> <1898324485.3459862.1616548945379@mail.yahoo.com> <546075598.257544.1616694904526@mail.yahoo.com> Message-ID: <1777151976.1146385.1620318210857@mail.yahoo.com> The fantastic, @cassiecodes on twitter has found a solution to this using paint order stroke, it seems like a longer term solution is inset or offset strokes. https://twitter.com/cassiecodes/status/1390338810911862790SVG transparent stroke. | | | | | | | | | | | SVG transparent stroke. ... | | | Now there's a solution I'll open bug for this. S++ On Thursday, March 25, 2021, 5:55:04 PM GMT, Stuart Axon wrote: Thanks for looking at this. Specifying the version, I can see the same result.? It seems likely there is a way to achieve the expected output, but I think I need to understand SVG a bit more first.?? I failed on my first pass understanding the filter dialog in Inkscape but will try again from that end, or just editing the raw SVG. S++ On Thursday, March 25, 2021, 4:06:43 PM GMT, Uli Schlachter wrote: Hi, Am 24.03.21 um 02:22 schrieb Stuart Axon: > I've been trying to generate an SVG using SVGSurface with a fill and an alpha stroke, > with OPERATOR_SOURCE to ensure the stroke draws over the fill, but this seemsto generate tags in the SVG. > Toy example and output + XML: > https://gist.github.com/stuaxo/b525a47d33f5f3074b1be7c693f6b6e6 > Is there any way to render fill + stroke (with alpha) and only output vector data ?This seems like a common operation, but whatever I try outputs SVGs full of s. > > For Shoebot, this has meant our SVGs become very very large, enough to eat all your ram if you try and open them in Inkscape. I ported your example code to C (attached). Don't ask me why, but I experimented with the SVG version. And it helped! More specifically, adding this line: ? cairo_svg_surface_restrict_to_version(s, CAIRO_SVG_VERSION_1_2); ...causes a small difference in the output with/without operator SOURCE: The path's style gets a new "comp-op:src;clip-to-self:true" entry. Everything else stays the same (well, except the header saying version="1.2" instead of the previous version="1.1"). So, I do not really have much clue about SVG, but I guess this means that: - cairo defaults to SVG 1.1 - SVG 1.1 does not support operator SOURCE Cheers, Uli -- Homophobia - The fear that another man will treat you the way you treat women. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuaxo2 at yahoo.com Thu May 6 16:47:32 2021 From: stuaxo2 at yahoo.com (Stuart Axon) Date: Thu, 6 May 2021 16:47:32 +0000 (UTC) Subject: [cairo] Output SVG with fill and alpha stroke, but without inline images ? In-Reply-To: <1777151976.1146385.1620318210857@mail.yahoo.com> References: <1898324485.3459862.1616548945379.ref@mail.yahoo.com> <1898324485.3459862.1616548945379@mail.yahoo.com> <546075598.257544.1616694904526@mail.yahoo.com> <1777151976.1146385.1620318210857@mail.yahoo.com> Message-ID: <88761043.1022096.1620319652878@mail.yahoo.com> Gah, immediately hit an edge-case will open a ticket anyway. S++ On Thursday, May 6, 2021, 5:23:30 PM GMT+1, Stuart Axon wrote: The fantastic, @cassiecodes on twitter has found a solution to this using paint order stroke, it seems like a longer term solution is inset or offset strokes. https://twitter.com/cassiecodes/status/1390338810911862790SVG transparent stroke. | | | | | | | | | | | SVG transparent stroke. ... | | | Now there's a solution I'll open bug for this. S++ On Thursday, March 25, 2021, 5:55:04 PM GMT, Stuart Axon wrote: Thanks for looking at this. Specifying the version, I can see the same result.? It seems likely there is a way to achieve the expected output, but I think I need to understand SVG a bit more first.?? I failed on my first pass understanding the filter dialog in Inkscape but will try again from that end, or just editing the raw SVG. S++ On Thursday, March 25, 2021, 4:06:43 PM GMT, Uli Schlachter wrote: Hi, Am 24.03.21 um 02:22 schrieb Stuart Axon: > I've been trying to generate an SVG using SVGSurface with a fill and an alpha stroke, > with OPERATOR_SOURCE to ensure the stroke draws over the fill, but this seemsto generate tags in the SVG. > Toy example and output + XML: > https://gist.github.com/stuaxo/b525a47d33f5f3074b1be7c693f6b6e6 > Is there any way to render fill + stroke (with alpha) and only output vector data ?This seems like a common operation, but whatever I try outputs SVGs full of s. > > For Shoebot, this has meant our SVGs become very very large, enough to eat all your ram if you try and open them in Inkscape. I ported your example code to C (attached). Don't ask me why, but I experimented with the SVG version. And it helped! More specifically, adding this line: ? cairo_svg_surface_restrict_to_version(s, CAIRO_SVG_VERSION_1_2); ...causes a small difference in the output with/without operator SOURCE: The path's style gets a new "comp-op:src;clip-to-self:true" entry. Everything else stays the same (well, except the header saying version="1.2" instead of the previous version="1.1"). So, I do not really have much clue about SVG, but I guess this means that: - cairo defaults to SVG 1.1 - SVG 1.1 does not support operator SOURCE Cheers, Uli -- Homophobia - The fear that another man will treat you the way you treat women. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuaxo2 at yahoo.com Thu May 6 17:00:45 2021 From: stuaxo2 at yahoo.com (Stuart Axon) Date: Thu, 6 May 2021 17:00:45 +0000 (UTC) Subject: [cairo] Output SVG with fill and alpha stroke, but without inline images ? In-Reply-To: <1777151976.1146385.1620318210857@mail.yahoo.com> References: <1898324485.3459862.1616548945379.ref@mail.yahoo.com> <1898324485.3459862.1616548945379@mail.yahoo.com> <546075598.257544.1616694904526@mail.yahoo.com> <1777151976.1146385.1620318210857@mail.yahoo.com> Message-ID: <1077656824.1665208.1620320445028@mail.yahoo.com> https://gitlab.freedesktop.org/cairo/cairo/-/issues/478 S++ On Thursday, May 6, 2021, 5:23:30 PM GMT+1, Stuart Axon wrote: The fantastic, @cassiecodes on twitter has found a solution to this using paint order stroke, it seems like a longer term solution is inset or offset strokes. https://twitter.com/cassiecodes/status/1390338810911862790SVG transparent stroke. | | | | | | | | | | | SVG transparent stroke. ... | | | Now there's a solution I'll open bug for this. S++ On Thursday, March 25, 2021, 5:55:04 PM GMT, Stuart Axon wrote: Thanks for looking at this. Specifying the version, I can see the same result.? It seems likely there is a way to achieve the expected output, but I think I need to understand SVG a bit more first.?? I failed on my first pass understanding the filter dialog in Inkscape but will try again from that end, or just editing the raw SVG. S++ On Thursday, March 25, 2021, 4:06:43 PM GMT, Uli Schlachter wrote: Hi, Am 24.03.21 um 02:22 schrieb Stuart Axon: > I've been trying to generate an SVG using SVGSurface with a fill and an alpha stroke, > with OPERATOR_SOURCE to ensure the stroke draws over the fill, but this seemsto generate tags in the SVG. > Toy example and output + XML: > https://gist.github.com/stuaxo/b525a47d33f5f3074b1be7c693f6b6e6 > Is there any way to render fill + stroke (with alpha) and only output vector data ?This seems like a common operation, but whatever I try outputs SVGs full of s. > > For Shoebot, this has meant our SVGs become very very large, enough to eat all your ram if you try and open them in Inkscape. I ported your example code to C (attached). Don't ask me why, but I experimented with the SVG version. And it helped! More specifically, adding this line: ? cairo_svg_surface_restrict_to_version(s, CAIRO_SVG_VERSION_1_2); ...causes a small difference in the output with/without operator SOURCE: The path's style gets a new "comp-op:src;clip-to-self:true" entry. Everything else stays the same (well, except the header saying version="1.2" instead of the previous version="1.1"). So, I do not really have much clue about SVG, but I guess this means that: - cairo defaults to SVG 1.1 - SVG 1.1 does not support operator SOURCE Cheers, Uli -- Homophobia - The fear that another man will treat you the way you treat women. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cworth at cworth.org Thu May 6 18:46:48 2021 From: cworth at cworth.org (Carl Worth) Date: Thu, 06 May 2021 11:46:48 -0700 Subject: [cairo] Output SVG with fill and alpha stroke, but without inline images ? In-Reply-To: <1777151976.1146385.1620318210857@mail.yahoo.com> References: <1898324485.3459862.1616548945379.ref@mail.yahoo.com> <1898324485.3459862.1616548945379@mail.yahoo.com> <546075598.257544.1616694904526@mail.yahoo.com> <1777151976.1146385.1620318210857@mail.yahoo.com> Message-ID: <87y2crk8dj.fsf@wobbit.home.cworth.org> On Thu, May 06 2021, Stuart Axon wrote: > The fantastic, @cassiecodes on twitter has found a solution to this using paint order stroke, it seems like a longer term solution is inset or offset strokes. > > https://twitter.com/cassiecodes/status/1390338810911862790SVG transparent stroke. You should be able to do what you are trying to in SVG by using a group (that is, a element). The group could be translucent and contain a path that is both stroked and filled without any translucence, (so you don't end up with the result you're currently seeing). And you should be able to achieve a similar result in cairo with code like: cairo_push_group (cr); /* Draw your stroke and filled shape here. */ cairo_pop_group_to_source (cr); cairo_set_operator (cr, CAIRO_OPERATOR_OVER); cairo_paint_with_alpha (cr, 0.5); I'm not sure whether the above cairo operations map to clean in SVG, but if not, then maybe that's the cairo bug you're looking to file? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mhao1999 at live.cn Sat May 8 08:32:04 2021 From: mhao1999 at live.cn (mhao1999 at live.cn) Date: Sat, 8 May 2021 08:32:04 +0000 Subject: [cairo] pango+cairo how to get position of each character? Message-ID: For example, I have a text string "hello" and a truetype font file, and I want to apply different color to different character, currently I cannot find a way to implement it. My thought is: first get each position of each character from pango/cairo, then if no api to render one by one, I can use freetype library to render each glyph, does it work? Thanks for any idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From theo.veenker at beexy.nl Sat May 8 13:59:57 2021 From: theo.veenker at beexy.nl (Theo Veenker) Date: Sat, 8 May 2021 15:59:57 +0200 Subject: [cairo] pango+cairo how to get position of each character? In-Reply-To: References: Message-ID: On 08/05/2021 10:32, mhao1999 at live.cn wrote: > For example, I have a text string "hello" and a truetype font file, and > I want to apply different color to different character, currently I > cannot find a way to implement it. > > My thought is: > first get each position of each character from pango/cairo, then if no > api to render one by one, I can use freetype library to render each > glyph, does it work? > > Thanks for any idea. > I think you need to create a pango layout for the text. Then use a pango iterator to iterate over the lines and each line's content. This should give you the position and size of each glyph. Then you can render each character separately in the desired color at the calculated position. Maybe it can be done smarter than that. If your goal is just to display fancy colored text rather than use a specific color for each character, I would simply create a rainbow gradient or whatever and use that as the paint source for your text. That's much easier and may also look better. HTH. Theo -- Theo Veenker | Beexy - Behavioral Experiment Software +31(0)524-541531 | +31(0)6-42525777 mobile theo.veenker at beexy.nl | www.beexy.nl From naveen at syrusdark.website Sat May 8 16:39:08 2021 From: naveen at syrusdark.website (Naveen M K) Date: Sat, 8 May 2021 22:09:08 +0530 Subject: [cairo] pango+cairo how to get position of each character? In-Reply-To: References: Message-ID: <47fdb155-b228-03d8-61cd-f46654e8f4a9@syrusdark.website> Hi, > For example, I have a text string "hello" and a truetype font file, and I want to apply different color to different character, currently I cannot find a way to implement it. You can simple use `PangoAttribute`[0] for coloring each character differently or use you can also use PangoMarkup[1] for achieving that. For loading a font from truetype font file, I don't know whether Pango would be able to do that. I think it usually requires you to install the font before hand and reference by the name. > then if no api to render one by one There is an API for rendering a Layout character by character, `pango_cairo_show_layout_line`[2] where you can iterate a PangoLayout using `pango_layout_get_line`[3] to achieve that. > I can use freetype library to render each glyph No idea how it will work. [0]: https://developer.gnome.org/pango/1.46/pango-Text-Attributes.html [1]: https://developer.gnome.org/pango/1.46/pango-Markup.html [2]: https://developer.gnome.org/pango/1.46/pango-Cairo-Rendering.html#pango-cairo-show-layout-line [3]: https://developer.gnome.org/pango/1.46/pango-Layout-Objects.html#pango-layout-get-lines -- Naveen From theo.veenker at beexy.nl Mon May 10 14:59:57 2021 From: theo.veenker at beexy.nl (Theo Veenker) Date: Mon, 10 May 2021 16:59:57 +0200 Subject: [cairo] pango+cairo how to get position of each character? In-Reply-To: References: Message-ID: <00ad7d21-d34f-9ceb-c949-3f5e153563e0@beexy.nl> On 5/10/21 4:10 PM, ? ? wrote: > Hi Theo, thank you, that's great. what I want is first: get each glyph; then get contour > and outline points of each glyph; then use cairo bezier related funtions to draw those > glyphs. because I want to do some transform based on those outline and points information. So you want to convert each character in a text to path and then operate on that. I'm afraid that's far beyond my expertise. I think I would study Inkscape (the source code) and learn from that. > > Now my question is if I can use some built-in cairo/pango function to get and render those > outline and points without freetype library? I am not familiar with how cairo draws each > glyph in detail (bitmap or bezier/line?) I don't know font rendering in depth, sorry. If you can do the text to path stuff you can of course draw or fill the path as you please. But seems a bit of an overkill if all you want is to color the individual characters. > > > ------------------------------------------------------------------------------------------ > *From:* cairo on behalf of Theo Veenker > > *Sent:* Saturday, May 8, 2021 9:59 PM > *To:* cairo at cairographics.org > *Subject:* Re: [cairo] pango+cairo how to get position of each character? > On 08/05/2021 10:32, mhao1999 at live.cn wrote: >> For example, I have a text string "hello" and a truetype font file, and >> I want to apply different color to different character, currently I >> cannot find a way to implement it. >> >> My thought is: >> first get each position of each character from pango/cairo, then if no >> api to render one by one, I can use freetype library to render each >> glyph, does it work? >> >> Thanks for any idea. >> > > I think you need to create a pango layout for the text. Then use a pango > iterator to iterate over the lines and each line's content. This should > give you the position and size of each glyph. Then you can render each > character separately in the desired color at the calculated position. > Maybe it can be done smarter than that. > > If your goal is just to display fancy colored text rather than use a > specific color for each character, I would simply create a rainbow > gradient or whatever and use that as the paint source for your text. > That's much easier and may also look better. > > HTH. > > Theo > > > -- > Theo Veenker? |? Beexy - Behavioral Experiment Software > +31(0)524-541531? |? +31(0)6-42525777 mobile > theo.veenker at beexy.nl? | www.beexy.nl > -- > cairo mailing list > cairo at cairographics.org > https://lists.cairographics.org/mailman/listinfo/cairo > -- Theo Veenker | Beexy - Behavioral Experiment Software +31(0)524-541531 | +31(0)6-42525777 mobile theo.veenker at beexy.nl | www.beexy.nl From ebassi at gmail.com Tue May 11 15:51:31 2021 From: ebassi at gmail.com (Emmanuele Bassi) Date: Tue, 11 May 2021 16:51:31 +0100 Subject: [cairo] Last call for a 1.17.6 snapshot Message-ID: Hi all; it's time for the next Cairo snapshot. I'm thinking of spinning a 1.17.6 release by the end of this week, so if you have any pending merge requests please ensure that they are either merged or review-ready and you have a reviewer. I created the 1.17.6 milestone: https://gitlab.freedesktop.org/cairo/cairo/-/milestones/3 If you have developer access, please add the issues/MRs you care about to that milestone; otherwise, ping me (@ebassi) on GitLab, and I'll do it for you. My plan is to cut 1.17.6 as is, to get the ball rolling; also, to shake down the release process. For 1.17.8, the plan is: - clean up the repository - remove old documentation files - move documentation to Markdown - consolidate boilerplate/build gunk - Meson parity with Autotools on Linux, Windows, and macOS - drop the Autotools build - drop the known broken/unmaintained/abandoned upstream backends: - drm - qt - beos - OS/2 - cogl - directfb - OpenVG - put the GL backend "on notice" - if somebody shows up and is willing to review and fix the issues, we can keep it; otherwise, it goes The deadline for the 1.17.8 release is in late-June/early-July. I've created a 1.17.8 milestone for it: https://gitlab.freedesktop.org/cairo/cairo/-/milestones/4 Depending on the result for the GL backend, and a couple of additional things I'm working on to simplify the build, we might do an intermediate 1.17.10. I want to spin 1.18.0 by late August, in order to be picked up by Fedora 35 and Ubuntu 21.10. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel.tao.gnome at gmail.com Sun May 16 01:06:30 2021 From: nigel.tao.gnome at gmail.com (Nigel Tao) Date: Sun, 16 May 2021 11:06:30 +1000 Subject: [cairo] cairo_add_color_stop_rgba_premultiplied or equivalent Message-ID: Summary: Was cairo_add_color_stop_rgba_premultiplied (or equivalent) ever implemented? How else can I make Cairo gradients interpolate in premultiplied alpha space? In 2006 (https://lists.freedesktop.org/archives/cairo/2006-June/007203.html), Carl Worth proposed adding cairo_set_source_rgba_premultiplied and cairo_add_color_stop_rgba_premultiplied. cairo_set_source_rgba_premultiplied is easy to fake on the caller-side (albeit unable to distinguish e.g. transparent red from transparent green). I can un-premultiply the red, green and blue arguments and pass to cairo_set_source_rgba, watching out for division by zero alpha. cairo_add_color_stop_rgba_premultiplied is trickier. I can un-premultiply each stop's RGBA values in the same way. But I would also like the interpolation to happen in premultiplied space. Suppose that two adjacent stops' RGBA values are opaque red = RGBA(1, 0, 0, 1) and transparent black = RGBA (0, 0, 0, 0). Note that the stop color semantics are equivalent in both premul and non-premul space. The halfway point, mathematically, is RGBA(0.5, 0, 0, 0.5). This is 50% opaque, but the question is whether the red has 50% or 100% Value (in the HSV sense). Using the existing cairo_pattern_add_color_stop_rgba produces 50% Value. I have a vector graphics file format that works entirely with premultiplied colors (unlike SVG). I'd like to rasterize it with Cairo, so I'd like to make Cairo gradients interpolate in premultiplied alpha space, yielding 100% Value instead in the example above. The cairo_add_color_stop_rgba_premultiplied idea sounds very close to what I want, but it doesn't look like it was ever implemented. That 2006 post to the cairo@ list, linked above, is also literally the only search hit for [cairo_add_color_stop_rgba_premultiplied]. I guess nobody replied specificaly to the proposal. I suppose that, on the caller-of-Cairo side, I could approximate two adjacent stops in the file format by N explicit stops in Cairo, doing the blend-in-premul-space myself, somewhat analogous to approximating a smooth B?zier segment by N line segments. I skimmed the thread (split into three on the lists.freedesktop.org archives for some reason) that it was posted to: https://lists.freedesktop.org/archives/cairo/2006-June/007201.html https://lists.freedesktop.org/archives/cairo/2006-June/007206.html https://lists.freedesktop.org/archives/cairo/2006-June/007216.html but didn't find an alternative. Any other suggestions for how I can do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at creativepost.co.uk Wed May 19 12:53:52 2021 From: john at creativepost.co.uk (John Emmas) Date: Wed, 19 May 2021 13:53:52 +0100 Subject: [cairo] config.h ? Message-ID: <60A50A60.3030700@creativepost.co.uk> The last time I built Cairo (from git master) was about 5 or 6 weeks ago. Back then, quite a few of the source files contained a section like this:- #if HAVE_CONFIG_H #include "config.h" #endif but in today's version, the #if an #endif lines have gone - just leaving #include "config.h" But where does config.h come from? Is it generated by meson somehow? I don't use meson in my builds so I need to find out how to generate (or obtain) config.h Thanks, John From ebassi at gmail.com Wed May 19 13:15:07 2021 From: ebassi at gmail.com (Emmanuele Bassi) Date: Wed, 19 May 2021 14:15:07 +0100 Subject: [cairo] config.h ? In-Reply-To: <60A50A60.3030700@creativepost.co.uk> References: <60A50A60.3030700@creativepost.co.uk> Message-ID: On Wed, 19 May 2021 at 14:06, John Emmas wrote: > The last time I built Cairo (from git master) was about 5 or 6 weeks > ago. Back then, quite a few of the source files contained a section like > this:- > > #if HAVE_CONFIG_H > #include "config.h" > #endif > > but in today's version, the #if an #endif lines have gone - just > leaving #include "config.h" > > But where does config.h come from? Is it generated by meson somehow? I > don't use meson in my builds so I need to find out how to generate (or > obtain) config.h > The `config.h` file is generated by the build system?either Autotools or Meson. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at creativepost.co.uk Wed May 19 14:46:07 2021 From: john at creativepost.co.uk (John Emmas) Date: Wed, 19 May 2021 15:46:07 +0100 Subject: [cairo] config.h ? In-Reply-To: References: <60A50A60.3030700@creativepost.co.uk> Message-ID: <60A524AF.80000@creativepost.co.uk> On 19/05/2021 14:15, Emmanuele Bassi wrote: > > The `config.h` file is generated by the build system?either Autotools > or Meson. > > Ciao, > Emmanuele. > Thanks Emmanuele, If I'm reading the makefiles correctly it looks like the top-level source folder should contain a file called 'config.h.in' but I'm not seeing that here (or does that file also get auto-generated?) Basically I need to know what command(s) I'd need to execute in order to end up with config.h John From ebassi at gmail.com Wed May 19 14:50:51 2021 From: ebassi at gmail.com (Emmanuele Bassi) Date: Wed, 19 May 2021 15:50:51 +0100 Subject: [cairo] config.h ? In-Reply-To: <60A524AF.80000@creativepost.co.uk> References: <60A50A60.3030700@creativepost.co.uk> <60A524AF.80000@creativepost.co.uk> Message-ID: On Wed, 19 May 2021 at 15:46, John Emmas wrote: > On 19/05/2021 14:15, Emmanuele Bassi wrote: > > > > The `config.h` file is generated by the build system?either Autotools > > or Meson. > > > > Ciao, > > Emmanuele. > > > Thanks Emmanuele, > > If I'm reading the makefiles correctly it looks like the top-level > source folder should contain a file called 'config.h.in' but I'm not > seeing that here (or does that file also get auto-generated?) > Yes, it's generated by the `configure` script in Autotools, just like Meson. Basically I need to know what command(s) I'd need to execute in order to > end up with config.h > If you are building Cairo with Autotools, then: ``` ./configure ``` will generate a `config.h` header file in the current directory. If you are building from Git, then I recommend using: ``` NOCONFIGURE=1 ./autogen.sh mkdir _build && cd _build ../configure ``` Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at creativepost.co.uk Wed May 19 15:24:33 2021 From: john at creativepost.co.uk (John Emmas) Date: Wed, 19 May 2021 16:24:33 +0100 Subject: [cairo] config.h ? In-Reply-To: References: <60A50A60.3030700@creativepost.co.uk> <60A524AF.80000@creativepost.co.uk> Message-ID: <60A52DB1.7020904@creativepost.co.uk> On 19/05/2021 15:50, Emmanuele Bassi wrote: > > Yes, it's generated by the `configure` script in Autotools, just like > Meson. > Ah... in my case I'm building with (my own) Visual C++ build projects. At one time, some libraries could generate VC project files either using Meson or CMake but I never really found them satisfactory. Could you maybe attach a copy of config.h so I can at least see what kinda stuff it needs to contain? Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebassi at gmail.com Wed May 19 16:20:31 2021 From: ebassi at gmail.com (Emmanuele Bassi) Date: Wed, 19 May 2021 17:20:31 +0100 Subject: [cairo] config.h ? In-Reply-To: <60A52DB1.7020904@creativepost.co.uk> References: <60A50A60.3030700@creativepost.co.uk> <60A524AF.80000@creativepost.co.uk> <60A52DB1.7020904@creativepost.co.uk> Message-ID: On Wed, 19 May 2021 at 16:24, John Emmas wrote: > On 19/05/2021 15:50, Emmanuele Bassi wrote: > > > Yes, it's generated by the `configure` script in Autotools, just like > Meson. > > > Ah... in my case I'm building with (my own) Visual C++ build projects. At > one time, some libraries could generate VC project files either using Meson > or CMake but I never really found them satisfactory. Could you maybe > attach a copy of config.h so I can at least see what kinda stuff it needs > to contain? Thanks, > The `config.h` file is just a list of `#define FOO` symbols that are discovered at configuration time depending on your platform, like: ``` /* Define to 1 if the PS backend can be tested (needs ghostscript) */ #define CAIRO_CAN_TEST_PS_SURFACE 1 /* Define to 1 if the SVG backend can be tested */ #define CAIRO_CAN_TEST_SVG_SURFACE 1 /* Define to 1 if the Win32 Printing backend can be tested (needs ghostscript) */ /* #undef CAIRO_CAN_TEST_WIN32_PRINTING_SURFACE */ /* Define to 1 if dlsym is available */ #define CAIRO_HAS_DLSYM 1 /* Define to 1 to enable cairo's cairo-script-interpreter feature */ #define CAIRO_HAS_INTERPRETER 1 /* Define to 1 to enable cairo's pthread feature */ #define CAIRO_HAS_PTHREAD 1 /* Define to 1 if we have full pthread support */ #define CAIRO_HAS_REAL_PTHREAD 1 ``` If you're using your own build system, unsanctioned by the Cairo project, then I'm afraid you're on your own. The reason why `HAVE_CONFIG_H` was removed was because all the build systems supported by Cairo?i.e. the in tree ones?generated a `config.h`, so there's literally no point in defining `HAVE_CONFIG_H` to guard the `config.h` inclusion. Incidentally, if you relied on that to build Cairo, you probably have been building a fairly broken version of it?unless, of course, you've also been injecting symbols like `CAIRO_HAS_DLSYM` or `HAVE_OS_ATOMIC_OPS` or `HAVE_UINT64_T` in your build environment. Personally, I'd ask you to use the build system provided by the project you're building, instead of going at it in your own way. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuaxo2 at yahoo.com Wed May 26 01:12:19 2021 From: stuaxo2 at yahoo.com (Stuart Axon) Date: Wed, 26 May 2021 01:12:19 +0000 (UTC) Subject: [cairo] Possible issue with long paths being slow References: <60091861.98487.1621991539671.ref@mail.yahoo.com> Message-ID: <60091861.98487.1621991539671@mail.yahoo.com> I came across this (closed) bug in a downstream project https://github.com/JuliaGraphics/Winston.jl/issues/89 Which seems to say that plotting paths in Cairo with a large number of line segments can be slow. Is this a known thing, it seems a little strange from the outside ?(especially as they are speeding it up by changing their code to add moveto, then draw a separate segment). S++ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml3p at onghu.com Fri May 28 15:54:26 2021 From: ml3p at onghu.com (Mohit Sindhwani) Date: Fri, 28 May 2021 23:54:26 +0800 Subject: [cairo] Cairo samples using RCairo on Windows - Ok to use? Message-ID: <1e71baf1-7040-5211-dec9-05769cef91a4@onghu.com> Hi Everyone, After a very long break from Cairo and especially RCairo, I started to explore it again this week. As I went through it, I first created a brief page to explain to people that RCairo on Windows works perfectly fine with a modern Ruby. This is online at: https://notepad.onghu.com/2021/ruby-cairo-installation-windows/ Next up, I am revisiting what I used to know, and I'm approaching that by converting all the samples on https://www.cairographics.org/samples/ from C to Ruby, noting the few small changes that I am making to get them to run. I intend to: 1) Put a blog post that shows the original C code, matching Ruby code and the output 2) Put up the Ruby samples into a GitHub repository for reference So, the question I have is: * Is there any copyright issue in doing #1? - can I re-publish the C code from the site along with the Ruby code on my page? Based on this line on the page: All of his original snippet code is considered to be part of the public domain I expect I am clear to do this, but just want a quick Yay or Nay :) Finally, once I have the page up, could it be linked to from the official Cairo page for whoever needs it? Best Regards, Mohit. 2021-5-28 | 11:38 pm. From pippin at gimp.org Fri May 28 16:53:12 2021 From: pippin at gimp.org (=?UTF-8?B?w5h5dmluZCBLb2zDpXM=?=) Date: Fri, 28 May 2021 18:53:12 +0200 Subject: [cairo] Cairo samples using RCairo on Windows - Ok to use? In-Reply-To: <1e71baf1-7040-5211-dec9-05769cef91a4@onghu.com> References: <1e71baf1-7040-5211-dec9-05769cef91a4@onghu.com> Message-ID: On Fri, May 28, 2021 at 6:31 PM Mohit Sindhwani wrote: > ... I am revisiting what I used to know, and I'm approaching that > by converting all the samples on https://www.cairographics.org/samples/ > from C to Ruby, noting the few small changes that I am making to get > them to run. > > I intend to: > 1) Put a blog post that shows the original C code, matching Ruby code > and the output > 2) Put up the Ruby samples into a GitHub repository for reference > > So, the question I have is: > * Is there any copyright issue in doing #1? > - can I re-publish the C code from the site along with the Ruby code on > my page? > Based on this line on the page: All of his original snippet code is > considered to be part of the public domain > I expect I am clear to do this, but just want a quick Yay or Nay :) Yay! I find code samples with restrictive licenses to be silly. I've seen my share of GPL, LGPL and commerical unlicensed source available tutorials; which is why the page explicitly states that the examples are to be public domain (perhaps this should be revised with CC0 - given that public domain does not exist in all of the world.) -- /?yvind Kol?s, https:/pippin.gimp.org/ https://ctx.graphics/ From ml3p at onghu.com Fri May 28 16:56:28 2021 From: ml3p at onghu.com (Mohit Sindhwani) Date: Sat, 29 May 2021 00:56:28 +0800 Subject: [cairo] Cairo samples using RCairo on Windows - Ok to use? In-Reply-To: References: <1e71baf1-7040-5211-dec9-05769cef91a4@onghu.com> Message-ID: <111cc51f-8300-39f3-a37f-0edfeed30ef4@onghu.com> Thanks ?yvind ! On 2021-5-29 12:53 am, ?yvind Kol?s wrote: > Yay! > I find code samples with restrictive licenses to be silly. I've seen > my share of GPL, > LGPL and commerical unlicensed source available tutorials; which is why the page > explicitly states that the examples are to be public domain (perhaps > this should be > revised with CC0 - given that public domain does not exist in all of the world.) Clearance from you kinda puts me in the clear :) Stay tuned for an updated link with a very long page! Best Regards, Mohit. 2021-5-29 | 12:56 am. From ml3p at onghu.com Sat May 29 18:10:51 2021 From: ml3p at onghu.com (Mohit Sindhwani) Date: Sun, 30 May 2021 02:10:51 +0800 Subject: [cairo] Cairo C Samples ported to RCairo/ Ruby Message-ID: <4c2c3d79-9192-c1d1-6ac8-773feee87073@onghu.com> Hi Everyone, Over the past couple of days, I ported the C samples from the Cairo website to Ruby using RCairo. These are on my blog at: https://notepad.onghu.com/2021/cairo-samples-in-ruby/ All the code is available at: https://github.com/mohits/rcairo_samples Separately, I have a question about the last sample: https://www.cairographics.org/samples/text_extents/ The image on the original site is clipped but when I ran the code, it seems that the sample does not do what it should. I made some small changes to the code. Both the original and modified pictures are at the last one on the blog page above. Inputs welcome. Thanks & Best Regards, Mohit. 2021-5-30 | 2:05 am. From psychon at znc.in Sun May 30 10:44:44 2021 From: psychon at znc.in (Uli Schlachter) Date: Sun, 30 May 2021 12:44:44 +0200 Subject: [cairo] Possible issue with long paths being slow In-Reply-To: <60091861.98487.1621991539671@mail.yahoo.com> References: <60091861.98487.1621991539671.ref@mail.yahoo.com> <60091861.98487.1621991539671@mail.yahoo.com> Message-ID: <23fa95e8-f408-43f2-c3b3-27526972a5b2@znc.in> Hi, Am 26.05.21 um 03:12 schrieb Stuart Axon: > I came across this (closed) bug in a downstream project > https://github.com/JuliaGraphics/Winston.jl/issues/89 > Which seems to say that plotting paths in Cairo with a large number of line segments can be slow. > Is this a known thing, it seems a little strange from the outside ? I cannot really say much, but... > (especially as they are speeding it up by changing their code to add moveto, then draw a separate segment). ...that might produce different visible results. The patch in the original comment causes different line joins and will also cause differences with a non-opaque sources. Think of a self-intersecting path: Before the patch, each intersection was only stroked once, but after the patch it will be stroked multiple times. Feel free to try to come up with a reproducer of the original problem. There might also be already something like this in cairo's perf/micro, I don't know. Cheers, Uli -- A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' -- Douglas Adams