whitespace-only spans must be merged

Bug #166680 reported by Buliabyak-users
2
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Low
Richard Hughes

Bug Description

1. Create a flowtext, type something to get 2 lines.
Open fill&stroke, select any fragment of text less than
the entire flowtext and paint it red - it works. But
then select the entire flowtext from start to end and
try to paint it - it does not work, color is reset
back. (Although you can still paint it as an object if
selected by selector.)

2. Now select each line separately (Home, Shift+End)
and paint it red. Now when cursor is at the end of the
first line, the displayed color is black - i.e. the
newline is "black". So when you select part of the
first line and part of the second line, you get an
average color because the "black" newline dirts it. As
I wrote you, any whitespace must be disregarded when
figuring out the selection style. Similarly, when
cursor is at the end of flowtext, the displayed paint
is undefined instead of red.

Tags: text
Revision history for this message
Richard Hughes (cyreve) wrote :

I'm not sure I agree with you about excluding whitespace from
inclusion. Let's be clear here that the whitespace in your
example is a normal space character, not a line break
character. Line breaks are currently excluded from style.

My argument is that if you move the cursor after the space
and type you will get black text, which is what I would expect
as a user (consider the case where you had deleted a whole
load of black characters until only the space was left, then
inserted some new characters). Thus that blackness is real
and is part of the user-visible editing interface and should not
be glossed over in any way.

The other points are all fixed now.

Revision history for this message
Buliabyak-users (buliabyak-users) wrote :

I disagree. Even if I just deleted black text, I deleted all
VISIBLE black text and therefore I cannot logically expect
blackness to be retained anywhere. I could not count on the
space preserving the black because I could not be sure that
it's "black" to start with - I can't easily see its color.
So, if I want to replace text but retain its style, I will
do it in such a way as to always retain some visible black
characters. And in all other situations the hidden black
space is even worse - after some time I will have no idea
where this blackness comes from. I see two red lines and I
type to get red, but I get black - why? It comes as a
surprise of a bad sort.

Once again I refer to my Xara experience. Xara has the
problem of retaining "unvisible style" not only in spaces,
but often also in some zero-length spans that tend to linger
in the text after styled characters are deleted. It's very
very annoying because I simply cannot predict the style of
the text I type into an existing text object. I would really
like to avoid this annoyance in Inkscape.

Revision history for this message
Buliabyak-users (buliabyak-users) wrote :

Well, now I realize that for this, you need to not only not
show whitespace-only style but to actually suppress them
merging with the neighboring spans with visible glyphs. If
there's an easy way to do this, please do; otherwise it can
wait until after the release.

Revision history for this message
Richard Hughes (cyreve) wrote :

Yeah, it wouldn't be a very big patch to do that when setting
style. Deleting text uses a different bit of code which really
ought to be converted over at some point, but that's a little
dangerous this close to release.

Do you think the space should inherit the style of the left hand
side or the right hand side?

Revision history for this message
Buliabyak-users (buliabyak-users) wrote :

I think inheriting from the right is more logical when you
delete text.

su_v (suv-lp)
tags: added: text
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.