Documents created before experimental branch merge get scaled by 90/96

Bug #1389723 reported by LucaDC on 2014-11-05
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

Roadmap for 0.92: (this bug)
√ Non-pixel units are allowed but everything in a document should use the same units including guides and grids. (Guides and grids need code to do this --> see bug #1400702).
- An extension that saves a document in pixels should be added to allow backwards compatibility with 0.91.
- Optionally add viewBox if document is affected as described here:

It should be possible to avoid overwriting Inkscape version until any necessary conversion is done. If a conversion appears to be needed, a pop-up can ask the author if it should be done.

Roadmap for 0.91: (bug #1387864)
√ Everything should use only pixels as is (mostly) done in 0.48 (including templates). For guides, grids, 3dbox see bug #1400702.
√ The ability to switch document units should be disabled (it's broken in several ways).
√ Font size should be stored in pixels.

See also:
Related mailing list threads:

Related wiki page:

Original description:
Merging of experimental branch has introduced the change of px from 90 DPI as 96 DPI.
Being px the internal unit used by Inkscape to save almost everything, all measures in documents created with the 90 DPI convention are now interpreted with the new 96 DPI convention and this causes a rescaling of the entire document by 90/96 (93.75%) if compared with the physical units they were created with.

Even the page is resized, so the problem is not visually evident after opening an old document unless there is an underlying grid which has been specified with an absolute unit (e.g. mm) so objects are no more aligned to it; or until an object whose length is known is measured with a unit different than px.
This lack of evidence could cause a user to start modifying an old document and realizing there is a problem only after a while. In this situation the document has become corrupted as there are now objects rescaled and new objects with correct dimensions. Such a situation could be not easily fixable so the work done so far could be lost.

An important aspect about this issue is that many users never cared (or knew) about the 90 DPI internals of Inkscape and are probably not going to care (or to know) about the change to 96 DPI. They are only going to find their documents corrupted.

The proposed solution is to find a way to recognize old documents (differentiating the news?) and, at least, warn the user upon opening them that a rescaling has occurred. Better would be to offer an automatic way to fix this unwanted rescaling, if it's the case; in fact for some documents it would be inappropriate, for example a document whose default unit was intended to be px no matter at what DPI hence it does not have any reference to physical units inside.

Lack of doing anything about this issue could result in document corruption and data loss.

su_v (suv-lp) on 2014-11-05
Changed in inkscape:
milestone: none → 0.92
tags: added: units
LucaDC (dicappello) wrote :

For reference, merge of experimental branch has happened in Rev. 13641.

Documents created with revisions just before 13641 are probably not affected thanks to the new viewbox approach.

Guides are always affected as they're still saved in px.
Attached document has been created with Rev. 13640. When opened with Rev. >= 13641 page, square and grid are correct, guides are not.

Zoom level and zoom correction are also affected.

LucaDC (dicappello) wrote :
Alvin Penner (apenner) wrote :

confirmed using square.svg

Changed in inkscape:
status: New → Confirmed
Alvin Penner (apenner) wrote :

in my case the bug shows up in a slightly different way, but still disconcerting. I prefer to work exclusively in pixels. Attached is a document created in 0.48.5. It uses an A4 page and has a red rectangle which fits the page perfectly in 0.48.5.

Alvin Penner (apenner) wrote :

in trunk, when I load it, it appears at first glance that it also fits the page as well. However, this is not true. Go into Document Properties and note that the page size is not a standard A4 page. Click on the A4 page size and get the attached svg file which has a noticeable mismatch between the rectangle and the page. This is not expected behavior.

Alvin Penner (apenner) wrote :

a proposed solution has been posted at

this seems to work well, when applied to the original file rect0485.svg. The only complaint I would have about this is that it has modified the basic structure of the file. It has created a new group above the normal "Layer 1" group, so the layers are no longer immediately underneath root. When I interrogate the layers dialog, I find only 90to96Layer, not Layer 1 as expected.

LucaDC (dicappello) wrote :

I'm not sure the proposed solution is acceptable in all cases: for example in square.svg no resize in the page nor for the rectangle are needed.
The same applies if the page size is expressed in mm but the drawing is in px rather than having both the page and the drawing in px.
Resizing the whole document tout court could not always be the right thing to do (please, consider I didn't try the proposed solution in all cases so my thoughts are only speculations).

1 comments hidden view all 103 comments
Jabiertxof (jabiertxof) wrote :

Tonight i post two new extensions, to test.
also about SVG detection version mail in list:

Alvin Penner (apenner) Says
> Also, with respect to detecting
> Inkscape version, perhaps you could read the following property of the svg
> file?
> inkscape:version="0.48.5 r10040" = 90 dpi
> inkscape:version="0.91+devel r13646" = 96 dpi
And non inkscape generated files?
Another advert on filter telling isnt a native inkscape, use with care...

Jabiertxof (jabiertxof) on 2014-11-06
Changed in inkscape:
assignee: nobody → Jabiertxof (jabiertxof)
1 comments hidden view all 103 comments
Jabiertxof (jabiertxof) wrote :

Here are two extensions with most of the feedback i get.
Are enought ok to put in trunk?

Jabiertxof (jabiertxof) wrote :

New name DPISwitcher. Only one extension.

A simple DPI Switcher. when confirmed working well, we can "switch" to the alert on open and so on.

There is a problem with inkscape:document, because trunk overwrite this value at open, so we cant know if is a previous version from a extension. For this reason I strip all inkscape::document checks writes and focus in a swith DPI method.

Im scaling/reducing:
//svg:rect | //svg:image | //svg:path | //svg:circle | //svg:ellipse | //svg:text
finaly remove the container from previous codes and apply the transform to each element of this list. I lost anyone?
Groups and clones are evidently out of list.

Zoom are not updated because the SVG stored zoom isnt actual zoom, seems is on close zoom, also, you cant change zoom from extension -not full sure- and finaly, the zoom change is good to give the user impress of the changes.

TODO: improve the ugly late regex sub

Jabiertxof (jabiertxof) wrote :

I commit to trunk. Is a feature needed to all trunk users, not perfect but better than none.

su_v (suv-lp) on 2014-11-08
Changed in inkscape:
importance: Undecided → High
status: Confirmed → In Progress
Alvin Penner (apenner) wrote :

>> There is a problem with inkscape:document, because trunk overwrite this value at open

    yes, I see what you mean about Inkscape automatically overwriting the previous Inkscape version number, so one cannot actually tell which version of Inkscape created the file. That is extremely unfortunate. I think this means that it will never be possible to determine for sure whether a document requires "adjusting" or not. Previously I had thought that perhaps one could search for the magic number of document height="1052.36", since this particular number can only be created in one way, namely 297*90/25.4, which is an almost certain guarantee that this document was created in an earlier version of Inkscape. However even this test would not be sufficient to determine that the document required "adjusting". Attached is a document created in Inkscape 0.48.5 using the template file default_mm.svg. In this template file the document units are explicitly set to mm, and also the page size is explicitly set to mm, so it should be safe from conversion problems, but it is not. The view you get in 0.48.5 is not the same as what you get in trunk, and the reason is that the original coordinates in 0.48.5 are stored in pixels despite the fact that the document units were mm.
    So I think the conclusion is that there is no way of knowing ahead of time whether a document will require fixing, or not, which is unfortunate.

Alvin Penner (apenner) wrote :

 I just tried out your latest extension from trunk rev 13679. This is very interesting, but I am still having a bit of trouble with it, depending on what the exact sequence of events is.
 Case 1. load the file rect0485.svg from comment 4 above into trunk. This file looks perfectly normal at a first glance, but I know it is wrong so I apply the extension DPI switcher. The result is exactly as expected, the page size physically expands to suit an A4 size, and the red rectangle simultaneously expands as well, so the final result is exactly as wanted, and the Document Properites can be used to confirm this.
 Case 2. load the file as before. In this case I am not sure whether the document requires fixing or not, so I open Document Properties and click on A4 to confirm the page size. This resizes the page but not the red rectangle, so now I know for sure that something is wrong. Now I apply the DPI extension to get the attached result, rect0485_after_extension.svg. This is not the same as above, and not expected.

Jabiertxof (jabiertxof) wrote :

Alvin for #14:
The only solution is ask to the user previously to the overwrite of inkscape version. We can use the code in the extension to switch from 90 to 96, if the user want. Now trying #15

Jabiertxof (jabiertxof) wrote :

Hi Alvin, there is a bug in the code, fixed and commited again to trunk.

Alvin Penner (apenner) wrote :

    I just tested rev 13680. As far as I can tell the behavior has deteriorated since the previous version. I get the warning message saying that Inkscape has received additional information, and it shows me the scale factor of 1.066666667 which is unneeded and did not happen previously.

When I try Case 1 from comment 15, I get the attached result which is unexpected, the original version was better

Alvin Penner (apenner) wrote :

When I try Case 2 from comment 15, I get the attached result which is unexpected, the original version was better

Tavmjong Bah (tavmjong-free) wrote :

The main problem occurs when one mixes units so the best solution is to stop this from happening. I propose the following fixes:

In 0.91: Everything should use only pixels as is (mostly) done in 0.48 (including templates). The ability to switch document units should be disabled (it's broken in several ways). Font size should be stored in pixels. Some templates in 0.48 templates do use 'mm' so there does need to be a script to convert files based on those templates to 96dpi.

In 0.92: Non-pixel units are allowed but everything in a document should use the same units including guides and grids. (Guides and grids need code to do this.) An extension that saves a document in pixels should be added to allow backwards compatability with 0.91.

It should be possible to avoid overwriting Inkscape version until any necessary conversion is done. If a conversion appears to be needed, a pop-up can ask the author if it should be done.

su_v (suv-lp) wrote :

@Tavmjong - thx for this summary of what needs to be changed for 0.91 and 0.92. I propose to track the required items for each release separately: 0.91 in bug #1387864 and 0.92 here (bug #1389723) and will update the bug descriptions with your proposed fixes for each release. Both reports will be tagged as release blockers.

description: updated
tags: added: blocker
Jabiertxof (jabiertxof) wrote :

New version updated to trunk.
Think it work now as expected. Independent the units, all is transformed to pixels at the end.

Alvin Penner (apenner) wrote :

Hello Jabiertxof, thanks for the update! I have tried rev 13682.
For what I called Case 1 in comment 15, the behavior now appears to be correct, thanks.
However Case 2 in comment 15 still does not behave as expected, resulting file attached here. There is a serious mismatch between the rectangle and the document.

Alvin Penner (apenner) wrote :

I just realized that Case 2 described above actually has two possible subcases depending on exactly how the file was loaded.

The original version of Case 2 is:
Case 2a:
- Do a right mouse button click on the file rect0485.svg. Choose Open with Inkscape.
- open the Document Properties dialog and note that the Page Size A4 is _not_ highlighted when it should be.
- note that the document size is 744 * 1052 which is wrong/unexpected.
- click on the size A4 and note that the page size is now 210mm * 297mm as expected
- in the XML editor note that the viewBox is still not defined, which is a bit unexpected
- now run the DPI switcher and note that the XML editor reports the document size as 224 px by 316.8 px. This is a bit unexpected. It looks like 210mm * 96/90 = 224 but with no units attached. This may be part of the problem.

Case 2b, which was previously not encountered:
- load Inkscape from trunk by itself.
- use File->Open to load rect0485.svg
- note that in the Document Properties the Page Size A4 is highlighted as expected. However the reported size is 744px * 1052px which is wrong. Click on A4 to refresh it, nothing happens. Click on US Letter and then click on A4 again to refresh it, now the document size is correct at 210mm * 297mm.
- in the XML editor note that the viewBox is still not defined.
- run the DPI switcher and get the same behavior as in 'a' above.

Both the document size and the viewBox size appear to be wrong at 224 px * 316.8 px, while the rectangle size is 744px * 1052px..

Alvin Penner (apenner) wrote :

speaking somewhat off the cuff, haven't thought about this a lot, but perhaps the conclusion is that page size should be converted by 6% if and only if the page size is expressed in px, whereas in Case 2 it is in mm, so it does not need to be converted.
On the other hand the actual object (rectangle) itself is always in px no matter what, so it always needs to be converted by 6%?

su_v (suv-lp) on 2014-11-09
description: updated
Jabiertxof (jabiertxof) wrote :

I Just update code in trunk handle the descriptions roadmap.
I test it well but never is enought.

One question about this in description:

<quote>for example a document whose default unit was intended to be px no matter at what DPI hence it does not have any reference to physical units inside.</quote>

I not agee, think a 0.48 or 0.91 need to be scaled, for example for print or export to PDF also if you want to change units after
And the same but in reverse method for 0.92
For displays, web, better don't scale.

For me is a easy not scale if units are pixels //comented in code
I have two options select one or ask to the user.
Waths our opinion? Im full wrong?

Jabiertxof (jabiertxof) wrote :

The code don't handle shortener transforms for the moment. I update it soon.

Jabiertxof (jabiertxof) wrote :

Code update, regex improvements and handle shortener transforms

Alvin Penner (apenner) wrote :

rev13696 has been tested for the two cases mentioned above. Case 1 looks perfect. For Case 2 the scaling problem has been fixed, thanks for fixing this!
However there is an unexpected vertical offset in Case 2, file attached here.

Jabiertxof (jabiertxof) wrote :

Hi Alvin, you try the last version? About your problem:
>Case 2. load the file as before. In this case I am not sure whether the document requires fixing or not, so I open

>"Document Properties and click on A4 to confirm the page size".
This action can corrupt document changing original pixels positions

> This resizes the page but not the red rectangle,
To me no resize of page when click A4, and expected results at apply.
Are you sure using file from #14 with no changes?

Alvin Penner (apenner) wrote :

    I am using the original file rect0485.svg from comment 4. It is possible that you may have encountered Case 2b instead of Case 2a which is a bit simpler to deal with. I think the main point is that the main Inkscape code uses the bottom left hand corner of the document as the origin when toggling Page Size units. If you load the file and then toggle the page size units repeatedly between size A4 and size Letter, you will see that the bottom left corner remains fixed as the origin. Since the bottom left is the origin, it is reasonable to expect that the Python extension will also treat it as the origin as well, in order to remain consistent with what Inkscape has been doing. However that is not the case. The origin at the bottom left shifts when applying the extension, which is unexpected.

Jabiertxof (jabiertxof) wrote :

Im using wrong file, now i see it, thanks Alvin. Go to code tonight.

LucaDC (dicappello) wrote :

Hi Jabier,
with regard to your comment #26, in that sentence I was trying to point out that some documents could not need the rescaling at all: think about a 64x64 px icon. It was to say that the conversion should not be applied automatically but the user must always be asked for confirmation.
At the actual state this problem is still not present because we only have an extension that one must know of and choose to deliberately apply to his documents. The situation would be different if an automatic recognition of the document state is introduced (which I think would be appropriate for most non informed users).

Jabiertxof (jabiertxof) wrote :

Hi Alvin i got some time:

Change document units in a migrated document previous to the extension produce "unexpected results".
I coulden't know if the user change document it from 0.92 GUI or become from fresh open document.

But the finality of the script is for run once at open!

Jabiertxof (jabiertxof) wrote :

Hi LucaDC.
Yes icons are similar problem to display or web objects. I think the best option is:
Ask to the user in the extension/prompt at open if the document is for pixels or for units, maybe better from display or print and make the extensions work as the user tell

in display documents you need also scale sometimes the grid -for 0.92 expected behabiour- and maybe, not sure, guides

su_v (suv-lp) wrote :

Maybe (at the current state where it is not run automatically after loading a document) the extension could have an option (an alternative action) to provide information about the current state (size, default units, units for page size, etc.) of the document (without applying changes yet), so that the user could make a better informed decision without actually opening 'Document Properties' and likely changing properties prematurely which makes it impossible to "fix" the old unchanged format.

LucaDC (dicappello) wrote :

Just an idea: why not adding a DPI Inkscape field, if it's not present it's taken as 90 DPI (old behavior) otherwise it should state 96. In this way the need for translation of pixel values would be more easily recognizable.
Also, in the future this DPI value could become specifiable by the user, giving more power to the "real" px unit.

Jabiertxof (jabiertxof) wrote :

LucaDC: I like very much this idea! #37
But this value need to retain unchanged, i think. user cant interact this could break all.

Jabiertxof (jabiertxof) wrote :

Want to put this idea in roadmap?

Jabiertxof (jabiertxof) wrote :

a problem: a 96DPI document not created in inkscape.

23 comments hidden view all 103 comments
Jabiertxof (jabiertxof) wrote :

Thanks Alvin for your hard work on comments, a bad notice you bow out, sorry if im very radical in my point of view.
You always are welcome.

Also a great point about the file for testing.

See you, Jabier.

LucaDC (dicappello) wrote :

Unfortunately I'm not sure I have a complete picture of the situation: there are now different versions in play, starting from 0.48.5 followed by development ones, coming 0.91 and current trunk.
I always keep my local version updated to trunk (even more than once daily; now for this issue I'm stuck at using Rev13640 but I still download and compile trunk) for my works so I don't master all the possible details raised by the various released (or to be released) versions.
I'll see if I can do something but don't expect anything in the near future as spotting, collecting, compiling and analyzing different versions in parallel is quite a complex task for me, given the time I can spend on it.

Jabier, can you point me where I can download the latest version of your script? I'd better try it on my documents, at least.

Jabiertxof (jabiertxof) wrote :

Hi LucaDC. The code is now in trunk and is called dpiswitcher one extension 2 files.

Jabiertxof (jabiertxof) wrote :

For now i remove the code from trunk waiting to be more mature or to select another ways to handle the problem.
I put here the last trunk extension, after attach some files with problems.

Jabiertxof (jabiertxof) wrote :

DPISWITCHER extension 0.4
.inx part

Jabiertxof (jabiertxof) wrote :

DPISWITCHER extension 0.4
.py part

Jabiertxof (jabiertxof) wrote :

This file give wrong results at 90->96 switch. Is a illustrator file but the result of this switch think need to be handled

Jabiertxof (jabiertxof) wrote :

I also have problem with the same file on clips and mask, translating clips to inverse direction. i try with a 0.48 fresh file and no problem with clips mask.

Jabiertxof (jabiertxof) on 2014-11-30
Changed in inkscape:
assignee: Jabiertxof (jabiertxof) → nobody
su_v (suv-lp) on 2014-12-01
Changed in inkscape:
status: In Progress → Triaged
su_v (suv-lp) on 2014-12-10
description: updated
su_v (suv-lp) on 2014-12-10
description: updated
su_v (suv-lp) on 2015-02-24
description: updated
su_v (suv-lp) on 2016-06-05
description: updated
Alvin Penner (apenner) wrote :

see comment 14...

just writing to indicate that an important change in the handling of file names was made in rev 14965, thanks Tav!

Previously the variable 'inkscape:version' would get overwritten on a file load, so that it was not possible for a Python extension to determine the rev number of the original file. Meaning that the user would not know if a scaling operation was required or not. Now it is possible to read this information using the Python code:

This removes one of the major obstacles preventing further development of this extension.
I think it would be worthwhile to re-start the evaluation of this extension.

Jabiertxof (jabiertxof) wrote :

I do this patch. Finaly I ignore the DPI switcher extension by a viewbox based solution.
The Extension is not working ok, anyway I comment code to run the extension if we want this solution, I only need to un-comment and fix the extension.

The text showing need to be fixed and maybe Im wrong at the detection on what need to be switched

There is also a problem with imported documents, they need a DPY switch? If yes the viewbox alternative is not a solution and we need to maybe go to a fixed DPISwitcher extension.

Jabiertxof (jabiertxof) wrote :

Thanks Alvin for your comment.
I have a question Im trying to find diferences 90/96 in a doc in mm from 0.91 to 0.92 and dont notice diferences, Im thinking we need to convert also from 0.91.
Can anybody confirm me only need to focus on 0.48 or less or non inkscape files without viewbox for suggest the conversion? In this case the extension could be OK, need to test again with 0.48 files.

Cheers, Jabier.

Alvin Penner (apenner) wrote :

sorry, I am getting a little confused here:
1. what is the difference between the patch you are proposing in comment 73 and the patch that was proposed by Tav at:

2. see also the comment at:

3. I have a practical problem in that I am no longer able to compile or test Inkscape code. My development machine was a 32 bit XP machine, and the 32 bit libs are currently not working.

Jabiertxof (jabiertxof) wrote :

Thanks Alvin Tav patch is far away better! I dont know why loose this conversations :(
All the best.

Jabiertxof (jabiertxof) wrote :

Hi I just update a patch with some code mixed from TAV patch.
It use dpi switcher extension. Adda hidden -not show in menus- new extension that load dpiswitcher extension with fixed values.

Jabiertxof (jabiertxof) wrote :

I couldent add a hidden effect, so in this patch I divide the dpiswitcher.inx into tree extensions:

DPI 90 to 96
DPI 96 to 90
DOC Info

Jabiertxof (jabiertxof) wrote :

New version numerous bug fixes.

Alvin Penner (apenner) wrote :

 I tested the patch called v0.3 from comment 80. I tested it on the 0.91.x branch using essentially the same test as in the comment at:
The result of the test looks quite reasonable to me. I think this would be worth implementing. If you choose yes to both options then you get a result that is similar to what you would get if you import a pdf file. For a pdf import the import layer has a scale factor of 90/72 caused by a unit change from pt to px. For the current dpiswitcher you get a similar scale factor caused by a dpi change. If you want to do some more editing using the new "96 dpi" units, then you can create a new layer and draw on the new layer in the new 96 dpi units and the result will be represented in the XML file as expected.
 I have only two very minor comments, both of them purely cosmetic:
First of all the user has four possible options coming from two separate questions, namely "viewbox or no" and "scale or no". Of these four options only about 3 or so seem reasonable to me. I can't think of any situation where the user might want to say yes to viewbox and no to scaling. I wonder if it would be possible to ask the scaling question first, since it is the most important one, and then, only if the user says yes, then ask the viewbox question next?
 Secondly I see that the rev number is showing up in the DOS output. I wonder if it would be worthwhile to also add it in the menu item Extensions->Document->DOC Info. It could be added with something that looks like this:
print "version: " + str(self.document.getroot().get(inkex.addNS('version',u'inkscape')))

 Finally it would be really helpful to get feedback from as many other people as possible, since this is likely to be a very serious issue in the new release.
 And thanks for your hard work, Jabier!

Jabiertxof (jabiertxof) on 2016-11-14
Changed in inkscape:
assignee: nobody → Jabiertxof (jabiertxof)
Jabiertxof (jabiertxof) wrote :

Hi Alvin. Im sorry don`t see your reply. Today I speak with Tav about this bug. I give another patch soon with your feedback.

Jabiertxof (jabiertxof) wrote :

Hi I just made another patch. Alvin try your problems with layers are solved. Also add your code to docinfo.

Alvin Penner (apenner) wrote :

thanks Jabiertxof - unfortunately I do not think I will be able to test it. Up to now I have always done my Inkscape work on Windows XP, 32 bit. However it is no longer possible to compile Inkscape trunk on a 32 bit machine, so I have stopped doing work on Inkscape. I do have a working version of 0.92.x branch which I am able to compile, but it appears that your patch is incompatible with 0.92.x. I got a number of failures of the patch command due to errors so I was not able to apply it.
    perhaps someone else could test this on trunk?

Jabiertxof (jabiertxof) wrote :

Hi Alvin, I think Tav giive a review next week.
Anyway you can test with 0.92 the pyton extrensions on the patch. If Tav like it I made a patch for 0.92.x also.

Cheers, Jabier.

Tavmjong Bah (tavmjong-free) wrote :

I have committed to trunk an improved version of my patch (partially based on Jabiertxof's patch) to handle the DPI change by setting an appropriate 'viewBox' attribute. I could not get the DPI switcher part of Jabiertxof's patch to work (the resulting SVG images extended way outside the document area) and am waiting for his feed back. There are "hooks" in my patch for DPI switcher so it should be trivial to add that as an option when all issues are resolved.

Jabiertxof (jabiertxof) wrote :

This patch pass all test on
Anyway the inverse version 96to90 is not tested. Try it soon.

Alvin Penner (apenner) wrote :


I have a question for either or both of you. There is a fundamental and very important difference between the approaches that the two of you have proposed. One approach does the scaling using the viewbox while the other approach did the scaling by modifying the import layer group transform. I am not able to test any of this code because I cannot compile trunk anymore, so could either or both of you explain how you have resolved this discrepancy? It is fairly important for the user to know which method is being used, because they are incompatible.

Jabiertxof (jabiertxof) wrote :

The idea of the patch is propose the final decision to end user: viewBox based or scale ones.
Currently the Tav proposal is on trunk and in 0.92.x but he retain hook to finish my work and also provide me a good test cases to try.

Alvin Penner (apenner) wrote :

thanks, that sounds like a good idea

Jabiertxof (jabiertxof) wrote :

You are welcome!

Jabiertxof (jabiertxof) wrote :

This patch fixes the problems related by Tavmjong in IRC. Also fixes the bug in the treee .inx extensions pointed by suv. Also tested a basic rollback to 90DPI

Jabiertxof (jabiertxof) wrote :

Forget add extensions. Thanks suv!

Jabiertxof (jabiertxof) wrote :

Added with extension to avoid download problems

su_v (suv-lp) wrote :

@Jabiertxof - in lp:inkscape (rev 15301) and lp:inkscape/0.92.x (rev 15241) does not scale any content which is placed within top-level container elements (most of the drawings created with Inkscape use layers, and thus have all graphics elements inside one or more container elements (<g>) in SVG root). With the current version of the extension, only graphics elements directly placed in SVG root are scaled (the conditional based on a number of element tags); groups and other container elements which may contain graphics elements ('a', 'switch' (?)) in SVG root are not considered.

AFAICT grids, guides and page area on the other hand are modified as expected.

Please review attached proposed changes - maybe we can discuss it on #inkscape-devel?

su_v (suv-lp) wrote :

@Jabiertxof - as mentioned on irc, I encountered a few issues with current The attached diff is a partial rewrite (work in progress):
1) Scaling objects with 'matrix()' transformations produced incorrect results - I decided to make use of the functions provided by instead of the custom method in DPISwitcher(). This simplifies composing transforms a lot.
2) Parsing SVG lengths from attributes now supports scientific notation (like the similar methods in
3) Page area of documents which have different units for <svg>'s width, height attributes (e.g. share/examples/text-on-path.svg) was incorrectly resized (fixed).
4) There is now basic support for text-on-path and <use> instances in SVG root (as siblings) to make sure scaling is not applied "twice" to instanciated elements.

Maybe you could test the diff [*], and we discuss details on irc?

[*] For text-put-on-path, you could test with Inkscape's own examples (share/examples/text-on-path.svg and share/examples/i18n.svg ).

LucaDC (dicappello) wrote :

I managed to try the conversion with some of my older documents and for what I've seen it's producing useful results.
First of all, there is a warning dialog offering to make a backup copy which IMHO is enough to prevent any loss of data.

I've had an issue with a couple of files with regard to not being able to set the document's unit different than px. I presume it's related to some broken file format created with development versions; I attach a sample if someone wants to take a look. The problem is that when opening this file I cannot change the ratio between the view box and the page size. Anyway, this is not related to the conversion process AFAIU. This file contains a 1 mm thick square of 10 mm x 10 mm placed at 10mm x 10 mm from the top left corner of an A4 landscape page.

I've tried select-all and copy-paste-in-place from the converted files to new fresh files and everything worked correctly. So if the converted documents show some weirdnesses (like in the attached example) it's still possible (even if maybe laborious) to transfer everything to a new document.

I still haven't found any particular issues in conversions of documents of mine made with more recent versions than the attached one.

I prefer not to say anything about the two different methods because I didn't dig inside the converted files enough to spot their weaknesses. I've just checked that the known dimensions were correct after the conversion and with regards to this point both behaved correctly.

Many thanks to Jabiertxof and Tav for all the efforts put into solving this!

LucaDC (dicappello) wrote :
Tavmjong Bah (tavmjong-free) wrote :

I've just checked into trunk internal code to do scaling. This would be a replacement for dpiswitcher (for 90->96). Please test!

Advantages of Internal code:

 * The additional code is only about 12 lines long (duplicated two places).
 * It relies on Inkscape's 'ungroup' function which is well tested and handles text-on-path and clones correctly.


  * Can't be easily updated by user.

I've also added code to handle 3d boxes. This code is also needed for handling legacy files that are not scaled. There is one small problem, the boxes are not updated on the screen until they are selected by the 3D box tool. I don't know how to fix this at the moment. (Any ideas?)

I've also updated many of my test files to include clones (and clones of clones), text-on-a-path, and clipping. The update files can be found at:

The internal scaling routine doesn't handle correctly the rectangle in the test files that is defined using percentage width/height. As Inkscape never creates shapes with percentage lengths this should not be a problem.

Tavmjong Bah (tavmjong-free) wrote :

@LucaDC The problem with not being able to set document units effects all files it seems.

Bryce Harrington (bryce) wrote :

I verified the dialog is displayed and appears to do its thing. Is there any further work that must be done for the 0.92.0 release?

I understand that a better fix might be available later, but perhaps that work can target 0.92.1?

su_v (suv-lp) wrote :

JFTR - an update for the current version of the dpiswitcher extension (as follow-up to comments 94-96) is maintained at (partial rewrite with too many changes to be considered so late in the release cycle).

zoqaeski (zoqaeski) wrote :

I'm not sure if it's this bug or, but some combination of the two managed to irreversably blow up a couple of my drawings. Even the backup copies displays artifacts, so I'm hestitant to open anything else I've created over the years. I've attached a screenshot of the aftermath. Can anyone involved suggest anything I could do to avoid having to realign every clone manually?

I'm using 0.92.0 on x86-64 Arch Linux, and haven't been following development as usually Inkscape has been reliable with no nasty surprises until now.

Jabiertxof (jabiertxof) on 2017-01-15
Changed in inkscape:
status: Triaged → Fix Released
Displaying first 40 and last 40 comments. View all 103 comments or add a comment.