3 ms·

This would be a lot more useful if the person writing the blog hadn't copied release notes in one character set into their blog entry in another character set.

This would be a lot more useful if the person writing the blog hadn't copied release notes in one character set into their blog entry in another character set. Tons and tons and tons of borked characters which make it very difficult to actually read what's going on.

teddyh 13y ago
He also did not escape angle brackets, so for instance “typing <left>, <right>, <S-left>, and <S-right> adjusts” from the original becomes “typing , , , and adjusts” in the text.
- mickeyp 13y ago
  I've fixed this now.
mickeyp 13y ago
I'm not seeing the character set issue at all. Both Wordpress and Emacs are set to UTF-8.
- ubernostrum 13y ago
  Here's an imgur album: http://imgur.com/a/ehla9 http://imgur.com/a/ehla9 Despite your comment saying you've fixed it, I'm still seeing this in Firefox, Chrome and Safari (OS X). No amount of fiddling with character sets client-side seems to fix it. Lot of it seems to be punctuation and ligature characters getting borked. Some still seems to be escaping issues. Some I don't even know.
  - deleted 13y ago
    [deleted]
  - mickeyp 13y ago
    Sounds like a font or machine issue? I've never had any reports, ever, about this issue and my blog has been around for three years. I also tested it on my Android phone and it looks as fine as it ever does. In SCreenshot #1 where the two odd chracters appear around "indent-rigidly" - those characters are normal parentheses. Here is what Emacs reports the opening character to be: position: 13888 of 66844 (21%), column: 37 character: ( (displayed as () (codepoint 40, #o50, #x28) preferred charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x28 script: latin syntax: () which means: open, matches ) category: .:Base, <:Not at eol, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME" buffer code: #x28 file code: #x28 (encoded by coding system utf-8-unix) display: by this font (glyph code) xft:-microsoft-Consolas-normal-normal-normal-*-19-*-*-*-m-0-iso10646-1 (#x17F) Character code properties: customize what to show name: LEFT PARENTHESIS old-name: OPENING PARENTHESIS general-category: Ps (Punctuation, Open) decomposition: (40) ('(') There is an overlay here: From 13888 to 13889 face show-paren-match priority 1000
    - ubernostrum 13y ago
      Very odd. Seems like I might have a corrupt italic Constantia. Disabling the italic variants (forcing fake-italic rendering) immediately fixed this.
      - mickeyp 13y ago
        Strange indeed. Mystery solved though. Thanks for the screenshots - they helped debug it!
  - mickeyp 13y ago
    Oh, and what I fixed were the missing angle brackets.
dredmorbius 13y ago
ProTip: the iconv utility (part of flinch, so yes, it's installed on Linux / Mac) is quite helpful for fixing this. Fixing linewrap issues would also be useful.

teddyh 13y ago

He also did not escape angle brackets, so for instance “typing <left>, <right>, <S-left>, and <S-right> adjusts” from the original becomes “typing , , , and adjusts” in the text.

mickeyp 13y ago
I've fixed this now.

mickeyp 13y ago

I'm not seeing the character set issue at all. Both Wordpress and Emacs are set to UTF-8.

ubernostrum 13y ago
Here's an imgur album: http://imgur.com/a/ehla9 http://imgur.com/a/ehla9 Despite your comment saying you've fixed it, I'm still seeing this in Firefox, Chrome and Safari (OS X). No amount of fiddling with character sets client-side seems to fix it. Lot of it seems to be punctuation and ligature characters getting borked. Some still seems to be escaping issues. Some I don't even know.
- deleted 13y ago
  [deleted]
- mickeyp 13y ago
  Sounds like a font or machine issue? I've never had any reports, ever, about this issue and my blog has been around for three years. I also tested it on my Android phone and it looks as fine as it ever does. In SCreenshot #1 where the two odd chracters appear around "indent-rigidly" - those characters are normal parentheses. Here is what Emacs reports the opening character to be: position: 13888 of 66844 (21%), column: 37 character: ( (displayed as () (codepoint 40, #o50, #x28) preferred charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x28 script: latin syntax: () which means: open, matches ) category: .:Base, <:Not at eol, a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME" buffer code: #x28 file code: #x28 (encoded by coding system utf-8-unix) display: by this font (glyph code) xft:-microsoft-Consolas-normal-normal-normal-*-19-*-*-*-m-0-iso10646-1 (#x17F) Character code properties: customize what to show name: LEFT PARENTHESIS old-name: OPENING PARENTHESIS general-category: Ps (Punctuation, Open) decomposition: (40) ('(') There is an overlay here: From 13888 to 13889 face show-paren-match priority 1000
  - ubernostrum 13y ago
    Very odd. Seems like I might have a corrupt italic Constantia. Disabling the italic variants (forcing fake-italic rendering) immediately fixed this.
    - mickeyp 13y ago
      Strange indeed. Mystery solved though. Thanks for the screenshots - they helped debug it!
- mickeyp 13y ago
  Oh, and what I fixed were the missing angle brackets.

dredmorbius 13y ago

ProTip: the iconv utility (part of flinch, so yes, it's installed on Linux / Mac) is quite helpful for fixing this. Fixing linewrap issues would also be useful.