[scribus] Vertical align of text / aligning text with horizontal lines

[Timothy J Massey]

Gregory Pittman <gregp_ky at yahoo.com> wrote on 10/01/2009 11:23:15 AM:

> On 10/01/2009 11:10 AM, Timothy J Massey wrote:
> >
> > I don't know how old 1.3.3.2 is, but compared to 13 it seems pretty 
old...
> > :)
> > 
> Ancient.

Fair enough.  I've found a newer one.  The newest I can find is 1.3.3.12, 
which is hopefully not as ancient...  Sure *looks* better!  :)

It still shows a lot of weirdness in moving lines around.  I've been able 
to narrow down my issues more specifically:

1) When you draw a line for the first time, you can use the CTRL key to 
get it to draw "straight" lines.  However, adjusting a line after it's 
drawn does not obey the CTRL key anymore:  with CTRL down, you can easily 
(and frustratingly!) adjust lines with e.g. 1* angle instead of the 0* you 
really wanted.

2) When you draw a line initially, it doesn't seem to obey the "Snap to 
Guides".  The line starts where you click, and the end point won't snap to 
any kind of guideline, either.  However, when you *adjust* that same line, 
it *does* obey the "Snap to Guides"!

Actually, after playing with it more, it seems fairly random whether the 
preview will obey the "Snap To Guides" setting...  I can't yet figure out 
a logical pattern.

3) Imagine adjusting the right endpoint of a horizontal line.  Sometimes 
the "Snap to Guides" feature will cause the endpoint to stay put as you 
move your mouse to the right, which is fine:  it's snapping to a 
guideline.  Let's say that you move your mouse a couple of inches to the 
right past this guide.  Your mouse will continue to move to the right, but 
the endpoint won't.  Now, you start to move your mouse back to the left. 
The *instant* you start moving the mouse to the left, the *endpoint* 
moves, too, but now it's a couple of inches away from the mouse pointer! 
This is *really* frustrating:  you're trying to tell the computer where 
you want the endpoint to go, but the mouse pointer is now disembodied away 
from the endpoint!  The endpoint shouldn't start moving left until the 
mouse pointer moves left of the endpoint's current preview position.

This too doesn't seem to follow a logical pattern.  How "tightly" a 
guideline holds on to an endpoint seems to be controlled by how *fast* you 
move the mouse!  Move quickly past a guide and it will break free after, 
say, 1/3 of an inch.  But move slowly, and it'll hold onto a point even 
after I've moved the mouse 1.5" or more!  And once you do this, the 
endpoint is disembodied from the mouse pointer.  And to make things worse, 
it seems that where the final line goes has *no* real relationship with 
*either* the preview line, *nor* the point where your mouse pointer ends 
up.

4) There are many times where I grab an endpoint and try to adjust the 
line.  Instead of getting a dotted line drawn from the other endpoint, I 
get a dotted line that starts a couple of inches *below* the endpoint, and 
draws a line at the angle that it should draw if it were starting in the 
correct location (i.e. parallel to the correct line, but vertically 
shifted from where it should be).  Once again, I'm left trying to gauge 
what adjustment I'm making from a line completely disembodied from the 
mouse pointer--and in this case, completely disembodied from the rest of 
the page!

5) When adjusting the endpoint of a line from one side of a guideline to 
another, the dotted preview line will snap to a guideline, and then 
release.  But when you let go of the endpoint, the endpoint of the 
permanent line *does* snap to the guideline that you broke free from while 
previewing.  This is not unique to lines:  I've had the same thing when 
adjusting text frames.  This is very annoying, and inconsistent:  the 
preview, after all, does snap to guidelines.  Why does the 
line/frame/whatever follow *different* rules in relation to the guideline 
when compared to the preview?  Why doesn't it just go where the preview 
line should tell it go go?  :)

6) This is unrelated, but it seems that guidelines are *very* greedy.  You 
have to move in the neighborhood of half an inch (!) before the item will 
break free from a guideline.  And guidelines do not share well.  If you 
have two guidelines relatively close to each other, it is darn near 
impossible to get it to snap to the *far* guideline.  In other words, if 
you have an endpoint that's to the left of a pair of vertical guidelines 
that are (e.g.) 0.1" apart and try to move it to the right, it will snap 
to the left guideline.  By the time you break free of the left guideline, 
you are right of *both* guidelines, and it will never stick to the right 
guideline.  First of all, it would be helpful if you didn't have to move 
so *very* far to break free from a guideline.  (This is not a tool to help 
those with poor motor control:  you should be able to count on the user to 
get pretty close to a guideline if they really want to snap something 
there...)  But the other part would be to check to see if there are any 
guidelines *between* the one you're breaking free of, and the point where 
the mouse pointer is, and if there are, stick to them.  You might even 
want to have the snapping logic snap to the far guideline *before* the 
user has gone so far as to break free of the near guideline, based on some 
sort of closer/farther weighting...


These are just what I found after about an hour of trying to determine why 
lines don't work properly.  Am I doing something wrong?  Do I have a 
version that's working substantially different from everyone else's?  Or 
is this consistent with others' behavior?

Tim Massey