Re: [O] double-width characters in tables
Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: Solving the problem then might mean just using `org-string-width' directly in the code, in the places where string width is currently calculated from text property values. I'll poke at it, and see how badly I break it. Thanks for digging further -- if you can find a bug that doesn't involve mixing languages (e.g. if users are inserting special but common characters?), that'd even better! -- Bastien
[O] double-width characters in tables
This problem has been flagged up before: http://orgmode.org/worg/org-issues.html#mid-87pqt04qg1-2Efsf-40gmail-2Ecom It's causing me headaches at the moment, so I'm trying to see if I can find a solution. The proximate cause of issues with double-width characters in table fields (they also mess with justification) is that the contents of the fields are propertized with a length based on `length', and not `string-width'. So you get this: #(《蛙》 0 3 (fontified t line-prefix #( 0 4 (face org-indent)) wrap-prefix #( 0 4 (face org-indent)) face org-table)) 3 is the number of characters in the string, but it takes up 6 columns of screen width. That messes up justification. I can't for the life of me figure out where that number is getting added to the string! I tried changing `length' to `string-width' in all manner of org functions, such as `org-add-props', but could never get that number changed during the fontification of the org tables. I wouldn't be surprised if this is something outside of org, or if fixing it would lead to more troubles, but does anyone have any ideas about this? Fixable, or not? Thanks! Eric
Re: [O] double-width characters in tables
File a bug report - M-x report-emacs-bug RET - against Orgmode. I am sure something useful will come out of it, eventually. It is good to get eyes and mouths of emacs-devel-ers involved, for whatever it is worth. Believe me it is good, for the discussion and suggestions it will open up. Eric Abrahamsen e...@ericabrahamsen.net writes: This problem has been flagged up before: http://orgmode.org/worg/org-issues.html#mid-87pqt04qg1-2Efsf-40gmail-2Ecom It's causing me headaches at the moment, so I'm trying to see if I can find a solution. The proximate cause of issues with double-width characters in table fields (they also mess with justification) is that the contents of the fields are propertized with a length based on `length', and not `string-width'. So you get this: #(《蛙》 0 3 (fontified t line-prefix #( 0 4 (face org-indent)) wrap-prefix #( 0 4 (face org-indent)) face org-table)) 3 is the number of characters in the string, but it takes up 6 columns of screen width. That messes up justification. I can't for the life of me figure out where that number is getting added to the string! I tried changing `length' to `string-width' in all manner of org functions, such as `org-add-props', but could never get that number changed during the fontification of the org tables. I wouldn't be surprised if this is something outside of org, or if fixing it would lead to more troubles, but does anyone have any ideas about this? Fixable, or not? Thanks! Eric --
Re: [O] double-width characters in tables
Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: This problem has been flagged up before: http://orgmode.org/worg/org-issues.html#mid-87pqt04qg1-2Efsf-40gmail-2Ecom It's causing me headaches at the moment, so I'm trying to see if I can find a solution. The problem for me here is that even if (string-width 《蛙》) returns 6, it is not visually equivalent to 6 characters. Is it for you? If not, let's report this to Emacs... PS: Btw (org-string-width 《蛙》) returns the correct value. -- Bastien
Re: [O] double-width characters in tables
Jambunathan K kjambunat...@gmail.com writes: File a bug report - M-x report-emacs-bug RET - against Orgmode. If users believe this is a bug in Org-mode, they should send the bug report to the Orgmode list. If they believe this is a bug in Emacs, they should discuss it to emacs-devel. Please help me in letting people know about this policy. -- Bastien
Re: [O] double-width characters in tables
Bastien b...@altern.org writes: Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: This problem has been flagged up before: http://orgmode.org/worg/org-issues.html#mid-87pqt04qg1-2Efsf-40gmail-2Ecom It's causing me headaches at the moment, so I'm trying to see if I can find a solution. The problem for me here is that even if (string-width 《蛙》) returns 6, it is not visually equivalent to 6 characters. Is it for you? If not, let's report this to Emacs... PS: Btw (org-string-width 《蛙》) returns the correct value. Yes, org-string-width eventually calls string-width, so that behaves correctly as far as it goes, but unfortunately that's not where the value in the text properties comes from... 《蛙》 123456 Doesn't that line up for you? Those bracket characters come with their own whitespace, maybe this is clearer: 正能量 123456 One Chinese character should definitely take up two screen columns. I'd love to file a bug report but I honestly don't know where this comes from. If it's not org-add-props or relatives, what emacs function is responsible? Thanks for the swift responses! Eric
Re: [O] double-width characters in tables
Eric Abrahamsen e...@ericabrahamsen.net wrote: 《蛙》 123456 Doesn't that line up for you? Those bracket characters come with their own whitespace, maybe this is clearer: 正能量 123456 I use a fixed-width font in my emacs and those two do not line up for me (the Chinese chars reach to about the middle of the 5). One Chinese character should definitely take up two screen columns. It does not seem to, in my case. Nick PS. In case it matters, I have this in my .emacs: (set-default-font -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1)
Re: [O] double-width characters in tables
Eric Abrahamsen writes: Yes, org-string-width eventually calls string-width, so that behaves correctly as far as it goes, but unfortunately that's not where the value in the text properties comes from... 《蛙》 123456 Doesn't that line up for you? Those bracket characters come with their own whitespace, maybe this is clearer: 正能量 123456 One Chinese character should definitely take up two screen columns. That's a function of the font that is ultimately used and their run-length. Since you are unlikely to use a font that has _all_ those glyphs, eventually the ones that are missing in your specified font will be replaced with the glyph corresponding to the same codepoint in a different font if it exists or possibly a composition of multiple glyphs (if not you'll get a placeholder). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] double-width characters in tables
Achim Gratz strom...@nexgo.de writes: Eric Abrahamsen writes: Yes, org-string-width eventually calls string-width, so that behaves correctly as far as it goes, but unfortunately that's not where the value in the text properties comes from... 《蛙》 123456 Doesn't that line up for you? Those bracket characters come with their own whitespace, maybe this is clearer: 正能量 123456 One Chinese character should definitely take up two screen columns. That's a function of the font that is ultimately used and their run-length. Since you are unlikely to use a font that has _all_ those glyphs, eventually the ones that are missing in your specified font will be replaced with the glyph corresponding to the same codepoint in a different font if it exists or possibly a composition of multiple glyphs (if not you'll get a placeholder). Thanks for all the responses here! Obviously the question is more complicated than I thought. Chinese fonts are fixed-width by default, so I assumed things would line up with a fixed-width latin font, though clearly I wasn't thinking hard enough about typefaces and their different widths/sizes. It's obvious from the screenshots that everyone's got a little something different going on. Takaaki's unicode WHITE CIRCLE is weird -- it's classified as CJK, but Chinese characters are usually named CJK IDEOGRAPH BLAH, and this isn't. It's displayed using a Chinese font on my machine, making it double-width, but sure enough `string-width' returns 1. I actually have the same problem with EM DASH here -- Inconsolata doesn't have that glyph, so a Chinese font is substituted, and I get a double-width character that reports its width as 1. Anyhoo... I still think the original problem is valid: strings in table fields should be measured with `string-width', not `length'. It might not be perfect, but surely it would be better than the present situation? On second thought I don't think it's a problem with text properties. (add-text-properties 0 6 '() 正能量) gives an Args out of range error, and it probably should, since all it cares about is the number of characters in the string. Solving the problem then might mean just using `org-string-width' directly in the code, in the places where string width is currently calculated from text property values. I'll poke at it, and see how badly I break it. Thanks again, Eric
