I am using Extensions > Render >Grid, and it is not working as expected. I am drawing a rectangle and then attempting to fill it with a grid, but the grid is below the top of the rectangle even though no offset has been specified (see attached image). I searched and saw a different issue that was resolved by unchecking "allow relative values" in Inkscape preferences, but this has no effect for me.

The first time I used it, it worked fine, but afterwards it is not in the right place, although in the xml it looks like it should be (it begins M 12 12, as does the rectangle, but it is not in the right place).

I am guessing, since it worked right once, that it is storing something somewhere that is throwing it off. I am using the 0.48 version of Inkscape portable.

Thanks!

Well here's my result:


It's been my experience that extension results are almost never displayed on the screen. Sometimes they are, but I haven't figured out what I might have done to cause them to be drawn on the screen. Most of the time I have to scroll around to find them, almost always outside the top of the screen, and then move them back to where I'm working. For a long time after I first started learning Inkscape, I thought most of the extensions were broken and didn't work -- until I later found all the results when I accidentally scrolled above the page border. In this case, I'm just happy the result is visible on the screen .

I guess it's a bug, but I'm not sure. I quickly searched Launchpad but didn't see anything about it. Maybe it should be reported? It certainly has been annoying me forever ~suv, what do you think?

Maybe in this case, where the extension is supposed to fill a shape, it's more of a bug than with most other extensions, which are more "free standing"? And actually I think the grid extension doesn't need a shape to fill. I think I've tried it without anything selected, and it draws a huge grid, which sometimes crashes Inkscape, if I recall

(I''m on Windows.)

So I was curious about another attribute that was popping up, and serendipitously solved this problem!

There is a "transform" attribute that will often have a value like translate(x,y). Now, if you resize the page at any time, it adds a tranform - translate to the svg:g element. This will throw many many things in Inkscape off, including a ton of extensions. It is a known bug, but there is nobody working on it (it has been known for years).

The fix is simple. Do not resize your page! If you must, do it on the blank canvas at the beginning, delete this transform attribute, and everything will work.

No, this happens to me on brand now documents, before I do anything else at all. That might indeed solve your problem. But it doesn't solve the overall issue with extensions. In fact in my screenshot, I did that in a brand new doc without any transforms at all.

What you found is indeed a well known, and universally annoying bug! It has confounded me on many occasions. But I'm not sure that the problem with extensions being drawn off the screen is related.

Unless that transform attribute is present in custom default templates? For example, I have a custom default doc, which is the A4 size, but in landscape orientation and 100% zoom. If that creates a transform attribute in all of my docs, well then that might explain it.

I do see a transform attribute in <svg:g id="layer 1" inkscape:label="Layer 1"> and I didn't do anything to put it there. So it must have come from the custom default doc. So if I delete that from the custom template, will it remove just the attribute, or will it remove my landscape orientation?

Edit
But it seems to me like that extension problem where they're drawn off screen seems like it has been happening to me since day 1. But it was a couple to three years more before I learned how to make the custom default doc. I could be wrong. But I'd definitely be interested to know if the extension drawing off screen is related to that transform bug. (Sorry ~suv, I don't know the bug number off the top of my head -- it's the one that e.g. causes radially tiled clones to be sprayed in a giant spiral if the layer has a transform attribute.)

The transform is there for one reason only, as far as I understand: to move anything already in the doc. However, it does not work as expected, and moves all kinds of stuff. So, yes, you should be able to delete it, and it will have no effect unless there are already elements on the canvas. If so, they will need to be moved by whatever values it contains.

If you have a transform, it is messing you up. Guaranteed.

If I have understood correctly, I think the solution to that bug is actually fairly trivial. Inkscape should not add a global transform, but, like with tiled clones, calculate all necessary transforms for current elements, and transform them, and them alone, directly and one time only.

Well I should say, if you haven't already perceived, that I don't have much of a technical grasp of Inkscape, SVG or XML. But I'm sure ~suv (our resident bug expert) will have some comments, and correct what I may have said or understood incorrectly....as well as correctly diagnose your problem, if I've missed the mark.

I don't think it's a trival bug, because it's been around for the last couple of stable version releases. ~suv is usually not absent from the forum for more than a day or 2. But I'll try to find that bug report for you. I'll post a link as soon as I find it

I'll also try deleting that transform attribute from my custom default doc, and see what happens. But now as I think about it, I haven't run into this bug that I'm talking about while using my custom default doc. It only happens if I change the page orientation or size after I've started working. If I need to change the page size, I wait until I'm finished working. Anyway, I'll try and see what happens.

EtchnSketch wrote:If I have understood correctly, I think the solution to that bug is actually fairly trivial. Inkscape should not add a global transform, but, like with tiled clones, calculate all necessary transforms for current elements, and transform them, and them alone, directly and one time only.

No. Avoiding an issue might be a "trivial" solution from your point of view. Instead, the underlying issue (properly handle parent transforms) needs to be addressed in the first place - unless you propose to flatten _all_ transforms for everything in Inskcape (IMHO a bad idea).

All these issues when working in resized documents (size or orientation) can be reproduced when working inside transformed groups, which are legit objects in any SVG file. They are not bound or limited to layers (groups with a special inkscape attribute).

EtchnSketch wrote:The fix is simple. Do not resize your page! If you must, do it on the blank canvas at the beginning, delete this transform attribute, and everything will work.

Simple fix when working in resized documents: add a new layer, and work on the new layer (it will not have the 'transform' attribute until you resize the document again).

Well, I tried a quick reply and lost it.

Anyway, now that ~suv has also posted, I see that there are more issues involved, and it makes sense to not treat things symptomatically - even if this symptom is probably the primary one people will run into. I am also sorry if I came across as ungrateful, I should have placed "If I understand correctly" in italics to show that I was simply speculating. At any rate, at least this is documented here in relation to grids and other extensions, so that people can find a temporary solution.

