Hello Mark,

I’m JF, from Paris, France. I’m co-founder of Optimistik (Analytics for industrial companies). Last year, my company was looking for an open source SVG Editor to complement our dashboards and we found SVGEdit. The project was not in a very nice state with a very old code, no more maintainers, etc… so we contacted one of the maintainers to be part of the SVGEdit team which they accepted. We started to refresh the project. We created a version V7 more modern, re-architectured most of the code, removed or updated old dependencies, started to fix many remaining bugs…etc.. We fund the project with half time of a developer + my time (in week-ends or evenings..). I think we are getting very close to our goal.

A few days ago, I realized you are also active on your editor forked from SVGEdit (Congratulations for the look by the way).

I was wondering if you would be interested to discuss if any collaboration would be beneficial … We could think about many ways to do this: we could combine the best ideas in a single project, we could externalize the svgcanvas component that we could both use and jointly maintain, etc… or any other idea that you may have.

What is your view?

Kind regards JF

My response:

Hi JF

Nice to hear from you, I’ve seen the monumental refactor done to SVG-Edit in recent years and congratulate you on the results. In fact, when I saw the direction of the project I wondered if it wouldn’t be better to join the effort rather than to quietly work on my fork.

To figure out if this was feasible I worked on something simple (getting the rulers to take advantage of higher dpi displays) and I sent a PR (though I still see low res rulers in the current version, I ignore why).

In the process of making this PR I discovered it takes me several seconds to recompile everything on my machine with each change, and even though this is standard in front-end development affairs, it makes me terribly inefficient and prevents me from enjoying coding because it breaks my flow. In my fork I have things set up so that it only compiles as a build step, and not with every change.

This may seem like a small thing, but I’ve verified time and time again that I cannot work on a codebase that doesn’t compile (or compiles instantly). This is mainly to explain my absence from the resurrection of SVG Edit, which I think is great, and to discount merging projects. I’ve heard great things about snowpack in this regard, but I’m too ignorant of build tools as to attempt to do it myself.

Sharing the svgcanvas.js codebase is something I would be very interested in participating in. I see that you refactored it into several files, which was much needed. However, I’m a designer who happens to do some front-end coding and a lot of the code here is above my head. I understand everything dom related, but the math I don’t dare to touch. I clarify this because I feel my contributions to svgcanvas would be limited.

I would suggest that my talents would be better used on the UI of SVG-Edit. There are many areas where the user experience can be improved quite easily.

Another issue is that—at this time—I find myself up to the neck in work, I expect my schedule to clear up in two months or so. This has the advantage of giving us some time to bounce around ideas for collaboration and hopefully find win-win scenarios for both projects.

Kind regards, M