I draw figures for my mathematical lecture notes using Inkscape (2019)

Like everyone else I know, I learned Ipe through trial and error, with a handful of little tidbits of advice. 90% of the functionality you will use is quite intuitive and right there on the interface if you hover over things (and all the tools also have keyboard shortcuts of course). Some of the tips I've given/been given over the years that are less intuitive are: - You can save directly in PDF and re-edit a PDF saved with Ipe. This is very helpful for a LaTeX project, since PDF files are very easy to import (even ones with multiple pages). - When you import into a LaTeX project, the dimensions of the figure will be cropped to the dimensions of the actual content (this may be obvious to some, but it wasn't to me). - You can edit the alignment of text (and other various hidden options) by right clicking on objects in select mode. - The different snapping modes are probably the killer feature of Ipe. You can snap to the intersection of curves, to the vertices of polylines, and much more. Between the intersection snapping mode, circle tool, and line segment tool, you can technically perform any compass-ruler construction you want from Euclidean geometry (with has been useful a handful of times for me surprisingly). - Selection of objects is a bit funny (but often useful): If you select from top-left to bottom-right, then you will only select things your selection box fully encapsulates. If you select instead from bottom-right to top-left, you will select anything your selection box intersects. - Writing extensions and editing configs (incl changing page dimensions, colour palette, text size palette) is unfortunately quite painful, and I can only recommend digging through the examples. I believe there is documentation somewhere, but I found it less than helpful. - You can edit the underlying points of any curve you place after the fact by using the "edit" option in the right-click menu. - In order to use the regular k-gon "ipelet" (under ipelets->goodies IIRC), you need to have a circle present first (which you can of course delete afterwards). Ipelets are the mechanism by which you can program functionality with Lua, and this is probably the one I use the most (it comes built in with the program).

In my personal opinion, the only major weak point of Ipe is how annoying it is to rotate things (to the point where I often prefer to redraw things in rotated form, unless it's quite complex). To do this you need to very carefully select a pivot point type and a rotation type through the right-click menu. You also have to be very conscious of snapping as you perform the rotation.

However, most work will focus on the end result -- i.e. a paper with static exported figures.

At any rate, there's nothing wrong with the proprietary tools either -- they're great. It's just a matter of what you can get access to and what's best for the use case at hand.

If it helps to have some examples, pretty much every figure in my dissertation was made with a combination of matplotlib, QGIS, and Inkscape: http://digital.library.wisc.edu/1711.dl/YHJWFVKMNVZGN8S E.g. see fig 2.12 for a cartoon made purely in Inkscape and things like fig 2.4 or 2.6 are a combination of matplotlib and Inkscape.

Specific to this article, the alignment tools have recently gotten a pass of updates - something which everyone doing technical drawings can make use of. Layers and objects have been merged into one panel and the update performance of the panel uses a more scalable algorithm now, making it easier to navigate the document in outline form and reducing some of the burdens of object manipulation that the author calls out to external code for.

Styling still needs improvement but IIRC there is work in progress on swatches that might address that.

It's now possible to use a command bar to type in commands (as is the trend with every complex app) which addresses some of the use of macros. Shortcut binding is in need a pass to improve assignability; that would eliminate a second source of pain.

It is always better to choose a tool where you're least likely to run into a dead-end street.

This isn't about figures but rather making it more productive to use in general, and making its use more semantically analysable, and more deterministic: If you include data in a paper is it actually up to date? Does that expression actually solve the equation etc. These are all things you could check automatically.

There are obviously bigger problems in science but what are you gonna do about them? It's nearly all political either in the department's or in government, whereas a new LaTeX is a relatively direct thing that can be done with a small team and a lot of money.

I love LaTeX and use it everyday, and in particular I have no gripes with compile time, but honestly it's only doing just fine (in terms of usage) because there's no alternative, not due to its own merits. Because the UX is ridiculously outdated.

- Needing to compile 2 or 3 times to get the document right (and not having an option of doing it automatically or been warned about it).

- Need to include an unusual Unicode character? Good luck navigating the different packages for character encodings, font encodings, etc. A couple of days ago we needed to include Қ (Tajik/Uzbek/Kazakh character) and after a few hours of googling and desperately trying several solutions that in theory should work, we ended up including a vector image of the character created in Inkscape (funnily enough the workaround is less bad than it sounds, because the Inkscape image actually has the character as a character, and latex is smart enough to make it copy-pastable as any other text character). Honestly in 2022 any software should Just Work(tm) with Unicode, period. It's trivial to write Қ in a modern browser and have it appear in HN, for example.

- Interactions between packages making a mess, so when you want to pitch your paper to a new journal and adopt their template, multiple errors start to come up, and after trying to decipher some cryptic messages, you find the hard way that some table package you're using is incompatible with the journal template.

- Related to the previous... error messages are sometimes extremely cryptic. Especially when something you do causes an error to be caught inside a package you're using, and you get pointed to a line that doesn't even relate to your code at hand.

- There is nothing to ease the learning curve, so entire scientific fields won't touch it. Why can't we have something that is as simple as Markdown if you just want to create a simple document with headers and lists, and where complexity is added as you need it?

I use LaTeX because all alternatives I know are worse but to me, it's a clear example of a local minimum where we are stuck. It would take a lot of effort to create something better so no one does it, and as a result we have to do with an UX from the 80s. I just wish people wouldn't act as if it were the bee's knees every time its obvious aging is mentioned.