Inkscape 1.0 (beta) drops `--file=FILE` and `--export-TYPE=FILE` command-line compatibility

Steps to reproduce:

Run long-established (in the build system of other SW) command akin to

inkscape --file=foo.svg --export-dpi=45 -C --export-png=foo-small.png

What happened?

Unknown option --file=foo.svg

What should have happened?

The command shall be accepted as it has always been :-)

Inkscape Version and Operating System:

Fedora Rawhide.

$ rpm -q inkscape
inkscape-1.0-0.beta.fc32.2.x86_64
$ inkscape --version 2>/dev/null
Inkscape 1.0beta1 (fe3e306978, 2019-09-17)

---

Relevant commit/change seems to be: https://gitlab.com/inkscape/inkscape/commit/408cb49b5559a81ea803df64bf58457a5dd4bf16?expanded=1&w=1

(notice that there's no --file substitute without any further commentary).

I couldn't find any remarks at https://wiki.inkscape.org/wiki/index.php?title=Release_notes/1.0 either.

Note that this is really an abrupt change that's going to break a lot of automation, hence I think it'd be highly advisable to maintain this command-line "API" compatibility throughout 1.x line, even if it would be, for instance, accompanied with a deprecation warning if that's indeed a desired direction.

Thanks for considering!

Also note that keeping --file=foo.png where mere foo.png would work alone could be caused with a not too clear (option string may be excluded) wording in the original help screen.

Hmm, --export-png no longer works, either, thought this was all to it.

Now, any (SW build system) automations relying on Inkscape to distill curves into pixels are in a pretty precarious situation.

Is it really intended that these would need to "smartly" conditionalize (i.e., complexity growth) on the Inkscape version happening to be in the environment?

changed title from Inkscape 1.0 (beta) drops --file=FILE command-line compatibility to Inkscape 1.0 (beta) drops --file=FILE {+and --export-TYPE=FILE +}command-line compatibility

Hi @poki. I followed your instructions and I got the same result:

C:\Users\Owner\Desktop\Apps\inkscape-1.0beta2_2019-12-05_a71adda-x64\inkscape\bin>inkscape --file=foo.svg --export-dpi=45 -C --export-png=foo-small.png

(org.inkscape.Inkscape:11900): GLib-GIO-WARNING **: 14:44:08.250: win32 session dbus binary not found: C:\Users\Owner\Desktop\Apps\inkscape-1.0beta2_2019-12-05_a71adda-x64\inkscape\bin\\gdbus.exe
Unknown option --file=foo.svg

I am just not sure if this is a bug or if this functionality of the application that was removed intentionally. Maybe @doctormo, @Moini, or @ede123 would be able to clarify this a bit better.

My info:

• Operating System: Windows 10 Home
• Operating System Version: Version 1903 (OS Build 18362.476)
• Inkscape Version: 1.0beta 2

@poki you also forgot to mention valuable information for us (Operating system (name and version) and inkscape version as well). Thank you.

added 1 deleted label

added 1 deleted label

Youp \usepackage{svg} broke. Nice :)

https://github.com/mrpiggi/svg/issues/20

mentioned in issue tista500/plata-theme#91 (closed)

you also forgot to mention valuable information for us (Operating > system (name and version) and inkscape version as well).

I did not ... all provided in the initial description.

---

Nonetheless, @kgaillot noticed that there was another "inconsistency" (intentionally quoted for a paradox we shall see later) in how the respective surrogate shall look like between said beta and rc1. This really verges on very tough maintainability for (said) build systems that aim to be "work equally everywhere", unless some more complexity (equals costs) are put into that. I think some more considerations around these "batch production" use cases might be appropriate.

Respective merge request, justified with "consistency" (which apparently means everything but the long term usability consistency): inkscape!1433 (merged)

added support request / question label and removed 1 deleted label

marked this issue as related to #2741 (closed)

marked this issue as related to #2855 (closed)

