[Webkit-unassigned] [Bug 27523] Don't convert soft hyphens in selections into spaces

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=27523





--- Comment #7 from Peter Arrenbrecht <peter.arrenbrecht+webkit at gmail.com>  2009-07-22 23:47:54 PDT ---
Adam,

> Substituting spaces for ­ is clearly wrong, which is why I got rid of it.

Agreed.

> However, there's no way that we should keep the ­'s when not rendered and
> omit them when rendered as you suggest.

That is not what I meant to suggest. I suggest keeping _all_ ­'s as 0xad,
as Firefox does, irrespective of whether they are rendered or not.

> Also, I can't replicate this behaviour
> in Firefox - it copies ­'s, rendered or not, for me.

I'm on Ubuntu Jaunty. When I copy in Firefox and then do

$ xclip -o -selection clipboard | hexdump -C

I get the all the ­ chars as 0xad. If I paste into gedit and turn line
wrapping on there, when I resize the width of gedit, it clearly breaks the long
words at the 0xad locations (although without adding a hyphen).

Referring again to http://recoveringphysicist.com/11/soft-hyphens, if I copy
the last two words of the demo paragraph in Firefox and hexdump, I get:

00000000  75 6e ad 70 72 65 ad 6d  65 64 69 ad 74 61 74 65  |un.pre.medi.tate|
00000010  64 20 75 6e 69 ad 6c 61  74 65 72 ad 61 6c        |d uni.later.al|

Although if I paste this into a terminal, the 0xad's are rendered as spaces.
Also if I paste into vim. So it's not entirely clear to me that what Firefox
does really is desirable.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.