GNU bug report logs -
#54646
29.0.50; set-fontset-font and font clipping issues
Previous Next
Reported by: Visuwesh <visuweshm <at> gmail.com>
Date: Thu, 31 Mar 2022 03:38:01 UTC
Severity: normal
Merged with 73752
Found in versions 29.0.50, 29.4
Fixed in version 30.1
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54646 in the body.
You can then email your comments to 54646 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 03:38:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Visuwesh <visuweshm <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 31 Mar 2022 03:38:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I have the following line [1] in my init.el to make Emacs use "Kurinto
Seri" for the Tamil script,
(set-fontset-font t 'tamil "Kurinto Seri")
and this leads to font "clipping" issues. The text is shaped properly
in that it combines the diacritics but I see "clipping" problems
instead. See screenshot below:
[screenshot_202203310850.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
I type C-x C-+, then the clipping problem goes away until I increase the
font size again a bit and the problem gets worse:
[screenshot_202203310853.png (image/png, inline)]
[Message part 5 (text/plain, inline)]
I cannot seem to reproduce this from emacs -Q, nor do I see this issue
when I start Emacs up (I use the daemon if that makes a difference [2]).
It naturally shows up after using Emacs for a while, sometimes reopening
the frame fixes the clipping problems, sometimes I have to reevaluate
the set-fontset-font form to fix it. And this issue isn't font-specific
as well: I had the same problem with "Noto Serif." I would highly any
hints towards nailing the problem down; I'm really out of ideas.
If I didn't make it clear, there are no such problems if I don't modify
the default fontset.
[1] I also modify the default fontset for other scripts,
(set-fontset-font t 'mathematical "Kurinto Mono" nil 'prepend)
(set-fontset-font t 'mathematical "Latin Modern Math" nil 'append)
(set-fontset-font t 'symbol "Latin Modern Math" nil 'append)
(set-fontset-font t 'emoji "Kurinto Mono")
(set-fontset-font t 'emoji "Kurinto Sans" nil 'append)
(set-fontset-font t 'emoji "DejaVu Sans" nil 'append)
and I set the language and the locale environment to Tamil and
ta_IN.utf8 respectively, before modifying the fontset.
[2] Modifying the fontset in `server-after-make-frame-hook' does not
make a difference. I don't see the issue when I do not use the
daemon but I believe I haven't run the non-daemon session long
enough.
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
Repository revision: ca3858563c7ba8ee3caa82fbd2b7c386ea60c0d3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: NixOS 21.11 (Porcupine)
Configured using:
'configure
--prefix=/nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0
--disable-build-details --with-modules --with-x-toolkit=lucid
--with-xft --with-cairo --with-native-compilation'
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM LUCID ZLIB
Important settings:
value of $EMACSLOADPATH:
value of $EMACSNATIVELOADPATH: /nix/store/5gh4w50dhchhcyjm6ysh17h7y4i5vasf-emacs-packages-deps/share/emacs/native-lisp::
value of $LC_MONETARY: ta_IN.UTF-8
value of $LC_NUMERIC: ta_IN.UTF-8
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix
Major mode: Group
Minor modes in effect:
semantic-minor-modes-format: ((:eval (if (or semantic-highlight-edits-mode semantic-show-unmatched-syntax-mode) S)))
gnus-agent-group-mode: t
gnus-undo-mode: t
recentf-mode: t
shell-dirtrack-mode: t
eros-mode: t
pdf-occur-global-minor-mode: t
minibuffer-depth-indicate-mode: t
repeat-mode: t
display-time-mode: t
display-battery-mode: t
straight-use-package-mode: t
straight-package-neutering-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tab-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
undelete-frame-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
indent-tabs-mode: t
transient-mark-mode: t
Load-path shadows:
/home/viz/.nix-profile/share/emacs/site-lisp/site-start hides /nix/store/5gh4w50dhchhcyjm6ysh17h7y4i5vasf-emacs-packages-deps/share/emacs/site-lisp/site-start
/home/viz/lib/emacs/straight/build/map/map hides /nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0/share/emacs/29.0.50/lisp/emacs-lisp/map
/home/viz/lib/emacs/straight/build/let-alist/let-alist hides /nix/store/iqqk7iqfwmfc6r78xg2knyq7hww2mhs4-emacs-git-20220225.0/share/emacs/29.0.50/lisp/emacs-lisp/let-alist
Features:
(shadow emacsbug sendmail ecomplete vc ind-util shortdoc smerge-mode
diff find-dired dired-aux gnus-dired flow-fill notifications xref
timezone shr-color descr-text url-http url-gw url-cache url-auth
pdf-sync pdf-outline pdf-links pdf-history icomplete tabify
writegood-mode org-agenda cal-islam holidays hol-loaddefs mule-util
cal-move flyspell ispell org-pdftools pdf-annot facemenu org-noter
goto-addr org-indent org-element avl-tree generator org-capture doct
org-refile ob-C cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs ob-shell ob-racket async ob-async
tempo ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect ol-docview doc-view ol-bibtex ol-bbdb ol-w3m ol-doi
org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete org-list org-faces
org-entities org-version ob-emacs-lisp ob-core ob-eval org-table
oc-basic bibtex ol org-keys oc org-compat org-macs org-loaddefs
mm-archive sort gnus-cite mail-extr textsec uni-scripts idna-mapping
ucs-normalize uni-confusable textsec-check gnus-bcklg gnus-async qp
gnus-ml gnutls network-stream nsm nndraft nnmh nnfolder nnmaildir
nnagent nnml nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig nntp
gnus-cache gnus-sum shr pixel-fill kinsoku url-file url-dired svg dom
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message
yank-media rmc puny rfc822 mml mml-sec epa epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus nnheader
gnus-util mail-utils range mm-util mail-prsvr tramp-cmds rfc2104
tramp-cache tramp-sh tramp tramp-loaddefs trampver tramp-integration
cus-start files-x tramp-compat parse-time iso8601 ls-lisp shell-command+
view executable time-stamp pulse color cl-print help-fns misearch
multi-isearch reveal noutline outline recentf tree-widget vc-git
diff-mode vc-dispatcher cursor-sensor face-remap shell pcomplete server
paredit edmacro kmacro eros time-date checkdoc flymake-proc flymake
project thingatpt hl-todo wordel-autoloads sokoban-autoloads
ement-autoloads ts-autoloads map-autoloads plz-autoloads nov-autoloads
esxml-autoloads kv-autoloads transmission-autoloads lua-mode-autoloads
nix-mode-autoloads magit-section-autoloads dash-autoloads
racket-mode-autoloads eros-autoloads flymake-shellcheck-autoloads
writegood-mode-autoloads avy avy-autoloads siege-mode-autoloads
paredit-autoloads puni-autoloads expand-region-autoloads
filladapt-autoloads compose quail scroll-other-window
org-pdftools-autoloads org-noter-autoloads math-delimiters-autoloads
doct-autoloads ob-async-autoloads async-autoloads
emacs-ob-racket-autoloads valign-autoloads org-starless-autoloads
cdlatex-autoloads auctex-autoloads tex-site easy-mmode pdf-occur
ibuf-ext ibuffer ibuffer-loaddefs tablist advice tablist-filter
semantic/wisent/comp semantic/wisent semantic/wisent/wisent
semantic/util-modes semantic/util semantic semantic/tag semantic/lex
semantic/fw mode-local find-func cedet pdf-isearch let-alist pdf-misc
imenu pdf-tools package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source eieio eieio-core eieio-loaddefs json
map url-vars compile comint ansi-color ring cus-edit wid-edit pdf-view
password-cache jka-compr pdf-cache pdf-info tq pdf-util pdf-macs
image-mode dired-x dired dired-loaddefs exif pdf-tools-autoloads
let-alist-autoloads tablist-autoloads derived mb-depth cus-load repeat
visual-fill-autoloads olivetti-autoloads hl-todo-autoloads time
format-spec battery dbus filenotify xml disp-table lacarte-autoloads
shell-command-plus-autoloads icalendar diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs filecache flymake-grammarly-autoloads
grammarly-autoloads websocket-autoloads finder-inf request-autoloads
s-autoloads chemtable-autoloads comp comp-cstr warnings rx autoload
radix-tree lisp-mnt saveplace-pdf-view saveplace bookmark
text-property-search pp saveplace-pdf-view-autoloads pcase
straight-autoloads info cl-seq cl-extra help-mode straight cl-macs
cl-loaddefs cl-lib vz-nh-theme seq gv subr-x byte-opt bytecomp
byte-compile cconv iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 1396059 197130)
(symbols 48 51447 4)
(strings 32 326304 31436)
(string-bytes 1 73415709)
(vectors 16 135734)
(vector-slots 8 3276991 368443)
(floats 8 9251 1289)
(intervals 56 69814 2502)
(buffers 992 63))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 05:35:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Thu, 31 Mar 2022 09:07:30 +0530
>
> I cannot seem to reproduce this from emacs -Q, nor do I see this issue
> when I start Emacs up (I use the daemon if that makes a difference [2]).
> [...]
> It naturally shows up after using Emacs for a while, sometimes reopening
> the frame fixes the clipping problems, sometimes I have to reevaluate
> the set-fontset-font form to fix it. And this issue isn't font-specific
> as well: I had the same problem with "Noto Serif." I would highly any
> hints towards nailing the problem down; I'm really out of ideas.
When it happens, does it help to do the below?
M-: (clear-composition-cache) RET
Also, does this happen with buffer text or on the mode line? If it
happens with buffer text, try these two experiments when it happens:
. move the cursor with C-f across the problematically-displayed
text, and see whether the display becomes correct and/or whether
you see some display artifacts, like "ghosts" of the cursor block
left behind;
. go to the problematically-displayed text and type "C-u C-x =",
then compare what you see with the results of "C-u C-x =" for
the same text when it is correctly displayed
> [2] Modifying the fontset in `server-after-make-frame-hook' does not
> make a difference. I don't see the issue when I do not use the
> daemon but I believe I haven't run the non-daemon session long
> enough.
Then please try running such a non-daemon session longer. It is
important to know whether this is at all related to daemon.
If it only happens with daemon sessions, I'll ask you to describe in
more detail how you use those sessions. In particular, do you use
both GUI and TTY emacsclient frames in the same session, do you edit
Tamil text in TTY frames, do you connect to the same server from
different remote hosts, or display frames on clients that use
different font for Tamil? Any other detail in your routine usage
might give a clue.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 07:05:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Date: Thu, 31 Mar 2022 09:07:30 +0530
>>
>> I cannot seem to reproduce this from emacs -Q, nor do I see this issue
>> when I start Emacs up (I use the daemon if that makes a difference [2]).
>> [...]
>> It naturally shows up after using Emacs for a while, sometimes reopening
>> the frame fixes the clipping problems, sometimes I have to reevaluate
>> the set-fontset-font form to fix it. And this issue isn't font-specific
>> as well: I had the same problem with "Noto Serif." I would highly any
>> hints towards nailing the problem down; I'm really out of ideas.
>
> When it happens, does it help to do the below?
>
> M-: (clear-composition-cache) RET
>
It does not really help. I saw a slight change in the "gaps" between
characters. But I do believe the issue might be do with some kind of
caching: when I read Tamil text, I tend to increase the buffer text size
using C-x C-+. Currently, Emacs does not display the text properly but
if I zoom in enough (so that the scale is similar/same as the one that
was used in another buffer), the text is shaped properly. Please see
the following screenshots,
before text-scale-mode:
[screenshot_202203311232.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
after text-scale-mode (6x):
[screenshot_202203311231.png (image/png, inline)]
[Message part 5 (text/plain, inline)]
> Also, does this happen with buffer text or on the mode line?
I'm not sure about the mode line (buffer names with Tamil text render
just fine) but the header line can have clipped text. The screenshots
are from a dired buffer.
> If it happens with buffer text, try these two experiments when it
> happens:
>
> . move the cursor with C-f across the problematically-displayed
> text, and see whether the display becomes correct and/or whether
> you see some display artifacts, like "ghosts" of the cursor block
> left behind;
I observe none of these.
> . go to the problematically-displayed text and type "C-u C-x =",
> then compare what you see with the results of "C-u C-x =" for
> the same text when it is correctly displayed
>
The *Help* buffer also has incorrectly shaped text.
>> [2] Modifying the fontset in `server-after-make-frame-hook' does not
>> make a difference. I don't see the issue when I do not use the
>> daemon but I believe I haven't run the non-daemon session long
>> enough.
>
> Then please try running such a non-daemon session longer. It is
> important to know whether this is at all related to daemon.
>
Yes, I will do and see if there are any changes.
> If it only happens with daemon sessions, I'll ask you to describe in
> more detail how you use those sessions. In particular, do you use
> both GUI and TTY emacsclient frames in the same session,
I only use GUI frames. But I do use emacsclient -c --eval a fair bit in
scripts (that mostly launch a GUI frame and runs a command---`shell',
`org-capture', etc.).
> do you edit Tamil text in TTY frames,
No. I don't use TTY frames.
> do you connect to the same server from different remote hosts,
No such thing.
> or display frames on clients that use different font for Tamil?
I'm not sure what you exactly mean here: all clients use the same font.
> Any other detail in your routine usage might give a clue.
>
Since I observed (clear-composition-cache) change the "size" of Tamil
text a tiny bit, I can say that I rely on text-scale-mode a lot. I
increase the buffer text by 2 to 3 times when writing something as that
helps me focus a bit better.
> Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 07:12:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 54646 <at> debbugs.gnu.org
> Date: Thu, 31 Mar 2022 12:33:47 +0530
>
> > . go to the problematically-displayed text and type "C-u C-x =",
> > then compare what you see with the results of "C-u C-x =" for
> > the same text when it is correctly displayed
> >
>
> The *Help* buffer also has incorrectly shaped text.
That's not what I meant. I meant to save the information from *Help*
when the text is displayed incorrectly, and then compare it with what
"C-u C-x =" produces when the same text is displayed correctly
(presumably, if you restart Emacs?).
> >> [2] Modifying the fontset in `server-after-make-frame-hook' does not
> >> make a difference. I don't see the issue when I do not use the
> >> daemon but I believe I haven't run the non-daemon session long
> >> enough.
> >
> > Then please try running such a non-daemon session longer. It is
> > important to know whether this is at all related to daemon.
> >
>
> Yes, I will do and see if there are any changes.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 07:36:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org
>> Date: Thu, 31 Mar 2022 12:33:47 +0530
>>
>> > . go to the problematically-displayed text and type "C-u C-x =",
>> > then compare what you see with the results of "C-u C-x =" for
>> > the same text when it is correctly displayed
>> >
>>
>> The *Help* buffer also has incorrectly shaped text.
>
> That's not what I meant. I meant to save the information from *Help*
> when the text is displayed incorrectly, and then compare it with what
> "C-u C-x =" produces when the same text is displayed correctly
> (presumably, if you restart Emacs?).
>
Ah, upon re-reading I see what you meant. Sorry about that, I will do
that as well.
>> >> [2] Modifying the fontset in `server-after-make-frame-hook' does not
>> >> make a difference. I don't see the issue when I do not use the
>> >> daemon but I believe I haven't run the non-daemon session long
>> >> enough.
>> >
>> > Then please try running such a non-daemon session longer. It is
>> > important to know whether this is at all related to daemon.
>> >
>>
>> Yes, I will do and see if there are any changes.
>
> Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 07:49:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 54646 <at> debbugs.gnu.org
> Date: Thu, 31 Mar 2022 12:33:47 +0530
>
> > When it happens, does it help to do the below?
> >
> > M-: (clear-composition-cache) RET
> >
>
> It does not really help.
What about the two commands below, one after the other -- do they
help?
M-: (clear-font-cache) RET
M-x redraw-display RET
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 08:47:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org
>> Date: Thu, 31 Mar 2022 12:33:47 +0530
>>
>> > . go to the problematically-displayed text and type "C-u C-x =",
>> > then compare what you see with the results of "C-u C-x =" for
>> > the same text when it is correctly displayed
>> >
>>
>> The *Help* buffer also has incorrectly shaped text.
>
> That's not what I meant. I meant to save the information from *Help*
> when the text is displayed incorrectly, and then compare it with what
> "C-u C-x =" produces when the same text is displayed correctly
> (presumably, if you restart Emacs?).
>
I have attached three text files that have the content of the *Help*
buffer in the three cases:
· correct: from emacs -Q which does not exhibit the problem.
· incorrect: from an non-daemon Emacs session that exhibits the
problem.
· correct_config: from a fresh Emacs session with my init.el loaded
that does not exhibit the problem.
>> >> [2] Modifying the fontset in `server-after-make-frame-hook' does not
>> >> make a difference. I don't see the issue when I do not use the
>> >> daemon but I believe I haven't run the non-daemon session long
>> >> enough.
>> >
>> > Then please try running such a non-daemon session longer. It is
>> > important to know whether this is at all related to daemon.
>> >
>>
>> Yes, I will do and see if there are any changes.
>
> Thanks.
Looks like this issue has nothing to do with me using the daemon. If I
go about using Emacs like I usually do, it reproduces in a non-daemon
session as well. Here's all the things I did in this session (AFAICR):
· Started a process in the background using the doas TRAMP method.
· Scrolled around in my init.el file which has Tamil text in the
hopes of reproducing the issue. I also increased and decreased
the buffer text size a few times.
· Opened gnus and sent the previous reply. I'm currently writing
the mail from an Emacs session that exhibits the problem.
Also, the mode line text is rendered similar to the text in-buffer:
[screenshot_202203311415.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
So far M-: (clear-composition-cache) has not helped.
[correct (text/plain, attachment)]
[correct_config (text/plain, attachment)]
[incorrect (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 08:49:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org
>> Date: Thu, 31 Mar 2022 12:33:47 +0530
>>
>> > When it happens, does it help to do the below?
>> >
>> > M-: (clear-composition-cache) RET
>> >
>>
>> It does not really help.
>
> What about the two commands below, one after the other -- do they
> help?
>
> M-: (clear-font-cache) RET
> M-x redraw-display RET
Unfortunately, no. I repeated it, all in vain.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 09:05:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 54646 <at> debbugs.gnu.org
> Date: Thu, 31 Mar 2022 14:15:41 +0530
>
> I have attached three text files that have the content of the *Help*
> buffer in the three cases:
>
> · correct: from emacs -Q which does not exhibit the problem.
>
> · incorrect: from an non-daemon Emacs session that exhibits the
> problem.
>
> · correct_config: from a fresh Emacs session with my init.el loaded
> that does not exhibit the problem.
For meaningful comparison, I need data for the same font size. One of
the three samples uses a smaller font size, so it's hard to compare it
to the rest.
However, this:
> Composed with the following character(s) "்" using this font:
> ftcrhb:-Goss-Kurinto Seri-regular-normal-normal-*-14-*-*-*-*-0-iso10646-1
> by these glyphs:
> [0 1 2965 23479 12 0 12 8 0 nil]
> [0 1 3021 23505 0 -1 1 11 -9 [-6 0 0]]
> with these character(s):
> ் (#xbcd) TAMIL SIGN VIRAMA
vs this:
> Composed with the following character(s) "்" using this font:
> ftcrhb:-Goss-Kurinto Seri-regular-normal-normal-*-14-*-*-*-*-0-iso10646-1
> by these glyphs:
> [0 1 2965 23479 12 0 12 8 0 [0 0 20]]
> [0 1 3021 23505 0 -1 1 11 -9 [-14 0 0]]
> with these character(s):
> ் (#xbcd) TAMIL SIGN VIRAMA
Seems to indicate that we use incorrect composition data in the second
case: the X offset part (-14) seems to be too large, and I don't
understand why there's a non-zero WADJUST value (20) for the first
glyph of the grapheme cluster. Very strange. Are both cases for
exactly the same text that surrounds the problematic characters, or
does the surrounding text differ in any way?
Also, what version of HarfBuzz do you have there? Can you try
upgrading to a newer version?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 09:31:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org
>> Date: Thu, 31 Mar 2022 14:15:41 +0530
>>
>> I have attached three text files that have the content of the *Help*
>> buffer in the three cases:
>>
>> · correct: from emacs -Q which does not exhibit the problem.
>>
>> · incorrect: from an non-daemon Emacs session that exhibits the
>> problem.
>>
>> · correct_config: from a fresh Emacs session with my init.el loaded
>> that does not exhibit the problem.
>
> For meaningful comparison, I need data for the same font size. One of
> the three samples uses a smaller font size, so it's hard to compare it
> to the rest.
>
Sorry about that. Please see below for the text from emacs -Q with the
same font size:
position: 5673 of 5691 (100%), column: 3
character: க (displayed as க) (codepoint 2965, #o5625, #xb95)
charset: unicode (Unicode (ISO10646))
code point in charset: 0x0B95
script: tamil
syntax: w which means: word
category: .:Base, L:Strong L2R
to input: type "C-x 8 RET b95" or "C-x 8 RET TAMIL LETTER KA"
buffer code: #xE0 #xAE #x95
file code: #xE0 #xAE #x95 (encoded by coding system utf-8-unix)
display: composed to form "க்" (see below)
Composed with the following character(s) "்" using this font:
ftcrhb:-Goss-Kurinto Seri-regular-normal-normal-*-14-*-*-*-*-0-iso10646-1
by these glyphs:
[0 1 2965 23479 12 0 12 8 0 nil]
[0 1 3021 23505 0 -1 1 11 -9 [-6 0 0]]
with these character(s):
் (#xbcd) TAMIL SIGN VIRAMA
Character code properties: customize what to show
name: TAMIL LETTER KA
general-category: Lo (Letter, Other)
decomposition: (2965) ('க')
> However, this:
>
>> Composed with the following character(s) "்" using this font:
>> ftcrhb:-Goss-Kurinto Seri-regular-normal-normal-*-14-*-*-*-*-0-iso10646-1
>> by these glyphs:
>> [0 1 2965 23479 12 0 12 8 0 nil]
>> [0 1 3021 23505 0 -1 1 11 -9 [-6 0 0]]
>> with these character(s):
>> ் (#xbcd) TAMIL SIGN VIRAMA
>
> vs this:
>
>> Composed with the following character(s) "்" using this font:
>> ftcrhb:-Goss-Kurinto Seri-regular-normal-normal-*-14-*-*-*-*-0-iso10646-1
>> by these glyphs:
>> [0 1 2965 23479 12 0 12 8 0 [0 0 20]]
>> [0 1 3021 23505 0 -1 1 11 -9 [-14 0 0]]
>> with these character(s):
>> ் (#xbcd) TAMIL SIGN VIRAMA
>
> Seems to indicate that we use incorrect composition data in the second
> case: the X offset part (-14) seems to be too large, and I don't
> understand why there's a non-zero WADJUST value (20) for the first
> glyph of the grapheme cluster. Very strange. Are both cases for
> exactly the same text that surrounds the problematic characters, or
> does the surrounding text differ in any way?
>
No, they are the same exact text. (Unless dired changes the surrounding
text somehow between sessions, which I don't think it does.)
> Also, what version of HarfBuzz do you have there? Can you try
> upgrading to a newer version?
Emacs is linked against HarfBuzz 3.0.0. I will see if I can update it,
and report back in the evening. (P.S., maybe we should look into
including this info in the text that M-x report-emacs-bug prepares?)
[ I will also check if I can reproduce this in emacs -Q but with
M-: (set-fontset-font t 'tamil "Kurinto Seri") RET. ]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 09:42:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 54646 <at> debbugs.gnu.org
> Date: Thu, 31 Mar 2022 14:59:47 +0530
>
> > Also, what version of HarfBuzz do you have there? Can you try
> > upgrading to a newer version?
>
> Emacs is linked against HarfBuzz 3.0.0. I will see if I can update it,
> and report back in the evening. (P.S., maybe we should look into
> including this info in the text that M-x report-emacs-bug prepares?)
HarfBuzz is remarkably compatible, and its version until now was never
important. I asked about that because it is the source of the
composition data which seems to be incorrect in the wrong display
cases. I'm not yet sure it's a HarfBuzz problem.
> [ I will also check if I can reproduce this in emacs -Q but with
> M-: (set-fontset-font t 'tamil "Kurinto Seri") RET. ]
Thanks.
One more question: what is the value of current-iso639-language, and
is it different between the "bad" and the "good" cases?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 12:18:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org
>> Date: Thu, 31 Mar 2022 14:59:47 +0530
>>
>> > Also, what version of HarfBuzz do you have there? Can you try
>> > upgrading to a newer version?
>>
>> Emacs is linked against HarfBuzz 3.0.0. I will see if I can update it,
>> and report back in the evening. (P.S., maybe we should look into
>> including this info in the text that M-x report-emacs-bug prepares?)
>
> HarfBuzz is remarkably compatible, and its version until now was never
> important. I asked about that because it is the source of the
> composition data which seems to be incorrect in the wrong display
> cases. I'm not yet sure it's a HarfBuzz problem.
>
>> [ I will also check if I can reproduce this in emacs -Q but with
>> M-: (set-fontset-font t 'tamil "Kurinto Seri") RET. ]
>
> Thanks.
>
> One more question: what is the value of current-iso639-language, and
> is it different between the "bad" and the "good" cases?
'ta' in both case.
BTW, the "bad" case having width 20 seems "correct" to me since the
character occupies more space than it should i.e., imagine a letter like
"I" but with a bunch of whitespace next to it as in "I ".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 13:45:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org
>> Date: Thu, 31 Mar 2022 14:59:47 +0530
>>
>> > Also, what version of HarfBuzz do you have there? Can you try
>> > upgrading to a newer version?
>>
>> Emacs is linked against HarfBuzz 3.0.0. I will see if I can update it,
>> and report back in the evening. (P.S., maybe we should look into
>> including this info in the text that M-x report-emacs-bug prepares?)
>
> HarfBuzz is remarkably compatible, and its version until now was never
> important. I asked about that because it is the source of the
> composition data which seems to be incorrect in the wrong display
> cases. I'm not yet sure it's a HarfBuzz problem.
>
I compiled an Emacs that is linked against HarfBuzz 3.3.2, and it shows
the same problem.
>> [ I will also check if I can reproduce this in emacs -Q but with
>> M-: (set-fontset-font t 'tamil "Kurinto Seri") RET. ]
I managed to reproduce this in an emacs -Q session with that evaled but
it took me some time [*]. For each buffer that has Tamil text, I have
to zoom in (or none in the case of eww's header-line) different amounts
to see the clipping issue:
· In init.el, I have to zoom in 7x times
· In eww, I have to zoom in 1x time
· In dired, I have to zoom in ~15x times
In the problematic emacs -Q session, current-iso639-language is 'en'.
[*] As in, it literally took me half an hour to observe the issue, and I
cannot seem to figure out a quick way to reproduce it.
>
> Thanks.
>
> One more question: what is the value of current-iso639-language, and
> is it different between the "bad" and the "good" cases?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 14:04:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 54646 <at> debbugs.gnu.org
> Date: Thu, 31 Mar 2022 17:46:51 +0530
>
> [வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>
> >> From: Visuwesh <visuweshm <at> gmail.com>
> >> Cc: 54646 <at> debbugs.gnu.org
> >> Date: Thu, 31 Mar 2022 14:59:47 +0530
> >>
> >> > Also, what version of HarfBuzz do you have there? Can you try
> >> > upgrading to a newer version?
> >>
> >> Emacs is linked against HarfBuzz 3.0.0. I will see if I can update it,
> >> and report back in the evening. (P.S., maybe we should look into
> >> including this info in the text that M-x report-emacs-bug prepares?)
> >
> > HarfBuzz is remarkably compatible, and its version until now was never
> > important. I asked about that because it is the source of the
> > composition data which seems to be incorrect in the wrong display
> > cases. I'm not yet sure it's a HarfBuzz problem.
> >
> >> [ I will also check if I can reproduce this in emacs -Q but with
> >> M-: (set-fontset-font t 'tamil "Kurinto Seri") RET. ]
> >
> > Thanks.
> >
> > One more question: what is the value of current-iso639-language, and
> > is it different between the "bad" and the "good" cases?
>
> 'ta' in both case.
Thanks. Then I'm out of ideas, I'm afraid. The data comes from
HarfBuzz, so if it's our fault, we must feed it something differently
in each case, and I cannot see what that could be...
> BTW, the "bad" case having width 20 seems "correct" to me since the
> character occupies more space than it should i.e., imagine a letter like
> "I" but with a bunch of whitespace next to it as in "I ".
That 20 and the larger value of X offset are the only differences
between the "bad" and the "good" cases, so they must be the
explanation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 14:11:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 54646 <at> debbugs.gnu.org
> Date: Thu, 31 Mar 2022 19:14:23 +0530
>
> I compiled an Emacs that is linked against HarfBuzz 3.3.2, and it shows
> the same problem.
The latest version of HarfBuzz is 4.2.0, although the chances that
it's their problem are not great.
> I managed to reproduce this in an emacs -Q session with that evaled but
> it took me some time [*]. For each buffer that has Tamil text, I have
> to zoom in (or none in the case of eww's header-line) different amounts
> to see the clipping issue:
>
> · In init.el, I have to zoom in 7x times
> · In eww, I have to zoom in 1x time
> · In dired, I have to zoom in ~15x times
>
> In the problematic emacs -Q session, current-iso639-language is 'en'.
>
> [*] As in, it literally took me half an hour to observe the issue, and I
> cannot seem to figure out a quick way to reproduce it.
Can you provide a recipe, as in: what file or URL to visit and/or what
text to insert before starting the zoom commands? Also, do you zoom
in and out repeatedly, or just zoom in that many time? And if it just
takes a small number of zoom commands, why do you say it takes half an
hour? what else needs to happen during that time to see the
problematic display?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 14:13:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 31 Mar 2022 17:10:40 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 54646 <at> debbugs.gnu.org
>
> Can you provide a recipe, as in: what file or URL to visit and/or what
> text to insert before starting the zoom commands? Also, do you zoom
> in and out repeatedly, or just zoom in that many time? And if it just
> takes a small number of zoom commands, why do you say it takes half an
> hour? what else needs to happen during that time to see the
> problematic display?
One more question: does this happen only with that particular font
used for Tamil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 15:08:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் மார்ச் 31, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org
>> Date: Thu, 31 Mar 2022 19:14:23 +0530
>>
>> I compiled an Emacs that is linked against HarfBuzz 3.3.2, and it shows
>> the same problem.
>
> The latest version of HarfBuzz is 4.2.0, although the chances that
> it's their problem are not great.
>
>> I managed to reproduce this in an emacs -Q session with that evaled but
>> it took me some time [*]. For each buffer that has Tamil text, I have
>> to zoom in (or none in the case of eww's header-line) different amounts
>> to see the clipping issue:
>>
>> · In init.el, I have to zoom in 7x times
>> · In eww, I have to zoom in 1x time
>> · In dired, I have to zoom in ~15x times
>>
>> In the problematic emacs -Q session, current-iso639-language is 'en'.
>>
>> [*] As in, it literally took me half an hour to observe the issue, and I
>> cannot seem to figure out a quick way to reproduce it.
>
> Can you provide a recipe, as in: what file or URL to visit and/or what
> text to insert before starting the zoom commands? Also, do you zoom
> in and out repeatedly, or just zoom in that many time? And if it just
> takes a small number of zoom commands, why do you say it takes half an
> hour? what else needs to happen during that time to see the
> problematic display?
>
It looks like I was mistaken about the time it takes to reproduce; I was
simply not observant enough. Here's a recipe that reliably reproduces
the problem,
1. emacs -Q
2. M-: (set-fontset-font t 'tamil "Kurinto Seri")
3. M-s M-w https://www.dinamalar.com/news_detail.asp?id=2996410
4. C-x C-+ a bunch of times and look for clipped text. Sometimes
this does not reproduce the first time, so you end up having to
zoom out and in a few times.
> Thanks.
From the other mail:
> One more question: does this happen only with that particular font
> used for Tamil?
I tried Meera Inmai, Noto Serif Tamil, Noto Sans Tamil, Catamaran,
Kurinto Seri. Out of which only Noto Serif and Kurinto Seri shows the
problem. Maybe it is a font issue after all? but (Ungoogled) Chromium
which uses harfbuzz AFAICT renders the text just fine.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 16:50:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: 54646 <at> debbugs.gnu.org
> Date: Thu, 31 Mar 2022 20:37:10 +0530
>
> > One more question: does this happen only with that particular font
> > used for Tamil?
>
> I tried Meera Inmai, Noto Serif Tamil, Noto Sans Tamil, Catamaran,
> Kurinto Seri. Out of which only Noto Serif and Kurinto Seri shows the
> problem. Maybe it is a font issue after all? but (Ungoogled) Chromium
> which uses harfbuzz AFAICT renders the text just fine.
We also render the text just fine -- until you resize it with
text-scale-adjust.
Anyway, according to this:
http://www.kurinto.com/download.htm
Kurinto fonts are a 3.1GB download! Is there some place where I can
get away with downloading just the font for Tamil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 31 Mar 2022 17:39:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 54646 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 31 Mar 2022 19:49:28 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> I tried Meera Inmai, Noto Serif Tamil, Noto Sans Tamil, Catamaran,
>> Kurinto Seri. Out of which only Noto Serif and Kurinto Seri shows the
>> problem. Maybe it is a font issue after all? but (Ungoogled) Chromium
>> which uses harfbuzz AFAICT renders the text just fine.
Eli> We also render the text just fine -- until you resize it with
Eli> text-scale-adjust.
Eli> Anyway, according to this:
Eli> http://www.kurinto.com/download.htm
Eli> Kurinto fonts are a 3.1GB download! Is there some place where I can
Eli> get away with downloading just the font for Tamil?
Iʼve tried here with Noto Serif Tamil and canʼt reproduce it, but Iʼm
only on harfbuzz 3.7.4. I think I have a box somewhere with 4.1.0,
Iʼll try there.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 01:06:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் மார்ச் 31, 2022] Robert Pluim wrote:
>>>>>> On Thu, 31 Mar 2022 19:49:28 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> >> I tried Meera Inmai, Noto Serif Tamil, Noto Sans Tamil, Catamaran,
> >> Kurinto Seri. Out of which only Noto Serif and Kurinto Seri shows the
> >> problem. Maybe it is a font issue after all? but (Ungoogled) Chromium
> >> which uses harfbuzz AFAICT renders the text just fine.
>
> Eli> We also render the text just fine -- until you resize it with
> Eli> text-scale-adjust.
>
> Eli> Anyway, according to this:
>
> Eli> http://www.kurinto.com/download.htm
>
> Eli> Kurinto fonts are a 3.1GB download! Is there some place where I can
> Eli> get away with downloading just the font for Tamil?
>
Since Kurinto Seri with all its weight comes around 12M in tar.gz, I
uploaded it here http://0x0.st/oq6O.bin instead of attaching it.
> Iʼve tried here with Noto Serif Tamil and canʼt reproduce it, but Iʼm
> only on harfbuzz 3.7.4. I think I have a box somewhere with 4.1.0,
> Iʼll try there.
>
I've only tried on versions lower than yours. I will try a newer
version than what's in nixpkgs, and report back.
> Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 03:09:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி ஏப்ரல் 01, 2022] Visuwesh wrote:
> [வியாழன் மார்ச் 31, 2022] Robert Pluim wrote:
>
>> Iʼve tried here with Noto Serif Tamil and canʼt reproduce it, but Iʼm
>> only on harfbuzz 3.7.4. I think I have a box somewhere with 4.1.0,
>> Iʼll try there.
>>
>
> I've only tried on versions lower than yours. I will try a newer
> version than what's in nixpkgs, and report back.
>
I can reproduce it in HarfBuzz 4.2.0. Maybe this could be related to
the toolkit being used? I have only tested so far with Lucid. I will
try GTK some time later.
>> Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 08:50:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 54646 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 01 Apr 2022 08:38:10 +0530, Visuwesh <visuweshm <at> gmail.com> said:
Visuwesh> [வெள்ளி ஏப்ரல் 01, 2022] Visuwesh wrote:
>> [வியாழன் மார்ச் 31, 2022] Robert Pluim wrote:
>>
>>> Iʼve tried here with Noto Serif Tamil and canʼt reproduce it, but Iʼm
>>> only on harfbuzz 3.7.4. I think I have a box somewhere with 4.1.0,
>>> Iʼll try there.
>>>
>>
>> I've only tried on versions lower than yours. I will try a newer
>> version than what's in nixpkgs, and report back.
>>
Visuwesh> I can reproduce it in HarfBuzz 4.2.0. Maybe this could be related to
Visuwesh> the toolkit being used? I have only tested so far with Lucid. I will
Visuwesh> try GTK some time later.
Iʼve managed to reproduce this, but only once, with HarfBuzz 4.2.0
using lucid and Kurinto Seri. I guess that points more at HarfBuzz
than at Emacs, but maybe the lucid build is doing things slightly
differently to gtk.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 10:54:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 54646 <at> debbugs.gnu.org,Eli Zaretskii <eliz <at> gnu.org>
> Date: Fri, 01 Apr 2022 10:49:21 +0200
>
> Visuwesh> I can reproduce it in HarfBuzz 4.2.0. Maybe this could be related to
> Visuwesh> the toolkit being used? I have only tested so far with Lucid. I will
> Visuwesh> try GTK some time later.
>
> Iʼve managed to reproduce this, but only once, with HarfBuzz 4.2.0
> using lucid and Kurinto Seri. I guess that points more at HarfBuzz
> than at Emacs, but maybe the lucid build is doing things slightly
> differently to gtk.
I think at this point we need to establish whether we pass the same
information to HarfBuzz in the "good" and the "bad" cases. In
particular, we tell it how to scale the glyph metrics:
hb_font_t *hb_font
= font->driver->begin_hb_font
? font->driver->begin_hb_font (font, &position_unit)
: NULL;
The value of position_unit then affects the values returned in the
Lisp glyph object used to display the grapheme cluster:
xoff = lround (pos[i].x_offset * position_unit);
yoff = - lround (pos[i].y_offset * position_unit);
wadjust = lround (pos[i].x_advance * position_unit);
if (xoff || yoff || wadjust != metrics.width)
LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
make_fixnum (xoff),
make_fixnum (yoff),
make_fixnum (wadjust)));
I'd be interested in what happens there in the "good" vs the "bad"
cases.
If we pass the same information to HarfBuzz, and it returns different
results, then it's probably a problem in HarfBuzz.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 11:40:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி ஏப்ரல் 01, 2022] Eli Zaretskii wrote:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org,Eli Zaretskii <eliz <at> gnu.org>
>> Date: Fri, 01 Apr 2022 10:49:21 +0200
>>
>> Visuwesh> I can reproduce it in HarfBuzz 4.2.0. Maybe this could be related to
>> Visuwesh> the toolkit being used? I have only tested so far with Lucid. I will
>> Visuwesh> try GTK some time later.
>>
>> Iʼve managed to reproduce this, but only once, with HarfBuzz 4.2.0
>> using lucid and Kurinto Seri. I guess that points more at HarfBuzz
>> than at Emacs, but maybe the lucid build is doing things slightly
>> differently to gtk.
>
> I think at this point we need to establish whether we pass the same
> information to HarfBuzz in the "good" and the "bad" cases. In
> particular, we tell it how to scale the glyph metrics:
>
> hb_font_t *hb_font
> = font->driver->begin_hb_font
> ? font->driver->begin_hb_font (font, &position_unit)
> : NULL;
>
> The value of position_unit then affects the values returned in the
> Lisp glyph object used to display the grapheme cluster:
>
> xoff = lround (pos[i].x_offset * position_unit);
> yoff = - lround (pos[i].y_offset * position_unit);
> wadjust = lround (pos[i].x_advance * position_unit);
> if (xoff || yoff || wadjust != metrics.width)
> LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
> make_fixnum (xoff),
> make_fixnum (yoff),
> make_fixnum (wadjust)));
>
> I'd be interested in what happens there in the "good" vs the "bad"
> cases.
>
> If we pass the same information to HarfBuzz, and it returns different
> results, then it's probably a problem in HarfBuzz.
If you can give some instructions on how to get started, I can try
getting the value of position_unit in the good and the bad cases.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 12:15:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Robert Pluim <rpluim <at> gmail.com>, 54646 <at> debbugs.gnu.org
> Date: Fri, 01 Apr 2022 17:08:59 +0530
>
> > I think at this point we need to establish whether we pass the same
> > information to HarfBuzz in the "good" and the "bad" cases. In
> > particular, we tell it how to scale the glyph metrics:
> >
> > hb_font_t *hb_font
> > = font->driver->begin_hb_font
> > ? font->driver->begin_hb_font (font, &position_unit)
> > : NULL;
> >
> > The value of position_unit then affects the values returned in the
> > Lisp glyph object used to display the grapheme cluster:
> >
> > xoff = lround (pos[i].x_offset * position_unit);
> > yoff = - lround (pos[i].y_offset * position_unit);
> > wadjust = lround (pos[i].x_advance * position_unit);
> > if (xoff || yoff || wadjust != metrics.width)
> > LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
> > make_fixnum (xoff),
> > make_fixnum (yoff),
> > make_fixnum (wadjust)));
> >
> > I'd be interested in what happens there in the "good" vs the "bad"
> > cases.
> >
> > If we pass the same information to HarfBuzz, and it returns different
> > results, then it's probably a problem in HarfBuzz.
>
> If you can give some instructions on how to get started, I can try
> getting the value of position_unit in the good and the bad cases.
I don't think I understand where to begin the instructions. Are you
familiar with running Emacs under GDB and debugging the C code? If
so, setting a breakpoint in the code which I quoted (it's in hbfont.c)
and showing the values in both the "good" and the "bad" cases is what
we need.
Alternatively, you could add printf statements in that code which
would output those values to stdout or stderr streams.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 13:11:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி ஏப்ரல் 01, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: Robert Pluim <rpluim <at> gmail.com>, 54646 <at> debbugs.gnu.org
>> Date: Fri, 01 Apr 2022 17:08:59 +0530
>>
>> > I think at this point we need to establish whether we pass the same
>> > information to HarfBuzz in the "good" and the "bad" cases. In
>> > particular, we tell it how to scale the glyph metrics:
>> >
>> > hb_font_t *hb_font
>> > = font->driver->begin_hb_font
>> > ? font->driver->begin_hb_font (font, &position_unit)
>> > : NULL;
>> >
>> > The value of position_unit then affects the values returned in the
>> > Lisp glyph object used to display the grapheme cluster:
>> >
>> > xoff = lround (pos[i].x_offset * position_unit);
>> > yoff = - lround (pos[i].y_offset * position_unit);
>> > wadjust = lround (pos[i].x_advance * position_unit);
>> > if (xoff || yoff || wadjust != metrics.width)
>> > LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
>> > make_fixnum (xoff),
>> > make_fixnum (yoff),
>> > make_fixnum (wadjust)));
>> >
>> > I'd be interested in what happens there in the "good" vs the "bad"
>> > cases.
>> >
>> > If we pass the same information to HarfBuzz, and it returns different
>> > results, then it's probably a problem in HarfBuzz.
>>
>> If you can give some instructions on how to get started, I can try
>> getting the value of position_unit in the good and the bad cases.
>
> I don't think I understand where to begin the instructions. Are you
> familiar with running Emacs under GDB and debugging the C code?
Unfortunately not, but the printf option sounds feasible. So I will do
that.
> If so, setting a breakpoint in the code which I quoted (it's in
> hbfont.c) and showing the values in both the "good" and the "bad"
> cases is what we need.
>
I get two matches for the first snippet: in hbfont_shape and in
hbfont_otf_capability. I assume I have to check the one in
hbfont_shape?
> Alternatively, you could add printf statements in that code which
> would output those values to stdout or stderr streams.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 14:20:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Fri, 01 Apr 2022 18:40:30 +0530
>
> I get two matches for the first snippet: in hbfont_shape and in
> hbfont_otf_capability. I assume I have to check the one in
> hbfont_shape?
Yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 14:59:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Friday April 01, 2022] Eli Zaretskii wrote:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org,Eli Zaretskii <eliz <at> gnu.org>
>> Date: Fri, 01 Apr 2022 10:49:21 +0200
>>
>> Visuwesh> I can reproduce it in HarfBuzz 4.2.0. Maybe this could be related to
>> Visuwesh> the toolkit being used? I have only tested so far with Lucid. I will
>> Visuwesh> try GTK some time later.
>>
>> Iʼve managed to reproduce this, but only once, with HarfBuzz 4.2.0
>> using lucid and Kurinto Seri. I guess that points more at HarfBuzz
>> than at Emacs, but maybe the lucid build is doing things slightly
>> differently to gtk.
>
> I think at this point we need to establish whether we pass the same
> information to HarfBuzz in the "good" and the "bad" cases. In
> particular, we tell it how to scale the glyph metrics:
>
> hb_font_t *hb_font
> = font->driver->begin_hb_font
> ? font->driver->begin_hb_font (font, &position_unit)
> : NULL;
>
> The value of position_unit then affects the values returned in the
> Lisp glyph object used to display the grapheme cluster:
>
> xoff = lround (pos[i].x_offset * position_unit);
> yoff = - lround (pos[i].y_offset * position_unit);
> wadjust = lround (pos[i].x_advance * position_unit);
> if (xoff || yoff || wadjust != metrics.width)
> LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
> make_fixnum (xoff),
> make_fixnum (yoff),
> make_fixnum (wadjust)));
>
> I'd be interested in what happens there in the "good" vs the "bad"
> cases.
>
> If we pass the same information to HarfBuzz, and it returns different
> results, then it's probably a problem in HarfBuzz.
I get the same value for position_unit just after begin_hb_font call and
just after setting the value of wadjust, in the bad and the good case:
0.015625. In case I was not clear, here's a patch that shows where I
added the printf calls
diff --git a/src/hbfont.c b/src/hbfont.c
index 2721a66120..887e0c0e86 100644
--- a/src/hbfont.c
+++ b/src/hbfont.c
@@ -490,6 +490,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
: NULL;
if (!hb_font)
return make_fixnum (0);
+ printf("position_unit begin_hb_font: %f\n", position_unit);
hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL);
if (font->driver->end_hb_font)
@@ -593,6 +594,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
xoff = lround (pos[i].x_offset * position_unit);
yoff = - lround (pos[i].y_offset * position_unit);
wadjust = lround (pos[i].x_advance * position_unit);
+ printf("position_unit after lround: %f\n", position_unit);
if (xoff || yoff || wadjust != metrics.width)
LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
make_fixnum (xoff),
So I see "position_unit begin_hb_font: 0.0015625" and "position_unit
after lround: 0.0015625" in the good and the bad case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 15:28:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Robert Pluim <rpluim <at> gmail.com>, 54646 <at> debbugs.gnu.org
> Date: Fri, 01 Apr 2022 20:28:06 +0530
>
> > hb_font_t *hb_font
> > = font->driver->begin_hb_font
> > ? font->driver->begin_hb_font (font, &position_unit)
> > : NULL;
> >
> > The value of position_unit then affects the values returned in the
> > Lisp glyph object used to display the grapheme cluster:
> >
> > xoff = lround (pos[i].x_offset * position_unit);
> > yoff = - lround (pos[i].y_offset * position_unit);
> > wadjust = lround (pos[i].x_advance * position_unit);
> > if (xoff || yoff || wadjust != metrics.width)
> > LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
> > make_fixnum (xoff),
> > make_fixnum (yoff),
> > make_fixnum (wadjust)));
> >
> > I'd be interested in what happens there in the "good" vs the "bad"
> > cases.
> >
> > If we pass the same information to HarfBuzz, and it returns different
> > results, then it's probably a problem in HarfBuzz.
>
> I get the same value for position_unit just after begin_hb_font call and
> just after setting the value of wadjust, in the bad and the good case:
> 0.015625. In case I was not clear, here's a patch that shows where I
> added the printf calls
>
> diff --git a/src/hbfont.c b/src/hbfont.c
> index 2721a66120..887e0c0e86 100644
> --- a/src/hbfont.c
> +++ b/src/hbfont.c
> @@ -490,6 +490,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
> : NULL;
> if (!hb_font)
> return make_fixnum (0);
> + printf("position_unit begin_hb_font: %f\n", position_unit);
>
> hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL);
> if (font->driver->end_hb_font)
> @@ -593,6 +594,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
> xoff = lround (pos[i].x_offset * position_unit);
> yoff = - lround (pos[i].y_offset * position_unit);
> wadjust = lround (pos[i].x_advance * position_unit);
> + printf("position_unit after lround: %f\n", position_unit);
> if (xoff || yoff || wadjust != metrics.width)
> LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
> make_fixnum (xoff),
>
> So I see "position_unit begin_hb_font: 0.0015625" and "position_unit
> after lround: 0.0015625" in the good and the bad case.
So we pass the same data to HarfBuzz and get back different results in
xoff, yoff, and wadjust? IOW, the results of shaping are different in
the two cases, although the inputs are identical? Can you print the
other values involved in the data that gets put into lglyph, and see
whether any of it is different between the two cases?
the lglyph data is shown in this excerpt from the code:
LGLYPH_SET_CHAR (lglyph, chars[char_idx]);
LGLYPH_SET_CODE (lglyph, info[i].codepoint);
unsigned code = info[i].codepoint;
font->driver->text_extents (font, &code, 1, &metrics);
LGLYPH_SET_WIDTH (lglyph, metrics.width);
LGLYPH_SET_LBEARING (lglyph, metrics.lbearing);
LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
LGLYPH_SET_DESCENT (lglyph, metrics.descent);
xoff = lround (pos[i].x_offset * position_unit);
yoff = - lround (pos[i].y_offset * position_unit);
wadjust = lround (pos[i].x_advance * position_unit);
if (xoff || yoff || wadjust != metrics.width)
LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
make_fixnum (xoff),
make_fixnum (yoff),
make_fixnum (wadjust)));
WHat is different between the two cases in this data? Does the call
to font->driver->text_extents produce different data in 'metrics',
perhaps? Do the values in pos[i] structure differ? Something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 16:42:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[Friday April 01, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: Robert Pluim <rpluim <at> gmail.com>, 54646 <at> debbugs.gnu.org
>> Date: Fri, 01 Apr 2022 20:28:06 +0530
>>
>> > hb_font_t *hb_font
>> > = font->driver->begin_hb_font
>> > ? font->driver->begin_hb_font (font, &position_unit)
>> > : NULL;
>> >
>> > The value of position_unit then affects the values returned in the
>> > Lisp glyph object used to display the grapheme cluster:
>> >
>> > xoff = lround (pos[i].x_offset * position_unit);
>> > yoff = - lround (pos[i].y_offset * position_unit);
>> > wadjust = lround (pos[i].x_advance * position_unit);
>> > if (xoff || yoff || wadjust != metrics.width)
>> > LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
>> > make_fixnum (xoff),
>> > make_fixnum (yoff),
>> > make_fixnum (wadjust)));
>> >
>> > I'd be interested in what happens there in the "good" vs the "bad"
>> > cases.
>> >
>> > If we pass the same information to HarfBuzz, and it returns different
>> > results, then it's probably a problem in HarfBuzz.
>>
>> I get the same value for position_unit just after begin_hb_font call and
>> just after setting the value of wadjust, in the bad and the good case:
>> 0.015625. In case I was not clear, here's a patch that shows where I
>> added the printf calls
>>
>> diff --git a/src/hbfont.c b/src/hbfont.c
>> index 2721a66120..887e0c0e86 100644
>> --- a/src/hbfont.c
>> +++ b/src/hbfont.c
>> @@ -490,6 +490,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
>> : NULL;
>> if (!hb_font)
>> return make_fixnum (0);
>> + printf("position_unit begin_hb_font: %f\n", position_unit);
>>
>> hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL);
>> if (font->driver->end_hb_font)
>> @@ -593,6 +594,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
>> xoff = lround (pos[i].x_offset * position_unit);
>> yoff = - lround (pos[i].y_offset * position_unit);
>> wadjust = lround (pos[i].x_advance * position_unit);
>> + printf("position_unit after lround: %f\n", position_unit);
>> if (xoff || yoff || wadjust != metrics.width)
>> LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
>> make_fixnum (xoff),
>>
>> So I see "position_unit begin_hb_font: 0.0015625" and "position_unit
>> after lround: 0.0015625" in the good and the bad case.
>
> So we pass the same data to HarfBuzz and get back different results in
> xoff, yoff, and wadjust?
>
> IOW, the results of shaping are different in the two cases, although
> the inputs are identical? Can you print the other values involved in
> the data that gets put into lglyph, and see whether any of it is
> different between the two cases?
>
> the lglyph data is shown in this excerpt from the code:
>
> LGLYPH_SET_CHAR (lglyph, chars[char_idx]);
> LGLYPH_SET_CODE (lglyph, info[i].codepoint);
>
> unsigned code = info[i].codepoint;
> font->driver->text_extents (font, &code, 1, &metrics);
> LGLYPH_SET_WIDTH (lglyph, metrics.width);
> LGLYPH_SET_LBEARING (lglyph, metrics.lbearing);
> LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
> LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
> LGLYPH_SET_DESCENT (lglyph, metrics.descent);
>
> xoff = lround (pos[i].x_offset * position_unit);
> yoff = - lround (pos[i].y_offset * position_unit);
> wadjust = lround (pos[i].x_advance * position_unit);
> if (xoff || yoff || wadjust != metrics.width)
> LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
> make_fixnum (xoff),
> make_fixnum (yoff),
> make_fixnum (wadjust)));
>
> WHat is different between the two cases in this data? Does the call
> to font->driver->text_extents produce different data in 'metrics',
> perhaps? Do the values in pos[i] structure differ? Something else?
TBH, I'm not even sure if I am comparing the data for the same set of
characters but AFAICT, the values don't seem to differ. Is there a way
to print the concerned character so I can make better comparisons?
I don't think it is of any help but I attached two text files: bad-case
and good-case. bad-case has all the data for the clipped text, and
good-case for the non-clipped text (for the same font size, at least I
hope so...).
[bad-case (text/plain, attachment)]
[good-case (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 01 Apr 2022 17:58:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Fri, 01 Apr 2022 22:10:54 +0530
>
> > WHat is different between the two cases in this data? Does the call
> > to font->driver->text_extents produce different data in 'metrics',
> > perhaps? Do the values in pos[i] structure differ? Something else?
>
> TBH, I'm not even sure if I am comparing the data for the same set of
> characters but AFAICT the values don't seem to differ. Is there a way
> to print the concerned character so I can make better comparisons?
The character codepoints are in the chars[] array, AFAIR.
If the input to HarfBuzz is identical, but the output isn't, it points
to a HarfBuzz bug.
> I don't think it is of any help but I attached two text files: bad-case
> and good-case. bad-case has all the data for the clipped text, and
> good-case for the non-clipped text (for the same font size, at least I
> hope so...).
It's hard to understand what you printed out, or where is the
difference. It is best to print only the data for the characters for
which you see display problems, because all the rest is just clutter.
And in any case, please print the character with the data, otherwise
it is impossible to know what to compare.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 03 Apr 2022 09:17:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[Friday April 01, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
>> Date: Fri, 01 Apr 2022 22:10:54 +0530
>>
>> > WHat is different between the two cases in this data? Does the call
>> > to font->driver->text_extents produce different data in 'metrics',
>> > perhaps? Do the values in pos[i] structure differ? Something else?
>>
>> TBH, I'm not even sure if I am comparing the data for the same set of
>> characters but AFAICT the values don't seem to differ. Is there a way
>> to print the concerned character so I can make better comparisons?
>
> The character codepoints are in the chars[] array, AFAIR.
>
> If the input to HarfBuzz is identical, but the output isn't, it points
> to a HarfBuzz bug.
>
>> I don't think it is of any help but I attached two text files: bad-case
>> and good-case. bad-case has all the data for the clipped text, and
>> good-case for the non-clipped text (for the same font size, at least I
>> hope so...).
>
> It's hard to understand what you printed out, or where is the
> difference. It is best to print only the data for the characters for
> which you see display problems, because all the rest is just clutter.
> And in any case, please print the character with the data, otherwise
> it is impossible to know what to compare.
I used the %c printf format control to print the character in
question---chars[char_idx]. comment-section-good is the "good" case and
comment-section-bad is the "bad" case. The URL I browsed in eww is
https://www.dinamalar.com/news_detail.asp?id=2998931 (isearch for
"Suppon" to get to the comment section). Unfortunately, all the
characters are in raw bytes so if there's a better to print the
characters, please let me know.
[ "# .*" in the last line are just markers I used. ]
[comment-section-bad (text/plain, attachment)]
[comment-section-good (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 03 Apr 2022 10:08:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Sun, 03 Apr 2022 14:45:35 +0530
>
> > It's hard to understand what you printed out, or where is the
> > difference. It is best to print only the data for the characters for
> > which you see display problems, because all the rest is just clutter.
> > And in any case, please print the character with the data, otherwise
> > it is impossible to know what to compare.
>
> I used the %c printf format control to print the character in
> question---chars[char_idx]. comment-section-good is the "good" case and
> comment-section-bad is the "bad" case. The URL I browsed in eww is
> https://www.dinamalar.com/news_detail.asp?id=2998931 (isearch for
> "Suppon" to get to the comment section). Unfortunately, all the
> characters are in raw bytes so if there's a better to print the
> characters, please let me know.
The %c format is only good for single-byte characters, which these
ones aren't. Please use %x to print them (in hex).
Also, I think printing everything is too much, and doesn't allow to
focus. Please print only when the character's code is one of those
involved in the problematic display. "C-u C-x =" will tell you the
codepoints of the characters involved: the one that is displayed
incorrectly and the ones surrounding it: please add an 'if' clause
there which would only print the metrics data for the characters in
which we are interested. Something like this:
if (chars[char_idx] == CHAR1
|| chars[char_idx] == CHAR2
|| chars[char_idx] == CHAR3)
printf (...
where CHAR1, CHAR2, and CHAR3 are the characters involved in the
problematic display, according to "C-u C-x =".
May I suggest that you show me the code you add to hbfont.c before you
run it? This would avoid unnecessary iterations for you.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 03 Apr 2022 10:28:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Sunday April 03, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
>> Date: Sun, 03 Apr 2022 14:45:35 +0530
>>
>> > It's hard to understand what you printed out, or where is the
>> > difference. It is best to print only the data for the characters for
>> > which you see display problems, because all the rest is just clutter.
>> > And in any case, please print the character with the data, otherwise
>> > it is impossible to know what to compare.
>>
>> I used the %c printf format control to print the character in
>> question---chars[char_idx]. comment-section-good is the "good" case and
>> comment-section-bad is the "bad" case. The URL I browsed in eww is
>> https://www.dinamalar.com/news_detail.asp?id=2998931 (isearch for
>> "Suppon" to get to the comment section). Unfortunately, all the
>> characters are in raw bytes so if there's a better to print the
>> characters, please let me know.
>
> The %c format is only good for single-byte characters, which these
> ones aren't. Please use %x to print them (in hex).
>
Will do, thanks.
> Also, I think printing everything is too much, and doesn't allow to
> focus. Please print only when the character's code is one of those
> involved in the problematic display.
Unfortunately, the characters that are problematic tend to differ from
each run. Nevertheless, I will hand-pick the problematic characters and
send it.
> "C-u C-x =" will tell you the codepoints of the characters involved:
> the one that is displayed incorrectly and the ones surrounding it:
> please add an 'if' clause there which would only print the metrics
> data for the characters in which we are interested. Something like
> this:
>
> if (chars[char_idx] == CHAR1
> || chars[char_idx] == CHAR2
> || chars[char_idx] == CHAR3)
> printf (...
>
> where CHAR1, CHAR2, and CHAR3 are the characters involved in the
> problematic display, according to "C-u C-x =".
>
> May I suggest that you show me the code you add to hbfont.c before you
> run it? This would avoid unnecessary iterations for you.
>
Sure,
diff --git a/src/hbfont.c b/src/hbfont.c
index 2721a66120..ad6838b19a 100644
--- a/src/hbfont.c
+++ b/src/hbfont.c
@@ -490,6 +490,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
: NULL;
if (!hb_font)
return make_fixnum (0);
+ printf("position_unit begin_hb_font: %f\n", position_unit);
hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL);
if (font->driver->end_hb_font)
@@ -589,10 +590,15 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
LGLYPH_SET_DESCENT (lglyph, metrics.descent);
+ printf("lbearing %d rbearing %d width %d ascent %d descent %d\n",
+ metrics.lbearing, metrics.rbearing, metrics.width, metrics.ascent, metrics.descent);
xoff = lround (pos[i].x_offset * position_unit);
yoff = - lround (pos[i].y_offset * position_unit);
wadjust = lround (pos[i].x_advance * position_unit);
+ printf("char %x xadvance %d yadvance %d xoffset %d yoffset %d\n",
+ chars[char_idx], pos[i].x_advance, pos[i].y_advance, pos[i].x_offset, pos[i].y_offset);
+ printf("xpos %d yoff %d wadjust %d\n", xoff, yoff, wadjust);
if (xoff || yoff || wadjust != metrics.width)
LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
make_fixnum (xoff),
> Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 03 Apr 2022 10:52:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Sun, 03 Apr 2022 15:56:35 +0530
>
> > The %c format is only good for single-byte characters, which these
> > ones aren't. Please use %x to print them (in hex).
> >
>
> Will do, thanks.
>
> > Also, I think printing everything is too much, and doesn't allow to
> > focus. Please print only when the character's code is one of those
> > involved in the problematic display.
>
> Unfortunately, the characters that are problematic tend to differ from
> each run. Nevertheless, I will hand-pick the problematic characters and
> send it.
That'd be good. We need a reproducible case to work with.
> > if (chars[char_idx] == CHAR1
> > || chars[char_idx] == CHAR2
> > || chars[char_idx] == CHAR3)
> > printf (...
> >
> > where CHAR1, CHAR2, and CHAR3 are the characters involved in the
> > problematic display, according to "C-u C-x =".
> >
> > May I suggest that you show me the code you add to hbfont.c before you
> > run it? This would avoid unnecessary iterations for you.
> >
>
> Sure,
This is okay, but please don't forget to add that 'if' condition. I
think the characters involved in the composition, and in addition one
character on each side of those, should be enough.
Please show the final code, so that I could then interpret the
print-outs correctly.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 03 Apr 2022 11:11:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Sunday April 03, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
>> Date: Sun, 03 Apr 2022 15:56:35 +0530
>>
>> > The %c format is only good for single-byte characters, which these
>> > ones aren't. Please use %x to print them (in hex).
>> >
>>
>> Will do, thanks.
>>
>> > Also, I think printing everything is too much, and doesn't allow to
>> > focus. Please print only when the character's code is one of those
>> > involved in the problematic display.
>>
>> Unfortunately, the characters that are problematic tend to differ from
>> each run. Nevertheless, I will hand-pick the problematic characters and
>> send it.
>
> That'd be good. We need a reproducible case to work with.
>
>> > if (chars[char_idx] == CHAR1
>> > || chars[char_idx] == CHAR2
>> > || chars[char_idx] == CHAR3)
>> > printf (...
>> >
>> > where CHAR1, CHAR2, and CHAR3 are the characters involved in the
>> > problematic display, according to "C-u C-x =".
>> >
>> > May I suggest that you show me the code you add to hbfont.c before you
>> > run it? This would avoid unnecessary iterations for you.
>> >
>>
>> Sure,
>
> This is okay, but please don't forget to add that 'if' condition. I
> think the characters involved in the composition, and in addition one
> character on each side of those, should be enough.
It seems like I did not get my point across: the characters that tend
to be rendered problematic differ from each run so I will hand-pick the
data for the problematic characters in _that_ run and send it.
>
> Please show the final code, so that I could then interpret the
> print-outs correctly.
>
> Thanks.
Considering the above, it would be
diff --git a/src/hbfont.c b/src/hbfont.c
index 2721a66120..9351359558 100644
--- a/src/hbfont.c
+++ b/src/hbfont.c
@@ -490,6 +490,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
: NULL;
if (!hb_font)
return make_fixnum (0);
+ printf("position_unit begin_hb_font: %f\n", position_unit);
hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL);
if (font->driver->end_hb_font)
@@ -589,10 +590,17 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
LGLYPH_SET_DESCENT (lglyph, metrics.descent);
+ printf("lbearing %d rbearing %d width %d ascent %d descent %d\n",
+ metrics.lbearing, metrics.rbearing, metrics.width, metrics.ascent, metrics.descent);
xoff = lround (pos[i].x_offset * position_unit);
yoff = - lround (pos[i].y_offset * position_unit);
wadjust = lround (pos[i].x_advance * position_unit);
+ printf("%x %x %x xadvance %d yadvance %d xoffset %d yoffset %d\n",
+ (chars_idx == 0 ? 1 : chars[char_idx-1]), chars[char_idx],
+ (chars_idx == glyph_len-1 ? 1 : chars[char_idx+1]),
+ pos[i].x_advance, pos[i].y_advance, pos[i].x_offset, pos[i].y_offset);
+ printf("xpos %d yoff %d wadjust %d\n", xoff, yoff, wadjust);
if (xoff || yoff || wadjust != metrics.width)
LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
make_fixnum (xoff),
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Thu, 21 Apr 2022 14:52:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[ஞாயிறு ஏப்ரல் 03, 2022] Visuwesh wrote:
> [Sunday April 03, 2022] Eli Zaretskii wrote:
>
>>> From: Visuwesh <visuweshm <at> gmail.com>
>>> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
>>> Date: Sun, 03 Apr 2022 15:56:35 +0530
>>>
>>> > The %c format is only good for single-byte characters, which these
>>> > ones aren't. Please use %x to print them (in hex).
>>> >
>>>
>>> Will do, thanks.
>>>
>>> > Also, I think printing everything is too much, and doesn't allow to
>>> > focus. Please print only when the character's code is one of those
>>> > involved in the problematic display.
>>>
>>> Unfortunately, the characters that are problematic tend to differ from
>>> each run. Nevertheless, I will hand-pick the problematic characters and
>>> send it.
>>
>> That'd be good. We need a reproducible case to work with.
>>
>>> > if (chars[char_idx] == CHAR1
>>> > || chars[char_idx] == CHAR2
>>> > || chars[char_idx] == CHAR3)
>>> > printf (...
>>> >
>>> > where CHAR1, CHAR2, and CHAR3 are the characters involved in the
>>> > problematic display, according to "C-u C-x =".
>>> >
>>> > May I suggest that you show me the code you add to hbfont.c before you
>>> > run it? This would avoid unnecessary iterations for you.
>>> >
>>>
>>> Sure,
>>
>> This is okay, but please don't forget to add that 'if' condition. I
>> think the characters involved in the composition, and in addition one
>> character on each side of those, should be enough.
>
> It seems like I did not get my point across: the characters that tend
> to be rendered problematic differ from each run so I will hand-pick the
> data for the problematic characters in _that_ run and send it.
>
>>
>> Please show the final code, so that I could then interpret the
>> print-outs correctly.
>>
>> Thanks.
>
> Considering the above, it would be
>
> [....]
It took me eons to do this again, I apologise for that. There's one
thing that I noticed about this issue: when I use this webpage
https://www.dinamalar.com/news_detail.asp?id=3012739 as a test page and
I let _all_ the scaled characters in that page be displayed, I cannot
reproduce the issue but if I let only some of the scaled characters in
that page be displayed and go to a part that was never displayed before,
the characters there have the "bad" shaping. I'm writing this here
in the hopes that it might help in debugging.
I was not successful in getting the data for all offending sequences.
The offending sequences were,
bb9 bbf -- ஹி
ba9 bc1 -- னு
bb5 bbf -- வி
b86 -- ஆ
and the GOOD case for bb9 bbf is
lbearing 1 rbearing 28 width 28 ascent 9 descent 5
1 bb9 bbf xadvance 1809 yadvance 0 xoffset 0 yoffset 0
xpos 0 yoff 0 wadjust 28
and the BAD case is
lbearing 1 rbearing 28 width 28 ascent 9 descent 5
1 bb9 bbf xadvance 3193 yadvance 0 xoffset 0 yoffset 0
xpos 0 yoff 0 wadjust 50
If you want more data, then I can try repeating this (I did not retry
since it is really tedious).
The data is for -Goss-Kurinto Seri-regular-normal-normal-*-17-*-*-*-*-0-iso10646-1
and HarfBuzz version is still at 4.2.0.
The patch I used is
diff --git a/src/hbfont.c b/src/hbfont.c
index 2721a66120..9432f75bbf 100644
--- a/src/hbfont.c
+++ b/src/hbfont.c
@@ -490,6 +490,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
: NULL;
if (!hb_font)
return make_fixnum (0);
+ printf("position_unit begin_hb_font: %f\n", position_unit);
hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL);
if (font->driver->end_hb_font)
@@ -589,10 +590,17 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
LGLYPH_SET_DESCENT (lglyph, metrics.descent);
+ printf("lbearing %d rbearing %d width %d ascent %d descent %d\n",
+ metrics.lbearing, metrics.rbearing, metrics.width, metrics.ascent, metrics.descent);
xoff = lround (pos[i].x_offset * position_unit);
yoff = - lround (pos[i].y_offset * position_unit);
wadjust = lround (pos[i].x_advance * position_unit);
+ printf("%x %x %x xadvance %d yadvance %d xoffset %d yoffset %d\n",
+ (char_idx == 0 ? 1 : chars[char_idx-1]), chars[char_idx],
+ (char_idx == glyph_len-1 ? 1 : chars[char_idx+1]),
+ pos[i].x_advance, pos[i].y_advance, pos[i].x_offset, pos[i].y_offset);
+ printf("xpos %d yoff %d wadjust %d\n", xoff, yoff, wadjust);
if (xoff || yoff || wadjust != metrics.width)
LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
make_fixnum (xoff),
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 22 Apr 2022 07:24:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Thu, 21 Apr 2022 20:20:45 +0530
>
> I was not successful in getting the data for all offending sequences.
> The offending sequences were,
>
> bb9 bbf -- ஹி
> ba9 bc1 -- னு
> bb5 bbf -- வி
> b86 -- ஆ
>
> and the GOOD case for bb9 bbf is
>
> lbearing 1 rbearing 28 width 28 ascent 9 descent 5
> 1 bb9 bbf xadvance 1809 yadvance 0 xoffset 0 yoffset 0
> xpos 0 yoff 0 wadjust 28
>
> and the BAD case is
>
> lbearing 1 rbearing 28 width 28 ascent 9 descent 5
> 1 bb9 bbf xadvance 3193 yadvance 0 xoffset 0 yoffset 0
> xpos 0 yoff 0 wadjust 50
This looks like HarfBuzz is feeding us incorrect data for some reason,
but I cannot imagine what that reason could be, sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 22 Apr 2022 10:47:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி ஏப்ரல் 22, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
>> Date: Thu, 21 Apr 2022 20:20:45 +0530
>>
>> I was not successful in getting the data for all offending sequences.
>> The offending sequences were,
>>
>> bb9 bbf -- ஹி
>> ba9 bc1 -- னு
>> bb5 bbf -- வி
>> b86 -- ஆ
>>
>> and the GOOD case for bb9 bbf is
>>
>> lbearing 1 rbearing 28 width 28 ascent 9 descent 5
>> 1 bb9 bbf xadvance 1809 yadvance 0 xoffset 0 yoffset 0
>> xpos 0 yoff 0 wadjust 28
>>
>> and the BAD case is
>>
>> lbearing 1 rbearing 28 width 28 ascent 9 descent 5
>> 1 bb9 bbf xadvance 3193 yadvance 0 xoffset 0 yoffset 0
>> xpos 0 yoff 0 wadjust 50
>
> This looks like HarfBuzz is feeding us incorrect data for some reason,
> but I cannot imagine what that reason could be, sorry.
Could it be some kind of cache? Because when Emacs rendered the entire
webpage, I was unable to reproduce the issue. Then again,
(clear-composition-cache) did not help. and I was also able to
reproduce the issue with Noto Sans Tamil as well. Anyway, thanks for
looking into this. I will look into reporting it to the HarfBuzz devs
if you have no further comments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Fri, 22 Apr 2022 10:49:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Fri, 22 Apr 2022 16:16:07 +0530
>
> >> and the GOOD case for bb9 bbf is
> >>
> >> lbearing 1 rbearing 28 width 28 ascent 9 descent 5
> >> 1 bb9 bbf xadvance 1809 yadvance 0 xoffset 0 yoffset 0
> >> xpos 0 yoff 0 wadjust 28
> >>
> >> and the BAD case is
> >>
> >> lbearing 1 rbearing 28 width 28 ascent 9 descent 5
> >> 1 bb9 bbf xadvance 3193 yadvance 0 xoffset 0 yoffset 0
> >> xpos 0 yoff 0 wadjust 50
> >
> > This looks like HarfBuzz is feeding us incorrect data for some reason,
> > but I cannot imagine what that reason could be, sorry.
>
> Could it be some kind of cache? Because when Emacs rendered the entire
> webpage, I was unable to reproduce the issue.
When Emacs have rendered the entire page, we no longer call HarfBuzz,
because the composition data is indeed cached by Emacs.
The print-outs you produced are from calling HarfBuzz, so our caching
cannot affect that, AFAIU.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sat, 11 Jun 2022 13:55:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[வெள்ளி ஏப்ரல் 22, 2022] Eli Zaretskii wrote:
Hello Eli, Robert
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
>> Date: Fri, 22 Apr 2022 16:16:07 +0530
>>
>> >> and the GOOD case for bb9 bbf is
>> >>
>> >> lbearing 1 rbearing 28 width 28 ascent 9 descent 5
>> >> 1 bb9 bbf xadvance 1809 yadvance 0 xoffset 0 yoffset 0
>> >> xpos 0 yoff 0 wadjust 28
>> >>
>> >> and the BAD case is
>> >>
>> >> lbearing 1 rbearing 28 width 28 ascent 9 descent 5
>> >> 1 bb9 bbf xadvance 3193 yadvance 0 xoffset 0 yoffset 0
>> >> xpos 0 yoff 0 wadjust 50
>> >
>> > This looks like HarfBuzz is feeding us incorrect data for some reason,
>> > but I cannot imagine what that reason could be, sorry.
>>
>> Could it be some kind of cache? Because when Emacs rendered the entire
>> webpage, I was unable to reproduce the issue.
>
> When Emacs have rendered the entire page, we no longer call HarfBuzz,
> because the composition data is indeed cached by Emacs.
>
> The print-outs you produced are from calling HarfBuzz, so our caching
> cannot affect that, AFAIU.
I think this might be a cairo+pango problem. My suspicion is due to
this bug report https://github.com/harfbuzz/harfbuzz/issues/1892 --
although I don't see the problem with English text as shown in the
screenshots.
I tried to turn off font metrics in cairo by applying the following
patch,
[cairo-hint-metrics.diff (text/x-diff, attachment)]
[Message part 3 (text/plain, inline)]
but that did not solve the issue.
However, I have been using the xft+harfbuzz combo for a ~week now and I
can say with confidence that I don't experience this strange issue. I
would highly appreciate it if the decision to remove the xft backend
could be delayed until a solution comes up [1]. Although the font
rendering is worse, the text stays readable at all font sizes.
[1] ./configure --with-cairo says,
configure: WARNING: This configuration uses libXft, which has a number of
font rendering issues, and is being considered for removal in the
next release of Emacs. Please consider using Cairo graphics +
HarfBuzz text shaping instead (they are auto-detected if the
relevant development headers are installed).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 12 Jun 2022 01:35:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 54646 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
> However, I have been using the xft+harfbuzz combo for a ~week now and I
> can say with confidence that I don't experience this strange issue. I
> would highly appreciate it if the decision to remove the xft backend
> could be delayed until a solution comes up [1]. Although the font
> rendering is worse, the text stays readable at all font sizes.
>
>
> [1] ./configure --with-cairo says,
>
> configure: WARNING: This configuration uses libXft, which has a number of
> font rendering issues, and is being considered for removal in the
> next release of Emacs. Please consider using Cairo graphics +
> HarfBuzz text shaping instead (they are auto-detected if the
> relevant development headers are installed).
We will not remove the Xft font backend as long as I'm still using it,
which will be quite a while.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 12 Jun 2022 04:50:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[Saturday June 11, 2022] Visuwesh wrote:
> [வெள்ளி ஏப்ரல் 22, 2022] Eli Zaretskii wrote:
>
> I think this might be a cairo+pango problem. My suspicion is due to
> this bug report https://github.com/harfbuzz/harfbuzz/issues/1892 --
> although I don't see the problem with English text as shown in the
> screenshots.
>
> I tried to turn off font metrics in cairo by applying the following
> patch,
>
>
>
> but that did not solve the issue.
>
> However, I have been using the xft+harfbuzz combo for a ~week now and I
> can say with confidence that I don't experience this strange issue. I
> would highly appreciate it if the decision to remove the xft backend
> could be delayed until a solution comes up [1]. Although the font
> rendering is worse, the text stays readable at all font sizes.
>
>
> [1] ./configure --with-cairo says,
>
> configure: WARNING: This configuration uses libXft, which has a number of
> font rendering issues, and is being considered for removal in the
> next release of Emacs. Please consider using Cairo graphics +
> HarfBuzz text shaping instead (they are auto-detected if the
> relevant development headers are installed).
I forgot to mention: I tried the patch with cairo 1.17.4 to no avail either.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 12 Jun 2022 05:55:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Sat, 11 Jun 2022 19:24:16 +0530
>
> I think this might be a cairo+pango problem.
I don't see how Pango could be relevant: AFAIK we don't use any of it
in Emacs.
It could be a Cairo issue, in which case it is somewhere in the bowels
of Cairo, not in Emacs code proper.
> My suspicion is due to this bug report
> https://github.com/harfbuzz/harfbuzz/issues/1892 -- although I don't
> see the problem with English text as shown in the screenshots.
If this is the same issue, how come you sometimes see correctly laid
out text and sometimes incorrectly laid out text? Emacs doesn't
change anything in both situation, and I'm not aware of any handling
of "hinting" on our side.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 12 Jun 2022 05:56:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Sun, 12 Jun 2022 09:34:39 +0800
>
> > configure: WARNING: This configuration uses libXft, which has a number of
> > font rendering issues, and is being considered for removal in the
> > next release of Emacs. Please consider using Cairo graphics +
> > HarfBuzz text shaping instead (they are auto-detected if the
> > relevant development headers are installed).
>
> We will not remove the Xft font backend as long as I'm still using it,
> which will be quite a while.
That might be so, but libXft does have a number of grave issues that
aren't being fixed, so if you use that, you are at their mercy. You
HAVE been warned!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 12 Jun 2022 07:48:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[ஞாயிறு ஜூன் 12, 2022 08:53] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
>> Date: Sat, 11 Jun 2022 19:24:16 +0530
>>
>> I think this might be a cairo+pango problem.
>
> I don't see how Pango could be relevant: AFAIK we don't use any of it
> in Emacs.
>
I was under the impression that cairo used pango somewhere but,
% ldd /usr/lib/x86_64-linux-gnu/libcairo.so.2 |grep pango
returned nothing. However,
% ldd $(which emacs) |grep pango
libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f1c4401f000)
libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f1c43fb9000)
libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f1c4363f000)
> It could be a Cairo issue, in which case it is somewhere in the bowels
> of Cairo, not in Emacs code proper.
>
>> My suspicion is due to this bug report
>> https://github.com/harfbuzz/harfbuzz/issues/1892 -- although I don't
>> see the problem with English text as shown in the screenshots.
>
> If this is the same issue, how come you sometimes see correctly laid
> out text and sometimes incorrectly laid out text? Emacs doesn't
> change anything in both situation, and I'm not aware of any handling
> of "hinting" on our side.
AFAIU, the issue shows itself when Emacs renders some part of the Tamil
characters and but not all. This is a common case in eww: <hN> headers
are rendered in a slightly larger font size than the main body text.
Anyway, I don't think it is the same issue, but what I wanted to convey
by quoting that bug report is that it made suspect that the problem
might be in cairo or pango.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 12 Jun 2022 10:18:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 54646 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
> I was under the impression that cairo used pango somewhere but,
>
> % ldd /usr/lib/x86_64-linux-gnu/libcairo.so.2 |grep pango
>
> returned nothing. However,
>
> % ldd $(which emacs) |grep pango
> libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f1c4401f000)
> libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f1c43fb9000)
> libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f1c4363f000)
If you build with GTK, it will link with Pango. Emacs doesn't use
either Pango or GTK for font display or font metrics computation at all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sat, 08 Oct 2022 11:49:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[சனி ஜூன் 11, 2022] Visuwesh wrote:
> [...]
> However, I have been using the xft+harfbuzz combo for a ~week now and I
> can say with confidence that I don't experience this strange issue. I
> would highly appreciate it if the decision to remove the xft backend
> could be delayed until a solution comes up [1]. Although the font
> rendering is worse, the text stays readable at all font sizes.
I made some "progress" on this bug report. The misplacement goes away
when I close _all_ frames open on the Xorg display and open a fresh new
frame. If I only close the frame visiting the problematic buffer and
open a new frame to visit the buffer again, the misplacement does not go
away.
AFAIK, this workaround is not possible in "emacs -Q" since there is no
way to close all frames without also exiting Emacs. I tried to leave
the "original" frame around and opening a new frame but that did not
help.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sat, 08 Oct 2022 12:43:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Sat, 08 Oct 2022 17:18:12 +0530
>
> [சனி ஜூன் 11, 2022] Visuwesh wrote:
>
> > [...]
> > However, I have been using the xft+harfbuzz combo for a ~week now and I
> > can say with confidence that I don't experience this strange issue. I
> > would highly appreciate it if the decision to remove the xft backend
> > could be delayed until a solution comes up [1]. Although the font
> > rendering is worse, the text stays readable at all font sizes.
>
> I made some "progress" on this bug report. The misplacement goes away
> when I close _all_ frames open on the Xorg display and open a fresh new
> frame. If I only close the frame visiting the problematic buffer and
> open a new frame to visit the buffer again, the misplacement does not go
> away.
> AFAIK, this workaround is not possible in "emacs -Q" since there is no
> way to close all frames without also exiting Emacs. I tried to leave
> the "original" frame around and opening a new frame but that did not
> help.
Could you please state what issue are you trying to discuss here?
This bug report had its last communication 4 months ago, and its
discussion thread is very long and includes several separate issues.
It's hard to understand to which parts are you alluding here.
If this is the original issue with incorrect advance width of the
glyphs, then why is it interesting whether it goes away when you close
all the frames? It will sooner or later appear again, and to solve
the problem we need to understand what causes that, no?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sat, 08 Oct 2022 12:54:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[சனி அக்டோபர் 08, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
>> Date: Sat, 08 Oct 2022 17:18:12 +0530
>>
>> [சனி ஜூன் 11, 2022] Visuwesh wrote:
>>
>> > [...]
>> > However, I have been using the xft+harfbuzz combo for a ~week now and I
>> > can say with confidence that I don't experience this strange issue. I
>> > would highly appreciate it if the decision to remove the xft backend
>> > could be delayed until a solution comes up [1]. Although the font
>> > rendering is worse, the text stays readable at all font sizes.
>>
>> I made some "progress" on this bug report. The misplacement goes away
>> when I close _all_ frames open on the Xorg display and open a fresh new
>> frame. If I only close the frame visiting the problematic buffer and
>> open a new frame to visit the buffer again, the misplacement does not go
>> away.
>> AFAIK, this workaround is not possible in "emacs -Q" since there is no
>> way to close all frames without also exiting Emacs. I tried to leave
>> the "original" frame around and opening a new frame but that did not
>> help.
>
> Could you please state what issue are you trying to discuss here?
The fact that glyphs for Tamil text gets misplaced. To see what I mean,
please refer to the images I attached in the OP.
> This bug report had its last communication 4 months ago, and its
> discussion thread is very long and includes several separate issues.
> It's hard to understand to which parts are you alluding here.
Sorry about that. All the separate issues eventually boiled down to
"Emacs has glyph misplacement issues for Tamil text." The rest of the
issue was me figuring out if my config was introducing the misplacement
or whether it was a font issue, both of which aren't the case. I can
reproduce it in emacs -Q and with any Tamil font I throw at Emacs.
> If this is the original issue with incorrect advance width of the
> glyphs, then why is it interesting whether it goes away when you close
> all the frames?
Because, AFAIR, the workaround of closing all the frames did not work
before but it does now.
> It will sooner or later appear again, and to solve the problem we
> need to understand what causes that, no?
Yes, the issue shows itself again later but I wondered whether the
'close all the frame' thingy gave some hints. Also, I should note that
the patch for bug#50951 made this issue rarer (but still noticeable).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sat, 08 Oct 2022 13:01:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 54646 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
> Date: Sat, 08 Oct 2022 18:23:23 +0530
>
> > If this is the original issue with incorrect advance width of the
> > glyphs, then why is it interesting whether it goes away when you close
> > all the frames?
>
> Because, AFAIR, the workaround of closing all the frames did not work
> before but it does now.
But it is still a workaround, not a solution.
> > It will sooner or later appear again, and to solve the problem we
> > need to understand what causes that, no?
>
> Yes, the issue shows itself again later but I wondered whether the
> 'close all the frame' thingy gave some hints. Also, I should note that
> the patch for bug#50951 made this issue rarer (but still noticeable).
OK, so let's hope someone will get a hint from what you discovered.
Thanks for reporting it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 09 Oct 2022 11:33:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 54646 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
> Sorry about that. All the separate issues eventually boiled down to
> "Emacs has glyph misplacement issues for Tamil text." The rest of the
> issue was me figuring out if my config was introducing the misplacement
> or whether it was a font issue, both of which aren't the case. I can
> reproduce it in emacs -Q and with any Tamil font I throw at Emacs.
What if you run `clear-font-cache'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#54646; Package
emacs.
(Sun, 09 Oct 2022 12:01:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 54646 <at> debbugs.gnu.org (full text, mbox):
[ஞாயிறு அக்டோபர் 09, 2022] Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Visuwesh <visuweshm <at> gmail.com> writes:
>
>> Sorry about that. All the separate issues eventually boiled down to
>> "Emacs has glyph misplacement issues for Tamil text." The rest of the
>> issue was me figuring out if my config was introducing the misplacement
>> or whether it was a font issue, both of which aren't the case. I can
>> reproduce it in emacs -Q and with any Tamil font I throw at Emacs.
>
> What if you run `clear-font-cache'?
It does not help. Same with clear-composition-cache.
Merged 54646 73752.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Fri, 08 Nov 2024 08:10:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 30.1, send any further explanations to
73752 <at> debbugs.gnu.org and xuan <at> xlk.me
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Fri, 08 Nov 2024 08:10:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 06 Dec 2024 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 38 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.