A progress update for my Outreachy internship on Librsvg. Also, GUADEC is happening this week, are you registered?
My first steps into working on this internship with Librsvg was learning about what to learn about. From Rust to the internals of Librsvg itself, I had a lot of unfamiliar things thrust at me, but I used the bits of time I had the first weeks and poured time into learning about everything I could for this project. I tried to go into this with as much of an open mind as I could, learning about all these new things with eagerness. Largest on the to-do list was organizing what needed to be done, so I did what I generally do and made a list! I listed out in a spreadsheet a subset of the features SVG 2 had added, then Federico (my mentor, maintainer of Librsvg and GNOME co-founder, for those of you not seeing this post on planet GNOME) and I sorted that list, removed things that weren’t applicable, and added things that were, until we got a more detailed list up on the Librsvg Gitlab wiki.
First Bits of Code
Following this first step, Federico gave me some tasks to focus on, so I got to coding! The first task I worked on was implementing orient=”auto-start-reverse” as a property for the marker element. This required changing quite a few files and learning a lot about how the code fit together for the orientation and rendering of markers, but Federico walked me through the code to help me learn how it all fit together, leaving notes for how it should be implemented, and after a long walkthrough of the code with a lot of notes, I got to working on it. It was a bit rough, especially with me fighting Git to actually get everything in order, but Federico helped me along the way to finally get it done and the merge request made! Git can be a very complex and annoying machine to a newcomer, and my experience with it was (and still is) no exception.
One example of auto-start-reverse is this train map, this is the fixed version.
The original image, see the grey arrows that point where the lines go? From Wikimedia: https://commons.wikimedia.org/wiki/File:S-Bahn_RheinNeckar2020.svg (SVG is GPLv3)
Following that was another set of changes that required learning an entirely different part of the code, context-fill and context-stroke for the marker element, or allowing an element to get its fill and stroke from another object by context (context meaning a convoluted process of inheritance that depends on the element being referenced). This also took a tour of the code to get implemented, which was exciting, as it delved more deeply with the rendering code and how it all fit together, and how elements got their final colors from the SVG file all the way to the final render. It was fascinating to learn about the rendering pipeline and the process of all the property values getting their values parsed and stored (something which I’m about to tackle more in depth in the future). It’s still work-in-progress for the second half, implementing for the use element, but it’s close to being done!
This is one of the tests for context fill and stroke, with this one being the fixed version, here the circles on the green line and corners of the blue square render how they’re supposed to.
This is how it used to render, the differences are especially noticeable on the circles on the green bar, and the corners of the blue square.
Learning Some More
This was the step where I learned the most about Git, and how to use it in a way that wasn’t my old ‘everything goes on the main branch and I’ll just delete it and re-download when it is too much to handle or I need to sync with the main repository’ method of making it work. Now I make a new branch, keep my main branch in sync with the upstream, and can even merge new changes to main back into the changes I made in the separate branch! It’s a wondrous boost to my ease of use and happiness.
Aside from that, I spent an evening making some scripts to run a docker image of OpenSUSE on my Fedora machine to then run the Librsvg test suite inside of it. It was fun, as I had last worked with Docker when running Nextcloud through it, so learning how to work with it in a slightly less complex environment was quite educational. So now there’s a fairly functional set of scripts to run the test suite in a OpenSUSE, Fedora, or Debian docker container, for all your development needs! These scripts also allowed Federico to debug a sporatic memory bug that’s been crashing our Gitlab CI for a while, which was eventually traced back to a bug with Pango and has been fixed upstream!
The next feature I tackled after that was implementing paint-order for text, which allows someone to specify whether a bit of text’s fill is supposed to go on top of or below the stroke, or outline. It’s a very useful feature, and this is the first feature that I completed the first draft of without too much assistance. It was awesome seeing it working when I finished. See here:
This is one of the tests for paint-order on text, with the right ‘pizazz’ being marked to have the fill on top of the stroke.
This is how it used to render, with the right one having the fill completely hidden by the stroke.
After that I began working on auto width and height for image, rect, and SVG elements. This feature varies depending on the element it’s applied to, but the part of the code that needed to be modified was about the same for each of them, so I was able to get it mostly done by myself with just some questions and feedback on it. This was also the first changes where I practiced using Git to merge my mess of commits down into one to ease merging upstream, which was really satisfying to understand how to use.
GUADEC & The Future
Finally, we’re to the present day! GUADEC is this week, and I’ll be participating in the intern lighting talks on Friday, so make sure to register for it and attend! Learning about so many different things and becoming a part of this community has been an amazing experience so far, I’m very thankful for the past half of the internship and so excited about the future. Thank you!