EtchnSketch wrote:At any rate, at least this is documented here in relation to grids and other extensions, so that people can find a temporary solution.

I probably should have filed a new report instead of adding this comment in Bug #401567 “Render>Grid doesn't render the horizontal lines properly”:

Code: Select all

~suv wrote on 2010-04-22:

fix in parts confirmed with Inkscape 0.47+devel r9361 (OS X 10.5.8)

Quick test: the bug as originally filed is fixed. However - as many other items - the extension doesn't deal with a resized/format-changed page: the calculated grid is inserted offset from the bounding box of the selected object - or from the current page margins (if no object is selected).

more generally: the extension misplaces the grid if the selected object/inserted grid is inside a transformed group.


Tip: consider using the 'Construct Grid' LPE (live path effect) instead of the (static) extension 'Render > Grid…' - the path effect is not negatively affected by transforms on parent groups.

In addition to being an expert on Inkscape bugs and code, she's also psychic, and magically appears whenever I post a message with her name in it!


EtchnSkectch, I couldn't find that bug, but trust ~suv has answered your questions

brynn wrote:(Sorry ~suv, I don't know the bug number off the top of my head -- it's the one that e.g. causes radially tiled clones to be sprayed in a giant spiral if the layer has a transform attribute.)

That's bug #168651 “"Tiled Clones" inside transformed groups broken”. The trigger is the same ('transform' attribute on a parent group (or layer, after changing the page size or orientation)), but that specific report is about (tiled) clones which not always properly compensate such parent transforms. There are also known similar issues with masks and clippings (can be displaced if mask or clip-path is taken from a transformed layer), with clones, connectors, linked offsets, text put-on-path, … (when ungrouping such transformed groups), and with extensions (see below). Each of the issue need to be addressed separately, though.

Some extensions have been fixed (for Inkscape 0.49), e.g.
Bug #663667 “Extension 'Modify Path->Envelope' fails inside transformed groups”
Bug #253296 “Perspective effect wrong when drawing size changed”
Bug #168942 “perspective extension fails on group with transforms”

~suv wrote:I probably should have filed a new report instead of adding this comment in Bug #401567 “Render>Grid doesn't render the horizontal lines properly”:

Done -> Bug #892694 “Grid extension incorrectly handles transforms of parent group”

Thanks ~suv.
I should start keeping a list of links to bugs that I discuss on the forum, so that I can quickly find them again.

So all the many various issues with the transform attribute -- are they all separate bugs with separate causes and separate resolutions? I thought that there were several issues with the "transform attribute in a parent layer". And I guess I had the impression that the transform attribute had been incorrectly added or assigned or written to the parent layer. Is that not the case (in as simple or general terms as possible please)?

brynn wrote:So all the many various issues with the transform attribute -- are they all separate bugs with separate causes and separate resolutions?

They might share a similar or the same trigger (the transforms of (nested) parent group(s) are not properly handled in all operations), but most need to be addressed in different parts of the code.

brynn wrote:I thought that there were several issues with the "transform attribute in a parent layer".

There are, and I did mention some in my earlier comment. But the same issues occur when you have one or more transformed groups and work e.g. inside one of them (see below for a simple example in Inkscape) - they are not limited to layers.

I'm not sure if I really understand what you are aiming at with your questions here. Since English isn't my native language, maybe I miss the subtleties: Aren't «many various issues with the transform attribute» and «several issues with the "transform attribute in a parent layer"» the same, or are you asking whether the second set of issues is a subgroup of the first set?

brynn wrote: And I guess I had the impression that the transform attribute had been incorrectly added or assigned or written to the parent layer. Is that not the case (in as simple or general terms as possible please)?

No, it is not a bug that layer groups can have a 'transform' attribute. A 'transform' attribute on a group (be it a group which acts as layer in Inkscape, or an ordinary group you create with 'Ctrl+G') is perfectly legit and valid SVG. But it can get quickly quite complex to properly handle (internally, code-wise) - depending on the type of object(s) involved, the actions executed on them, etc.

To understand why it is not limited / bound to layers: here are steps how to reproduce the same problem (in this case with the 'Grid' extension) when working inside a transformed (e.g. moved) group:

• open a new document based on the original default template shipping with Inkscape
• draw two rectangles, some distance apart
• group them
• move the group with the select tool to the side (or up, or down)
• enter the moved group (use the context menu entry, or double-click it, or type the keyboard shortcut 'Ctrl+Enter')
• select one of the rectangles and apply 'Extensions > Render > Grid…'

-> same "failure": the grid is not inserted on top of the rectangle as expected, but displaced - offset - from the position of the rectangle.

sample SVG file:

I'm not sure if I really understand what you are aiming at with your questions here. Since English isn't my native language, maybe I miss the subtleties: Aren't «many various issues with the transform attribute» and «several issues with the "transform attribute in a parent layer"» the same, or are you asking whether the second set of issues is a subgroup of the first set?

You understood correctly. I just used different adjectives. After I used "many", I was a little worried you'd think I was exaggerating. I had the impression that some of the 'transform attribute' issues were related, so the 2nd time, I used "several". Actually you speak/write English very well. I'm surprised to learn you're not a native English speaker!

Yes, I understand now that the problems occur in regular groups and in layer groups. It actually clears up some confusion I had about the issue.

I thought that the problem was the transform attribute had been put into the layer (group) when it really should not have been put there (or maybe anywhere). So now, I think you're saying that it's not in the layer (group) erroneously, but that it's not working properly. Yes?

The transform attribute affects more than what it's supposed to affect? Right? And depending on what it erroneously affects and how, that's what determines how the bug is categorized?