0
Not a bug

Unexpected font change with certain characters

burrum 12 years ago updated by Alex Jenter 12 years ago 0

Open this page and scroll a little to second top comment:


Image 10


Note: UserEcho resizes the image, open it in new tab or save to disk to view with original size and fidelity.


Select it and clip (Ctrl+F12), or copy-paste into new note. Notice how some portion of the text gets small.


Image 11


I first clipped from SRWare Iron 15 browser (Chromium core), and the small line was always last, no matter how many lines are displayed (with wrapping on):


Image 12


I then tried it in Opera 11.60, and its randomly first or second line. Sorry for not having time to find out the exact pattern now, but it's always only one line.


This also affects standard Windows Notepad.exe (Win7 SP1 x64). If export this note to plain text and open in notepad, small font also shows up. Obviously, clearing formatting has no effect.


I suppose there's some weird character causing this rendering and analyzing the exact content of the clipboard (as well as character codes in exported file) could help finding it. At the moment I have no handy tools to do it quickly.


Edit: paste this text into Notepad++ and notice the question mark '?' appearing at certain place.

viewing notes-list text-formatting

Answer

Answer
Not a bug
Thanks for the report!
This happens because of the U+FEFF character occurring in the middle of that string. Here is an exerpt from the Unicode FAQ:

Q: What should I do with U+FEFF in the middle of a file?
A: In the absence of a protocol supporting its use as a BOM and when not at the beginning of a text stream, U+FEFF should normally not occur. For backwards compatibility it should be treated as ZERO WIDTH NON-BREAKING SPACE (ZWNBSP), and is then part of the content of the file or string. The use of U+2060 WORD JOINER is strongly preferred over ZWNBSP for expressing word joining semantics since it cannot be confused with a BOM. When designing a markup language or data protocol, the use of U+FEFF can be restricted to that of Byte Order Mark. In that case, any U+FEFF occurring in the middle of a file can be treated as an unsupported character[AF]


As you see, this is really a rare and exceptional case and thus I consider fixing unnecessary at the moment. Just delete the offending character, and the font becomes normal.
Answer
Not a bug
Thanks for the report!
This happens because of the U+FEFF character occurring in the middle of that string. Here is an exerpt from the Unicode FAQ:

Q: What should I do with U+FEFF in the middle of a file?
A: In the absence of a protocol supporting its use as a BOM and when not at the beginning of a text stream, U+FEFF should normally not occur. For backwards compatibility it should be treated as ZERO WIDTH NON-BREAKING SPACE (ZWNBSP), and is then part of the content of the file or string. The use of U+2060 WORD JOINER is strongly preferred over ZWNBSP for expressing word joining semantics since it cannot be confused with a BOM. When designing a markup language or data protocol, the use of U+FEFF can be restricted to that of Byte Order Mark. In that case, any U+FEFF occurring in the middle of a file can be treated as an unsupported character[AF]


As you see, this is really a rare and exceptional case and thus I consider fixing unnecessary at the moment. Just delete the offending character, and the font becomes normal.