Re: [O] double-width characters in tables
Hi Eric, Eric Abrahamsen 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
Re: [O] double-width characters in tables
Achim Gratz 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
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
Eric Abrahamsen 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
Bastien writes: > Hi Eric, > > Eric Abrahamsen 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
Jambunathan K 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
Hi Eric, Eric Abrahamsen 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
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 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
>
>
>
--
[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