I guess the policy seems to be that there should be no way to use inkscape compatibly across versions? :(

The problem with the lack of compatibility is that now I need to make every script that uses inkscape know about both interfaces for the foreseeable future. So since you weren't willing to do that in inkscape itself, everyone else needs to do it again and again. Changing an interface that is used in build scripts is a terrible thing to do to people, and doing it in such a way that we can simply fix said scripts adds insult to injury.

For now I can put off dealing with this, and perhaps better to just find another tool for the job. I've got until Debian makes it's next release, to the extent that I can avoid using my laptop for paper writing.

@daveroundy I tend to agree. Although I think an inkscape intermediary script could be fashioned to translate one format to the other since it was literally impossible (technically) to do inside of Inkscape 1.0.

The problem I saw, was that there weren't any contributors who were interested in developing this.

I fail to understand why this is such a big deal. It's really not that unusual that interfaces change from time to time. You either adapt and move on or you stick with the version(s) you have.

I've looked at your GitLab @daveroundy trying to see what scripts you are talking about. You are using Inkscape to create PDFs in Makefile and papers/paper/figures/fac-svgs.py. If this is what you're talking about, a small intermediary script as @doctormo mentioned will do the job. In your case it'll be really simple since you only have to take care of translating --export-pdf to the new format.

That's just false. Well maintained command line told don't change their interfaces for precisely this reason. Making everyone modify all their programs is a great way to make everyone decide yours is not software they want to use. I've never before encountered a change like this in about twenty years of computational physics. The closest I've seen is tools stop being maintained and drop entirely out of Debian.

I hardly have anything up on gitlab, and relatively little on GitHub. I haven't bothered dealing with this (it running a grep to count the instances that will need changes) because it's only my laptop that now has the new inkscape and I can just not work on papers until the quarter ends. My plan is to see whether cairosvg meets my needs at that time.

Let's leave it at that. Whenever people resort to "arguments" like "I have x years of experience and never seen this" and "threats" like "I'm not going to use your software anymore" there's really no point in talking to them.

I agree. When a software developer respond to a bug report with an "I don't care about your experience" there's really no point continuing to discuss the bug. Telling me that it's easy for me to parse and convert command line flags, but impractical for you to do so does not make me feel any better.

Also cannot but to defend the conservative view here, which I tried to raise here as soon as I spotted the change is upon us users (as you can see, it was half a year ago, not the best outcome ever that the interface allegedly received yet another shake in the interim).

I think it is quite a testament of the importance of the free-standing SVG renderer that inkscape became go-to solution for this task (admittedly despite this not being its main purpose). But that alone means there is a ton of "batch use case" scripting around, and I can only imagine plenty of them, like from source generated documentation of some SW as mentioned, will only get exercised infrequently (yep, despite all the CI calls, which actually led me to this discovery), so some pain about this disruptive change is still deferred, yet imminent. Ditto when such processing is based off slow-rolling and LTS OS distributions -- respective audience is yet to discover they have now new things to tackle. Heck, I cannot easily regenerate my master thesis now, unlike with the dead-conservative LaTeX part alone :-)

Showing some responsibility under this perhaps originally not anticipated (but see above) weight would mean one-off centralized effort to preserve original command-line interface vs. hard-to-quantify (but perhaps non-negligible) effort spread over the cases of still latent disruption. Would this constructive discussion regarding the work that needs to be done to undo particular effect of existing change(s) occur at the point it was raised, perhaps there would be more happiness around now.

@daveroundy The only reason we changed the command line interface was because we were forced to by using the g Application class. There was a big discussion of the problem a few years ago, but I don't think in this case the project did enough to account for the massive number of users using Inkscape on the command line.

Alas the change was forced on us. So an argument about whether it should or shouldn't have been changed isn't on the cards. But a discussion about what can be done about it, is something we should think about.

I think we should simply implement a legacy fallback. It's gonna be less than 100 lines of code, seriously.

mentioned in commit speleo3/inkscape@2aa787d9

mentioned in merge request inkscape!2056 (merged)

mentioned in commit speleo3/inkscape@3ca6a4ed

changed milestone to %Inkscape 1.0.1

closed

Is this also for master or only for 1.0.x?

I'm asking, because if the goal of this is to ensure the old options continue to work for the foreseeable future for convenience of users it should likely be in 1.1+, too.

If the goal was to inform users about the deprecations and have them update their scripts - well we basically had already implemented that in the most efficient way by removing those options altogether forcing people to update . Having it in 1.0.1 "only" might not be overly useful anymore for most people that are facing the issue now.

I meant to cherry-pick it to master, sorry for the delay. Here it is: inkscape!2066 (merged)

Thanks!

mentioned in commit speleo3/inkscape@60faa23c

mentioned in merge request inkscape!2066 (merged)

added command line interface (CLI) label