* bug#23292: 24.5; Combining characters do not reliably combine @ 2016-04-14 19:26 Honore Doktorr 2016-04-14 19:50 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Honore Doktorr @ 2016-04-14 19:26 UTC (permalink / raw) To: 23292 Combining characters often do not render combined in emacs 24.5. For example, the combining short solidus overlay (0x337, o̷) appears following the character it's meant to combine with---although they are both highlighted together and so forth. cf. https://i.imgsafe.org/8369941.jpeg for a visual reference. This seems similar to bug 17261, but both characters are from the same font, DejaVu Sans Mono. describe-char for the combined (but separately rendered) o̷: --------------------------------------------------------------------------- position: 14 of 70 (19%), column: 12 character: o (displayed as o) (codepoint 111, #o157, #x6f) preferred charset: ascii (ASCII (ISO646 IRV)) code point in charset: 0x6F script: latin syntax: w which means: word category: .:Base, L:Left-to-right (strong), a:ASCII, l:Latin, r:Roman to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME" buffer code: #x6F file code: #x6F (encoded by coding system utf-8) display: composed to form "o̷" (see below) Composed with the following character(s) "̷" using this font: xft:-PfEd-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 by these glyphs: [0 1 111 82 8 1 7 7 0 nil] [0 1 823 703 8 0 8 8 1 nil] Character code properties: customize what to show name: LATIN SMALL LETTER O general-category: Ll (Letter, Lowercase) decomposition: (111) ('o') --------------------------------------------------------------------------- describe-char for the combining short solidus overlay by itself: --------------------------------------------------------------------------- position: 619 of 1008 (61%), column: 42 character: ̷ (displayed as ̷) (codepoint 823, #o1467, #x337) preferred charset: unicode-bmp (Unicode Basic Multilingual Plane (U+0000..U+FFFF)) code point in charset: 0x0337 script: latin syntax: w which means: word category: ^:Combining to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME" buffer code: #xCC #xB7 file code: #xCC #xB7 (encoded by coding system utf-8) display: composed to form "̷" (see below) Composed by the rule: (TAB ?̷ TAB) The component character(s) are displayed by these fonts (glyph codes): ̷: xft:-PfEd-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 (#x2BF) See the variable `reference-point-alist' for the meaning of the rule. Character code properties: customize what to show name: COMBINING SHORT SOLIDUS OVERLAY old-name: NON-SPACING SHORT SLASH OVERLAY general-category: Mn (Mark, Nonspacing) decomposition: (823) ('̷') There are text properties here: composition [Show] --------------------------------------------------------------------------- In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.18.7) of 2016-02-03 on buildhw-05.phx2.fedoraproject.org Windowing system distributor `Fedora Project', version 11.0.11803000 System Description: Fedora release 23 (Twenty Three) Configured using: `configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3 --with-gpm=no build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro' Important settings: value of $LANG: en_US.utf8 value of $XMODIFIERS: @im=none locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: show-paren-mode: t delete-selection-mode: t display-time-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t temp-buffer-resize-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent messages: Mark set [2 times] Type "q" to restore previous buffer, M-x scroll-up to scroll help. byte-code: End of buffer <mouse-6> is undefined byte-code: Beginning of buffer [4 times] Quit <<< Type SPC or RET to bury the buffer list >>> byte-code: Beginning of buffer [2 times] Load-path shadows: /home/denis/.emacs.d/elpa/js2-mode-20141118/js2-mode hides /home/denis/lib/site-lisp/…aside/js2-mode ~/lib/site-lisp/markdown-mode hides /usr/share/emacs/site-lisp/goodies/markdown-mode ~/lib/site-lisp/css-mode hides /usr/share/emacs/24.5/lisp/textmodes/css-mode /usr/share/emacs/site-lisp/gnus-bonus/nnir hides /usr/share/emacs/24.5/lisp/gnus/nnir /usr/share/emacs/site-lisp/gnus-bonus/nnnil hides /usr/share/emacs/24.5/lisp/gnus/nnnil /usr/share/emacs/site-lisp/gnus-bonus/spam-stat hides /usr/share/emacs/24.5/lisp/gnus/spam-stat ~/lib/site-lisp/longlines hides /usr/share/emacs/24.5/lisp/obsolete/longlines Features: (shadow sort gnus-util mail-extr emacsbug message idna format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils pp mule-util ebuff-menu wid-edit descr-text help-mode package epg-config server follow-mouse desktop frameset saveplace paren cl-macs cl gv apropos derived markdown-mode cl-loaddefs cl-lib thingatpt noutline outline easymenu advice help-fns mustache-mode delsel grep compile comint ansi-color ring cus-start cus-load time 50magit emacs-goodies-loaddefs easy-mmode time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) Memory information: ((conses 16 129620 19595) (symbols 48 32900 0) (miscs 40 1221 515) (strings 32 37972 9706) (string-bytes 1 1003542) (vectors 16 19979) (vector-slots 8 1305892 204196) (floats 8 78 475) (intervals 56 445 16) (buffers 960 16) (heap 1024 49802 1271)) ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-14 19:26 bug#23292: 24.5; Combining characters do not reliably combine Honore Doktorr @ 2016-04-14 19:50 ` Eli Zaretskii [not found] ` <CABtnboWhZYg16Wd9XPi4KjUjSTaC77BttkAU5OhrQXdsH=6+qQ@mail.gmail.com> 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-14 19:50 UTC (permalink / raw) To: Honore Doktorr; +Cc: 23292 > Date: Thu, 14 Apr 2016 15:26:03 -0400 > From: Honore Doktorr <hdfssk@gmail.com> > > Combining characters often do not render combined in emacs 24.5. > For example, the combining short solidus overlay (0x337, o̷) appears > following the character it's meant to combine with---although they are > both highlighted together and so forth. > > cf. https://i.imgsafe.org/8369941.jpeg for a visual reference. > > This seems similar to bug 17261, but both characters are from the same > font, DejaVu Sans Mono. Was your Emacs built with libotf and other libraries mentioned in INSTALL under "Complex Text Layout"? When I arrange for Emacs to use a font that supports both 'o' and the solidus, the sequence you show does display as a single glyph. (My default font doesn't have the solidus, so I need that special arrangement.) The fact that Emacs displays a cursor on both of the characters clearly shows that Emacs did combine them, but the font and/or the shaping engine didn't display them overlaid. Not sure why, perhaps upgrade your libotf and related libraries? ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CABtnboWhZYg16Wd9XPi4KjUjSTaC77BttkAU5OhrQXdsH=6+qQ@mail.gmail.com>]
* bug#23292: 24.5; Combining characters do not reliably combine [not found] ` <CABtnboWhZYg16Wd9XPi4KjUjSTaC77BttkAU5OhrQXdsH=6+qQ@mail.gmail.com> @ 2016-04-15 6:53 ` Eli Zaretskii 2016-04-15 7:47 ` Alexis 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-15 6:53 UTC (permalink / raw) To: Honore Doktorr; +Cc: 23292 [Please keep the bug address on the CC list.] > Date: Thu, 14 Apr 2016 17:30:01 -0400 > From: Honore Doktorr <hdfssk@gmail.com> > > > Was your Emacs built with libotf and other libraries mentioned in > > INSTALL under "Complex Text Layout"? > > > > When I arrange for Emacs to use a font that supports both 'o' and the > > solidus, the sequence you show does display as a single glyph. (My > > default font doesn't have the solidus, so I need that special > > arrangement.) > > > > The fact that Emacs displays a cursor on both of the characters > > clearly shows that Emacs did combine them, but the font and/or the > > shaping engine didn't display them overlaid. Not sure why, perhaps > > upgrade your libotf and related libraries? > > Yes, it looks like with the latest upstream versions of the complex text libraries/db: > > $ ldd /usr/bin/emacs |egrep 'lib(otf|m17n-flt)' > libotf.so.0 => /lib64/libotf.so.0 (0x00007f6cd2a05000) > libm17n-flt.so.0 => /lib64/libm17n-flt.so.0 (0x00007f6cd25cc000) > $ dnf -C list libotf m17n-lib m17n-db > Last metadata expiration check: 0:12:20 ago on Thu Apr 14 17:09:12 2016. > Installed Packages > libotf.x86_64 0.9.13-6.fc23 @@commandline > m17n-db.noarch 1.7.0-5.fc23 @@commandline > m17n-lib.x86_64 1.7.0-4.fc23 @@commandline > > I'm using the fedora 23 precompiled packages. Does anyone else see this with DejaVu Sans Mono? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 6:53 ` Eli Zaretskii @ 2016-04-15 7:47 ` Alexis 2016-04-15 7:55 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Alexis @ 2016-04-15 7:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Honore Doktorr, 23292 Eli Zaretskii <eliz@gnu.org> writes: > Does anyone else see this with DejaVu Sans Mono? Not by doing `C-x 8 / o', which produces 'ø'; but is that the way i should be testing this? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 7:47 ` Alexis @ 2016-04-15 7:55 ` Eli Zaretskii 2016-04-15 8:17 ` Alexis 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-15 7:55 UTC (permalink / raw) To: Alexis; +Cc: hdfssk, 23292 > From: Alexis <flexibeast@gmail.com> > Cc: Honore Doktorr <hdfssk@gmail.com>, 23292@debbugs.gnu.org > Date: Fri, 15 Apr 2016 17:47:25 +1000 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Does anyone else see this with DejaVu Sans Mono? > > Not by doing `C-x 8 / o', which produces 'ø'; but is that the way > i should be testing this? No. Type 'o', then "C-x 8 RET 337". ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 7:55 ` Eli Zaretskii @ 2016-04-15 8:17 ` Alexis 2016-04-15 8:32 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Alexis @ 2016-04-15 8:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: hdfssk, 23292 Eli Zaretskii <eliz@gnu.org> writes: > No. Type 'o', then "C-x 8 RET 337". Done. i get the same result as the OP - i.e. the 'o' and the '/' are visually separated - using both DejaVu Sans Mono (Book) and Inconsolata-G (my default font). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 8:17 ` Alexis @ 2016-04-15 8:32 ` Eli Zaretskii 2016-04-15 9:03 ` Alexis 2016-04-15 9:15 ` Eli Zaretskii 0 siblings, 2 replies; 14+ messages in thread From: Eli Zaretskii @ 2016-04-15 8:32 UTC (permalink / raw) To: Alexis, Kenichi Handa; +Cc: hdfssk, 23292 > From: Alexis <flexibeast@gmail.com> > Cc: hdfssk@gmail.com, 23292@debbugs.gnu.org > Date: Fri, 15 Apr 2016 18:17:48 +1000 > > > Eli Zaretskii <eliz@gnu.org> writes: > > > No. Type 'o', then "C-x 8 RET 337". > > Done. i get the same result as the OP - i.e. the 'o' and the '/' > are visually separated - using both DejaVu Sans Mono (Book) and > Inconsolata-G (my default font). Thanks. This is strange. I'm CC'ing Handa-san, perhaps there's some issue in libm17n-flt or its database for this case. For the record, the composition works for me on MS-Windows using the Arial Unicode MS font, and the composition data looks quite different (and makes much more sense to me) than what the OP shows: Composed with the following character(s) "̷" using this font: uniscribe:-outline-Arial Unicode MS-normal-normal-normal-sans-13-*-*-*-p-*-iso8859-1 by these glyphs: [0 1 111 82 7 1 6 14 4 nil] [0 1 823 671 0 -5 -2 14 4 nil] The OP said the composition data he gets is this: Composed with the following character(s) "̷" using this font: xft:-PfEd-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 by these glyphs: [0 1 111 82 8 1 7 7 0 nil] [0 1 823 703 8 0 8 8 1 nil] and the offsets in the second vector look wrong to me, FWIW. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 8:32 ` Eli Zaretskii @ 2016-04-15 9:03 ` Alexis 2016-04-15 9:21 ` Eli Zaretskii 2016-04-15 9:15 ` Eli Zaretskii 1 sibling, 1 reply; 14+ messages in thread From: Alexis @ 2016-04-15 9:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: hdfssk, 23292 Eli Zaretskii <eliz@gnu.org> writes: >> From: Alexis <flexibeast@gmail.com> Cc: hdfssk@gmail.com, >> 23292@debbugs.gnu.org Date: Fri, 15 Apr 2016 18:17:48 +1000 >> >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > No. Type 'o', then "C-x 8 RET 337". >> >> Done. i get the same result as the OP - i.e. the 'o' and the >> '/' are visually separated - using both DejaVu Sans Mono >> (Book) and Inconsolata-G (my default font). My apologies, i accidentally used a non -Q instance to test this. :-/ In a -Q instance, it turns out that DejaVu Sans Mono (Book) /does/ compose visually: Composed with the following character(s) "̷" using this font: xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 by these glyphs: [0 1 111 82 8 0 8 8 1 nil] [0 1 823 703 0 0 8 8 1 [-8 0 0]] Sorry! However, Inconsolata-g definitely doesn't compose visually. Interestingly, when i use `describe-char' on the 'o', i'm told that the glyph is sourced from Inconsolata-g, but when i use it on the '/', it tells me it's sourced from Gentium .... ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 9:03 ` Alexis @ 2016-04-15 9:21 ` Eli Zaretskii 2016-04-15 11:52 ` Alexis 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-15 9:21 UTC (permalink / raw) To: Alexis; +Cc: hdfssk, 23292 > From: Alexis <flexibeast@gmail.com> > Cc: Kenichi Handa <handa@gnu.org>, hdfssk@gmail.com, 23292@debbugs.gnu.org > Date: Fri, 15 Apr 2016 19:03:15 +1000 > > My apologies, i accidentally used a non -Q instance to test > this. :-/ In a -Q instance, it turns out that DejaVu Sans Mono > (Book) /does/ compose visually: Can you show a screenshot? > Composed with the following character(s) "̷" using this font: > xft:-unknown-DejaVu Sans > Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 > by these glyphs: > [0 1 111 82 8 0 8 8 1 nil] [0 1 823 703 0 0 8 8 1 [-8 0 0]] > > Sorry! > > However, Inconsolata-g definitely doesn't compose visually. > > Interestingly, when i use `describe-char' on the 'o', i'm told > that the glyph is sourced from Inconsolata-g, but when i use it on > the '/', it tells me it's sourced from Gentium .... Something with your fonts and fontsets, I guess. If you force Emacs to use Inconsolata-g for "̷", does the composition happen? Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 9:21 ` Eli Zaretskii @ 2016-04-15 11:52 ` Alexis 2016-04-16 10:01 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Alexis @ 2016-04-15 11:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: hdfssk, 23292 [-- Attachment #1: Type: text/plain, Size: 1065 bytes --] Eli Zaretskii <eliz@gnu.org> writes: > Can you show a screenshot? Attached. > Something with your fonts and fontsets, I guess. If you force > Emacs to use Inconsolata-g for "̷", does the composition happen? Hmm, i'm having some difficulty doing this. i start GUI Emacs from an X terminal via 'emacs -Q'. i then go to the Options menu, select "Set Default Font", and choose "InconsolataG Medium"[1]. In *scratch*, i type 'o', and confirm with `describe-char' that "InconsolataG" is the font used for that character. i then evaluate: (set-fontset-font "fontset-default" '(#x0337 . #x0337) "InconsolataG") with C-x C-e, which returns nil. If i then move point immediately after the previously-typed 'o', and type C-x 8 RET 337, the '/' is displayed visually separate from the 'o'. But using `describe-char' on it says that Gentium is the font used. i gather something i'm doing something wrong here, i'm guessing in the ELisp .... ? [1] "InconsolataG" is "Inconsolata-g" renamed by me locally, via FontForge, so as to be XLFD-friendly. [-- Attachment #2: dejavu_sans_mono_book.png --] [-- Type: image/png, Size: 5821 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 11:52 ` Alexis @ 2016-04-16 10:01 ` Eli Zaretskii 0 siblings, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2016-04-16 10:01 UTC (permalink / raw) To: Alexis; +Cc: hdfssk, 23292 > From: Alexis <flexibeast@gmail.com> > Cc: handa@gnu.org, hdfssk@gmail.com, 23292@debbugs.gnu.org > Date: Fri, 15 Apr 2016 21:52:51 +1000 > > > Something with your fonts and fontsets, I guess. If you force > > Emacs to use Inconsolata-g for "̷", does the composition happen? > > Hmm, i'm having some difficulty doing this. i start GUI Emacs from > an X terminal via 'emacs -Q'. i then go to the Options menu, > select "Set Default Font", and choose "InconsolataG Medium"[1]. In > *scratch*, i type 'o', and confirm with `describe-char' that > "InconsolataG" is the font used for that character. > > i then evaluate: > > (set-fontset-font "fontset-default" '(#x0337 . #x0337) > "InconsolataG") > > with C-x C-e, which returns nil. If i then move point immediately > after the previously-typed 'o', and type C-x 8 RET 337, the '/' is > displayed visually separate from the 'o'. But using > `describe-char' on it says that Gentium is the font used. Looks like for some reason Emacs rejects InconsolataG as the font for that character, not sure why. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 8:32 ` Eli Zaretskii 2016-04-15 9:03 ` Alexis @ 2016-04-15 9:15 ` Eli Zaretskii 2016-04-24 14:18 ` handa 1 sibling, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2016-04-15 9:15 UTC (permalink / raw) To: handa; +Cc: hdfssk, flexibeast, 23292 > Date: Fri, 15 Apr 2016 11:32:29 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: hdfssk@gmail.com, 23292@debbugs.gnu.org > > For the record, the composition works for me on MS-Windows using the > Arial Unicode MS font, and the composition data looks quite different > (and makes much more sense to me) than what the OP shows: > > Composed with the following character(s) "̷" using this font: > uniscribe:-outline-Arial Unicode MS-normal-normal-normal-sans-13-*-*-*-p-*-iso8859-1 > by these glyphs: > [0 1 111 82 7 1 6 14 4 nil] > [0 1 823 671 0 -5 -2 14 4 nil] > > The OP said the composition data he gets is this: > > Composed with the following character(s) "̷" using this font: > xft:-PfEd-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 > by these glyphs: > [0 1 111 82 8 1 7 7 0 nil] > [0 1 823 703 8 0 8 8 1 nil] > > and the offsets in the second vector look wrong to me, FWIW. I now tried this on Windows 8.1, where the (default) Courier New font does have a glyph for u+0337, and I see there the same problem as reported by the OP, including the composition data that shows positive offsets where I thought negative offsets should be. Maybe this is something related to the fact that bot DejaVu Sans Mono and Courier New are monospaced fonts, whereas Arial Unicode MS isn't? I Hope Handa-san will provide some insight. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-15 9:15 ` Eli Zaretskii @ 2016-04-24 14:18 ` handa 2016-05-17 4:40 ` Alexis 0 siblings, 1 reply; 14+ messages in thread From: handa @ 2016-04-24 14:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: hdfssk, flexibeast, 23292 Sorry for the late response. In article <83y48fcjw9.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > > For the record, the composition works for me on MS-Windows using the > > Arial Unicode MS font, and the composition data looks quite different > > (and makes much more sense to me) than what the OP shows: > > > > Composed with the following character(s) "̷" using this font: > > uniscribe:-outline-Arial Unicode MS-normal-normal-normal-sans-13-*-*-*-p-*-iso8859-1 > > by these glyphs: > > [0 1 111 82 7 1 6 14 4 nil] > > [0 1 823 671 0 -5 -2 14 4 nil] > > > > The OP said the composition data he gets is this: > > > > Composed with the following character(s) "̷" using this font: > > xft:-PfEd-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1 > > by these glyphs: > > [0 1 111 82 8 1 7 7 0 nil] > > [0 1 823 703 8 0 8 8 1 nil] > > > > and the offsets in the second vector look wrong to me, FWIW. > I now tried this on Windows 8.1, where the (default) Courier New font > does have a glyph for u+0337, and I see there the same problem as > reported by the OP, including the composition data that shows positive > offsets where I thought negative offsets should be. > Maybe this is something related to the fact that bot DejaVu Sans Mono > and Courier New are monospaced fonts, whereas Arial Unicode MS isn't? > I Hope Handa-san will provide some insight. I tried to display "o\x0337" by "dejavu sans mono" font and saw no problem. I also tried "Inconsolata-g" font and found "\x0337" was not displayed by that font. But, this is simply because the font doesn't have a glyph for "\x0337". I downloaded "Inconsolata-g" font from http://www.fantascienza.net/leonardo/ar/inconsolatag/inconsolata-g_font.zip. Are we using the same font? --- K. Handa handa@gnu.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#23292: 24.5; Combining characters do not reliably combine 2016-04-24 14:18 ` handa @ 2016-05-17 4:40 ` Alexis 0 siblings, 0 replies; 14+ messages in thread From: Alexis @ 2016-05-17 4:40 UTC (permalink / raw) To: handa; +Cc: hdfssk, 23292 handa <handa@gnu.org> writes: > I tried to display "o\x0337" by "dejavu sans mono" font and saw > no problem. I also tried "Inconsolata-g" font and found > "\x0337" was not displayed by that font. But, this is simply > because the font doesn't have a glyph for "\x0337". > > I downloaded "Inconsolata-g" font from > http://www.fantascienza.net/leonardo/ar/inconsolatag/inconsolata-g_font.zip. > Are we using the same font? i believe so. Running fc-query(1) on the TTF version in my ~/.fonts folder: $ fc-query ~/.fonts/ttf/Inconsolata-g.ttf | grep -E 'version|hash' fontversion: 66191(i)(s) hash: "sha256:6847a2f48296546984ea60c37cc34749375857d137a01a574566d9c73d13e908"(s) Running fc-query(1) on the TTF version from the above URL: $ fc-query ./Inconsolata-g.ttf | grep -E 'version|hash' fontversion: 66191(i)(s) hash: "sha256:6847a2f48296546984ea60c37cc34749375857d137a01a574566d9c73d13e908"(s) ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-05-17 4:40 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-04-14 19:26 bug#23292: 24.5; Combining characters do not reliably combine Honore Doktorr 2016-04-14 19:50 ` Eli Zaretskii [not found] ` <CABtnboWhZYg16Wd9XPi4KjUjSTaC77BttkAU5OhrQXdsH=6+qQ@mail.gmail.com> 2016-04-15 6:53 ` Eli Zaretskii 2016-04-15 7:47 ` Alexis 2016-04-15 7:55 ` Eli Zaretskii 2016-04-15 8:17 ` Alexis 2016-04-15 8:32 ` Eli Zaretskii 2016-04-15 9:03 ` Alexis 2016-04-15 9:21 ` Eli Zaretskii 2016-04-15 11:52 ` Alexis 2016-04-16 10:01 ` Eli Zaretskii 2016-04-15 9:15 ` Eli Zaretskii 2016-04-24 14:18 ` handa 2016-05-17 4:40 ` Alexis
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).