After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744897 - Colons (":") are being changed into a colon-like character ("：")
Colons (":") are being changed into a colon-like character ("：")
Status: RESOLVED FIXED
Product: easytag
Classification: Other
Component: general
2.3.x
Other Linux
: Normal normal
: 2.2
Assigned To: EasyTAG maintainer(s)
EasyTAG maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-02-21 16:29 UTC by J.B. Nicholson
Modified: 2015-02-21 18:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description J.B. Nicholson 2015-02-21 16:29:47 UTC 
I've seen this behavior on EasyTAG 2.3.4 and 2.2.6. I don't think it matters which OS one uses, but I'm testing on GNU/Linux.

I have a FLAC file whose title contains the "：" character. In my current font this looks like a colon (":") but with more whitespace on the left and right sides of the glyph.

I tried renaming the title by manually substituting a colon for this colon-like character. EasyTAG would not let me do that; each time I clicked the button to set the new title (or clicked the set title button) EasyTAG would change the character back to being this colon-like character.

I don't understand why I can't use a real colon in the title tag of this FLAC file. I can't get this behavior to occur with the artist, album artist, or album tags. With these other tags the colon character works like any other character.
Comment 1 David King 2015-02-21 18:20:56 UTC 
It just so happens that I was writing a test for the buggy code that caused this behaviour while you filed this bug!

The problem is that when updating the internal representation of the tag from the UI fields, EasyTAG used g_utf8_collate() to compare the internal and UI strings for equality. This normalized the strings, so that the two colon characters (the fullwidth and regular colon) were treated identically, and the internal representation was not updated. The fix was to use g_utf8_normalize() with a mode of G_NORMALIZE_DEFAULT, to do only normalization which does not affect string content.

Fixed in master as 834b354f5ddf438ee58fa5824ea7b7849eb05e1e. I also updated and expanded the tests so that similar problems should be caught in the future.