Open NerdsMaxx opened 2 years ago
I'll have to check, but I suspect that bug may be in one of the upstream libraries we use (Gtk or Pango are the most likely culprits). If that's the case, there's probably nothing we can do about it. Still, if you could run sticky from the terminal and post the output (if any). That might help pinpoint the issue. You can also check ~/.xession-errors
and see if there is anything that might be relevant.
@collinss No output from terminal.
@collinss xsession-errors: https://pastebin.com/s4YRn6ks The first occurrence of the word "sticky" is on the line 117.
I finally got a chance to test this out. (Please note that my keyboard doesn't have accented characters on it, so I had to use other methods.) It seems to work fine when I type it in (ctrl+shift+u, then the 4 digit code). If I try using the character map and copy the character in, it doesn't. I believe what's happening, is that copying in doesn't actually apply the formatting because subsequent characters also don't have that formatting applied.
Could you try highlighting the text and selecting the font scale from the menu?
I've tested this by using the composite key (in my case right-alt) and using i
+'
The effect is that the special characters will display in normal, while text on both sides will be the correct (larger) size.
The stored content for the notes.json file:
"#tag:larger:This text #tag:larger:\u00ed#tag:larger is big\n#tag:larger:This text is normal"
For whatever reason a special character is causing it to escape.
Edit: I'm wondering if the issue is relating to unicode and character length. If I try to insert the special character in the middle of an embiggened block of text then it will apply, so this issue only occurs at the end of the file.
I've logged out the size of the character, and according to do_insert_text, the length is incrementing by 2 for the í
character.
I'm wondering if the issue is relating to unicode and character length.
Hmm... I hadn't considered that. When handling inserted text, the only way to distinguish between typing on the keyboard, and copy-pasting (this needs different handling) is the number of characters, so I have it only try to extend the formatting if there's a single character being inserted (unfortunately gtk doesn't do this automatically). If it's getting stored in the buffer as more than one character, that could explain why it's not working. I'll have to play around with it a bit more and see. In the mean time, you should still be able to apply the formatting manually, it just may not work automatically if it's stored as more than one character in the buffer. I'll play with this a bit and see if that is indeed what is happening.
@collinss @NerdsMaxx This has been fixed: https://github.com/linuxmint/sticky/commit/3c62ce7f2f47105760ca20d3742c09a54d1605d5
Linux Mint 20.3 Beta Sticky 1.5
Accented letters are not the same size.