Horizontal and vertical lines non-resizable from secondary toolbar if bbox mode is set to geometrical

[Vladimir Savic]

I'm talking about absolutely horizontal and vertical lines (at 0 and 90 degrees).
Problem displays with width and height, one of which should be non-existing for geometric bboxes, but says 0,0001, if I recall correctly. IMHO, It should be disabled completely because either W or H have no dimension geometrically, depending on line orientation.

[su_v (suv-lp)]

Related to or duplicate of Bug #452102 “Wrong value set when changing the size of a horizontal (or vertical) line”:

«Unfortunately in 'geometric' bounding box mode there is another bug: it is not possible to input values in the control W of the selector toolbar if the line has geometric h=0. [Steps to reproduce: 1) switch to geometric bounding box mode 2) draw horizontal line 3) click on selector 4) change value of W in the toolbar. Result: the value of W flips back to the old value and the line remains unchanged]» (comment #3)

[su_v (suv-lp)]

Present in latest stable (0.48.2) and latest trunk (r10539), tested on Mac OS X 10.5.8 (i386)

[Diederik van Lierop (mail-diedenrezi)]

Fixed as of rev. #10614

[su_v (suv-lp)]

@Diederik - many thanks for addressing this long-standing issue.

May I add another observation about using horizontal/vertical lines with geom bbox? [1]

Steps to reproduce (r10614):
0) geom bbox mode, stroke scaling off, grid visible
1) grid snapping on, cusp nodes snapping on
2) draw a straight line (diagonal, angle doesn't matter)
3) with the select tool, drag a transformation arrow at the bounding box corner to align (snap) the line horizontally

-> while dragging the bbox corner in the select tool context, the stroke gets scaled (known issue), to be reset when the mouse is released. In geom bbx mode, the line gets 'nan' as stroke width when snapping to the grid with the line getting horizontally or vertically aligned to one of the axes. The stroke width is not reset to the original width after the mouse button is released. Once that has happened, it is difficult to further edit it without manually resetting the stroke width (the line is no longer visible if not selected).

I also have seen the line disappear completely (d="M 0,0 0,0", stroke-width:nan) when transforming it (select tool) while snapping to the grid (with 'Snap only node nearest to the pointer' active), but have not been able to consistently reproduce it.

[1] Do you want me to file this separately?

[Diederik van Lierop (mail-diedenrezi)]

I will have a look; please allow me to revert the status to confirmed, to make sure it doesn't disappear from my radar.

[Diederik van Lierop (mail-diedenrezi)]

Well, it appears I cannot revert the status.

[Diederik van Lierop (mail-diedenrezi)]

@~suv: can you attach a sample file, and maybe also your preferences
file? I haven't been able to reproduce this, even after checking and
double checking the settings you mentioned

[su_v (suv-lp)]

… and the preferences file used (new, changes: geom bbox, stroke scaling and rect corner scaling off)

[Diederik van Lierop (mail-diedenrezi)]

Thanks, now I can reproduce this too.

My latest commit (#10621) allows you to change the strokewidth from NaN back to a more useful value.

The root cause is more difficult to fix though. To compensate for the change in strokewidth, it is being multiplied by the inverse of the scaling of the object. This will not work however when the scaling is zero or infinite, because you cannot ever recover from that by multiplying. I guess we should be able to restore the previous value directly (in SPItem::adjust_stroke or SPItem::doWriteTransform), but I have not yet figured out how.

[su_v (suv-lp)]

I complied r10621 with the same fix as described by Krzysztof on inkscape-devel [1], but I can see no real change for this issue (stroke width still reduced to nan and the line disappears after "scaling" it to a horizontally aligned line) - it's even "worse" because now the stroke width indicator/selector in the status bar is completely gone (see attached screenshot), whereas in r10620 one could at least reset the stroke width of the line quickly by choosing a value from the context menu of the style indicator in the status line. In r10621, I have to actually open Fill&Stroke (or use the XML Editor) to change the stroke width back to a visible width.

[1] <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37227/focus=37233>

[Diederik van Lierop (mail-diedenrezi)]

Hi ~suv, thanks for testing and reporting. So far I've only tried to
fix the stroke & fill dialog. I haven't looked yet at the context menu
and the status bar, but will see if these can be fixed too.

Will keep you posted!

[su_v (suv-lp)]

Diederik van Lierop wrote
> So far I've only tried to fix the stroke & fill dialog.

Oops - I didn't even noticed that 'nan' in the Fill&Stroke could not be changed to a numeric value ;)
(I only had used the style indicator in the status bar when testing for this issue, but I can reproduce the problem with the Fill&Stroke dialog now in older revisions, and it's fixed in r10621).

It's an old bug by the way (reproduced in 0.47 and 0.48.2, too), and not limited to the geometric bbox (my bad - I'll do a search now in case it was already reported earlier ;) ).

[Diederik van Lierop (mail-diedenrezi)]

Rev. #10624 should fix the root cause: the stroke-width will no longer scale to NaN, in the use-case you described.

I haven't looked at the behavior of the GUI controls, so these might still act up if somewhere in the code a 0 or NaN strokewidth is calculated.

[Diederik van Lierop (mail-diedenrezi)]

In rev. #10636 I had to partly revert this fix, because it had side effects (see lp:847437).

Apparently, this behaviour can only be fixed for lines, paths, rectangles, and text, because these type of items store the absolute strokewidth, i.e. without the strokewidth being dependent on the scaling. Other items, such as ellipses and stars, apply the transformation also to the strokewidth. This means that if scaling is zero in at least one dimension, then the stroke will also be scaled to zero. There is no easy way to overcome this fundamental problem.

[su_v (suv-lp)]

The changes in revision 10624 possibly trigger other unexpected results - see bug #959223, comments #9 and #10, about copy&pasting stroked paths and rectangles inside transformed (e.g. scaled) groups.

[Diederik van Lierop (mail-diedenrezi)]

Should have been fixed as of rev. #11186

[suresh (suresh-meetsme)]

Hi,

Along with the patch mentioned in https://bugs.launchpad.net/inkscape/+bug/190557, Here is another patch to resize horizontal line from toobox in desited width.

Horizontal line draw by using CTRL+Clik takes default value 0.001 which fall in 'bbox.hasZeroArea()' in sp-item-transform.cpp file. I set default value of h0 to 1px and applied scale matrix than move by default.

Here is the patch.

[jazzynico (jazzynico)]

@suresh - I'm not sure I fully understand what your patch does exactly. If it fixes a different issue, could you please create a different report? I'm afraid we're going to forget your patch if it stays linked to the current (closed!) one.