October 2025 - Inkscape Board of Directors

Developer Meeting Notes: Oct 17th 2025
by Martin Owens 17 Oct '25

17 Oct '25

Hey Developers! Event: https://inkscape.org/cals/event/64/ Attending: Mikekov, Martin, Jabier, Willy, Tav Next Meeting: https://inkscape.org/cals/event/1/ We kick off with Willy who has two open open merge requests for the developer team to consider. One is the rotation snapping which is ready to be re-reviewed. It uses a regulr Spin Button instead of a Math Spin Button so it's got some regressions still. The second is a 1.4.x patch for the toolbars so the buttons dispear one by one instead of chunking entire groups at a time. We talked about the 1.4.3 issues and the open issues and when we can schedule the release. We suggest a December release with a project wide request to focus on fixing some of the remaining issues for 1.4.3 so make it a really stable release before 1.5 comes out. We talked about the 1.5 release and Martin's idea for releasing 1.5, 1.5.1 and then calling the 1.5.2 Inkscape's 2.0. This is in an attempt to promote stability an give users the time to field trial some of the new functionality before we make a big splash with the 2.0. We talked about freeze policy. Mikekov went through some of the remaining open issues in Gtk4. Martin asked if our Gtk upstream needs help or not or if things are progressing organically at the right speed for our release on macOS, windows etc. We talked about the dificulty of getting program admins who can organise projects that pay people to work on different aspects of our release issues. And our recruitment of volunteers that tends to depend heavily on programmers instead of people who might be more stilled in admin releated organising. Mikekov helped with the Dash2 issues, and doing merge requests. His currently thinking about the preferences dialog. He's been medidating on how to clarify the preferences to reduce the amount of duplicate code and depend on the glade file directly. There's a couple of routes to having preferences paths defined in glade files and widgets constructed with simple APIs, there's a refactoring pathway for how we would get there too. But the ultimate aim would be to remove most of the code until only loading of the glade file remains. We talked about how Gtk custom widgets work so we don't need to load each widget by Id. Tav has been working on color in CSS issues with export. He wants to have a meeting with Martin to talk about Color further. He's looking into the problem of integer artefacts and generating example files in 16bit to test how browsers are currently dealing with the older limitations and if they have been overcome. Some of these artefacts are actically used by filter designers as inputs to produce iteresting results. Report on Bug Accelerator Program, Tav has a few hours left. Martin talked about his engine improvements and walked through the entire plan for filters, color, memory surface management and the stepping stones that are being worked on to get everything in place for CMYK support. Tav and Martin talked about various details in support and what it means for SVG. Tav says that the attendance at the late meeting is very poor. Should we redefine a new time for that meeting so it's easier for other contributors. Martin asked Tav to make a survay for all the new contributors about their availability. Thanks to everyone who was able to come to this week's meeting. Best Regards, Martin Owens

1 0

Policy Discussion: Social Media and Inkscape's Presence in other spaces
by Martin Owens 03 Oct '25

03 Oct '25

