I updated to 0.92 just now and tested my extensions, and it looks like various distances and sizes are all off in irregular and confusing ways. I expected maybe a few % off (uniformly) because of the 90 to 96 dpi change I saw mentioned in the 0.92 changelog, but it is worse than that.

The hexmap extension (https://github.com/lifelike/hexmapextension) if asked to generate a grid with 1 inch hexes instead creates hexes that are about 3 inches across. Something with the changes to viewPort or something perhaps? It is almost as if the user-units becomes mm instead of 1/96 inches somehow (even if the extension operates on a blank document created by Inkscape and does not modify anything except the content it adds in new layers)?

The countersheets extension (https://github.com/lifelike/countersheetsextension), supposed to pack counters in nice rectangular blocks instead spreads them out a bit irregular with no obvious pattern. It is not just a scale error 96/90 but different errors for different counters, as if the calculations (that worked in 0.91) for how much to offset each counter has somehow broken down completely. The calculation is based on running Inkscape with the query-all flag and parsing the output, then doing a bit of magic to compensate for transforms. But it was never hardcoded to know anything about dpi.

Just thought it was worth posting about this here in case it rings any bells and someone has some suggestions about things I probably need to look at.

Ideally I would like to come up with solutions that makes the extensions still work properly with older versions of Inkscape as well, so that users are not forced to upgrade to 0.92 (and I do not have to maintain two versions).

Today more than ever I wish there was a proper plugin API for Inkscape so you could call some well-defined and stable python-functions to do work instead of having to do operations on the raw XML and try to produce XML that ends up correct in Inkscape. Perhaps there is something in inkex.py I could have used that would have made the extensions safe from the new changes?

Just creating a new empty documents makes it use a viewport that is the same size as the document in mm, so the user-units are mm, which explains the error in hex-size. Since I have to use user-units in specifying path coordinates I guess I somehow needs a way to get the size of user-units in the extension, but not sure how to do that other than by parsing the xml-tag attributes and trying to mimic the calculation done by Inkscape?

I didn't look into that yet, and didn't know there would be incompatibilities. It seems we will need instructions for updating incompatible extensions.
Can you make a bug report at launchpad for Inkscape?

It would be good if those could be added to the release notes. And I'm sure suv will know what needs to be done (while I don't have a clue).

I need to investigate a bit more before I start writing bug reports.

Compared the output of --query-all between 0.91 and 0.92 and the output differs for the same file. The x coordinate reported for one of my templates used by the extension are for instance -605.6053 in 0.92, but -567.75497 in 0.91 and other values looks like they are similarly off. That might very well be different enough to explain why the output is now wrong, but I need to experiment more.

EDIT: Oh, the difference between 567 and 605 turns out to be exactly 90/96. Still interesting because there is no 90 hardcoded in that extension, so not sure why it is confused by the dpi being changed.

Then the thing about coordinates being suddenly in mm even for an empty new document is probably unrelated.

Just multiplying all coordinates read from --query-all by 90.0/96.0 made the countersheets work as expected. Of course using that hack will make the extension break for 0.91 and older instead. Also perhaps something can still break depending on if Inkscape is applying some magic to convert the dpi on some document or not?

Do not feel too happy about just adding a scaling factor like that, where none should be needed anyway. Will keep looking for a proper way to fix it.

If I put some templates in a new document and generate a countersheet there (instead of opening an old existing SVG document with templates) then that issue with user-units kicks in and the generated counters are way outside of the document because they are translated in mm instead of pixels.

Hi.

Sorry that you got no replies from developers. Would suggest trying the bug tracker or the #inkscape-devel channel at freenode irc. That way you can catch the developers attention better.

Tried it here: https://bugs.launchpad.net/inkscape/+bug/1654907

Thanks! I added a Question for it on launchpad a few days ago (and now mentioned as a comment in your bug).

https://answers.launchpad.net/inkscape/+question/431543

Hexmap extension works in 0.92 if I set the viewBox attribute to the same value as is used in the 0.91 template.

It looks as if unittouu helper function in 0.92 calculates the actual size of user-units so that if I use that everywhere (instead of hardcoding 1 inch = 90 px as in hexmapextension) it should work. But no idea why that affects countersheetsextension. Will look into that next after I have committed a fix for the hexmaps.

Yes, for units in extensions, you're supposed to use that function.

Yes, hexmapextension could be easily fixed by just making sure to use unitstouu everywhere, but still not sure what is wrong about the coordinates in the countersheetsextension (that uses a lot more magic and calculations on transforms to figure out how to position things, but as far as I can see do not rely on the size of user-units for anything... but it probably does somehow).

Asking around at Launchpad and inkscape-dev seems to have helped (or at least I understand the issue better). There is a bug over a year old about unittouu not working properly for old documents (or any other documents that do not have user-units that are not one of the predefined standard lengths). There seems to be some existing workarounds used by bundled extensions that I might be able to use.

https://bugs.launchpad.net/inkscape/+bug/1508400

Thanks for reporting back, Pelle! Please let us know if / when you made it work!