Dear PLC, The vectors team are requesting guidance on the use of social media spaces such as Twitter which have become problematic. I believe that such guidance can be made into a generalisable project wide policy and present here a draft for what this might look like. Request for comment, since I've probably over thinking it: ======= # Inkscape Community Spaces Policy Inkscape is a project with a wide and inclusive community who participate in many places online. We do not wish to restrict what spaces people participate in as users, or even fan groups; but must be decisive about which spaces can be counted as official, use the inkscape trademark and brand identity and what rules must apply in those instances. ## Official Inkscape Community Space A space which is run by the Inkscape project must follow these rules to be considered an official Inkscape Community Space: 1. It must be run: 1a. On an Inkscape controlled infrastructure or Virtual Private server for example the inkscape website, chat room, forum, etc. 2b. On behalf of the project by a third party running Free Software server components. For example BigBlueButton, GitLab, Mastodon etc 3c. Be given a special exception by the Project Leadership Committee. 2. It must strictly follow the Code of Conduct: https://inkscape.org/community/coc/ 3. It must have a moderator, or moderator team that can respond in reasonable time to abuse. 4. If possible, it should use the Inkscape branding, mark, and domain name to associate itself with the project. 5. Should be linked directly from the Inkscape website as a core part of the community infrastructure. 6. May be private for contributors, special team members, project leads or users in general depending on the needs of the platform. ## Official Inkscape Outpost A space that is run on some other platform, which is used for outreach, advertising, news and to connect with the wider user community in the existing spaces where they have existing accounts. These rules apply to official outposts: 1. It must NOT be run by Inkscape, but must be in a third party website or service. 2. Must have an account or administrator which is ownable by the project where a copy of the required credentials to access the service can be maintained in the PLC accessible credentials repository. 3. Must not be used for contributions to the project: a. As a permanent store of code, merge requests, issues, graphics, or designs or canonical store of official documentation except where it is a published copy or clone for read-only accessibility. b. A singular place for user sentiment, such as polling and surveys, except where such a poll or survey is also available elsewhere AND the results are copied into the project's core spaces for record keeping once completed. 4. Must NOT act as a place where users believe they are talking with, reporting to, or filing complaints with the actual Inkscape Project. When users attempt to contact "The Inkscape Project" through an outpost service, the user should be redirected to official channels, issue trackers, website, mailing lists etc by a moderator. This redirection should be made available in the bio/profile text for clarity. 4. All participants must follow the Code of Conduct and where moderation and administration is possible, the code of conduct should supersede local rules. Where administration is not possible, blocking and block lists may be employed to moderate the spaces. 5. Must not be on a platform known for or owned by people intent on popularising, propagandising or otherwise supporting hate, fascism, terrorism, violence, sexual abuse, and other politically ideological wider communities. 6. Must NOT be linked from the Inkscape website. The outpost service is intended to support users who are already on those platforms, not encouraging new users to join them. But should include links FROM those sites or service profiles TO Inkscape and it's core community platforms such as the website and forums. 7. Should have activity at least once per three months to indicate its still in use and has interest in being maintained. 8. May use Inkscape's trademark and logo, but must try and communicate that it is for outreach, news, user community, etc and where it is a website that invites technical contributions should make it clear that the service is not being used for that an redirect people to the correct resource. ## Fan/User Run Communities Some communities are run by users who are not involved with the Inkscape project and are not bound by our code of conduct. So our rules are generally about the appearance of being official and the use of our trademark: 1. Are encouraged to use the Inkscape Code of Conduct as a way of managing their moderation. 2. Must not use the Inkscape brand or logo unmodified, in the same ways as the trademark policy specifies for Inkscape code and binary publications. 3. Must not use the inkscape name as a domain name, or an inkscape domain with a separate country level top level domain. Except where there is sufficient differentiation that it wouldn't be confused with being run by the project itself. 4. Must not be linked from the Inkscape website, etc. 5. May copy news, announcements, and participate in discussions about outreach where necessary. 6. Must not advertise themselves as official, or create confusion that posting, commenting, or sending private messages would be the same as communicating with the Inkscape Project. ---------------------------------------------------------- Sorry for the long read! Best Regards, Martin Owens

1 1

PLC Status Meeting
by Ted Gould 03 Oct '25

03 Oct '25

Hello Folks, There is a PLC Status Meeting scheduled for tomorrow (Oct 3). Unfortunately I'm going to have to send my condolences again. This time at Texas Linux Fest, which has all of its graphics done with free tools (including a lot of Inkscape). Sorry to miss two in a row. Could someone else run the meeting please? Thank you, Ted

2 1

Inkscape Developer Meeting, Oct 1st 2025
by Martin Owens 01 Oct '25

01 Oct '25

Hey Developers, Event: https://inkscape.org/cals/event/64/ Attending: Martin, Youstena, René, Tav Next Meeting: https://inkscape.org/cals/event/1/ Martin starts off with a quick introduction, and a short update on the website updates and the downtime people may have experienced. René looking into windows CI, it felt so bad that he felt he had to work on it. The goal is to make it faster and usable as being so slow sucks the joy out of everythig. The 7z archive builder is now running on a persistant runner which René said he would never run one again, but it was required to make it much much faster. The mechanism for depedancies was switched from 7z packaged, to a Microsoft based format which has advantages which can mounted and doesn't need to be 'extracted' as well as being more windows native. There's a bit of work more to do which is how easily it is to build depedencies, moving the config back into the main CI builder itself. Martin Martin talked abut Gtk and the need to keep the version we are building with and targeting for 1.5 will have to be a future version because of the known bugs that will have to be fixed in time for release. Martin's work on filter rendering and unit testing and is currently working on Light sources after completing the ConvolveMatrix work last week. A lot of tricky decisions will have to be made about interpolating in other color spaces but the new code will give us the flexibility to choose. Some backwards compatability will be needed for Integer calculations too. Tav has been working on CSS Color parsing and some of the found bugs, checking over our support introduced by Martin in 1.5. The Lch color conversion was wrong and has now been fixed, case insenstivity, and a range issue on Lch. Tav has questions about the color picker, we're currntly using Luv in the color picker. Martin and Tav had talk about color, rendering, document color space. Talking about how to achieve backwards compatibility and various other issues between Inkscape and SVG for color support. Youstena is a student from Egypt who is interesting in contributing to open source and introduced themselves. We asked around if anyone still needed to claim from the SFC, Tav was waiting on something but he'd put it in later too. We may want to make sure per-deim and travel between events where there is more than one event happening should be in the next vote. Thanks everyone for coming!

1 0