GNU bug report logs -
#6471
Arabic display by emacs -Q on HELLO
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6471 in the body.
You can then email your comments to 6471 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#6471
; Package
emacs
.
(Sat, 19 Jun 2010 23:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
David De La Harpe Golden <david <at> harpegolden.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 19 Jun 2010 23:14:02 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)]
On 19/06/10 23:16, David De La Harpe Golden wrote:
>
> Aside: HELLO looks distinctly odd around the arabic lines in emacs -Q
> but not with my normal config. Probably independent from the immediate
> scrolling issue and possibly font-dependent, I'll file a separate bug.
>
Yes, emacs -Q is picking this font:
xft:-unknown-Metal-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1
from debian package ttf-arabeyes:
/usr/share/fonts/truetype/ttf-arabeyes/ae_Metal.ttf
and "emacs" this font (in accord with my default font customisation):
xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
Actually, I suspect (not that I know arabic) both cases are displaying
it incorrectly (not composed), but it looks particularly off with the
former, with the character cell for the character taking up half the
screen. This might be partially a problem with the font in question.
[1]
character: ّ (1617, #o3121, #x651)
preferred charset: arabic-iso8859-6 (Right-Hand Part of ISO/IEC 8859/6
(Latin/Arabic): ISO-IR-127)
code point: 0x71
syntax: w which means: word
category: b:Arabic
buffer code: #xD9 #x91
file code: ESC #x2C #x47 #x71 (encoded by coding system
iso-2022-7bit-unix)
display: by this font (glyph code)
xft:-unknown-Metal-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1
(#x21C)
Character code properties: customize what to show
name: ARABIC SHADDA
old-name: ARABIC SHADDAH
general-category: Mn (Mark, Nonspacing)
There are text properties here:
charset arabic-iso8859-6
[emacs_q_hello_arabic.png (image/png, attachment)]
[emacs_hello_arabic.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#6471
; Package
emacs
.
(Wed, 21 Aug 2019 22:58:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 6471 <at> debbugs.gnu.org (full text, mbox):
David De La Harpe Golden <david <at> harpegolden.net> writes:
>> Aside: HELLO looks distinctly odd around the arabic lines in emacs -Q
>> but not with my normal config. Probably independent from the immediate
>> scrolling issue and possibly font-dependent, I'll file a separate bug.
>>
>
> Yes, emacs -Q is picking this font:
>
> xft:-unknown-Metal-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1
>
> from debian package ttf-arabeyes:
>
> /usr/share/fonts/truetype/ttf-arabeyes/ae_Metal.ttf
>
> and "emacs" this font (in accord with my default font customisation):
>
> xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
>
> Actually, I suspect (not that I know arabic) both cases are displaying
> it incorrectly (not composed), but it looks particularly off with the
> former, with the character cell for the character taking up half the
> screen. This might be partially a problem with the font in question.
(I'm going through old bug reports that have unfortunately gotten no
attention yet.)
I tried reproducing this in Emacs 27, but as far as I can tell, the
Arabic text shows up composed for me (emacs -Q is using "Ubuntu Mono")
on my GNU/Linux system.
Are you still seeing this problem, or has it been fixed in the
intervening years?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 21 Aug 2019 22:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#6471
; Package
emacs
.
(Thu, 22 Aug 2019 14:06:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 6471 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 6471 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Wed, 21 Aug 2019 15:57:10 -0700
>
> David De La Harpe Golden <david <at> harpegolden.net> writes:
>
> >> Aside: HELLO looks distinctly odd around the arabic lines in emacs -Q
> >> but not with my normal config. Probably independent from the immediate
> >> scrolling issue and possibly font-dependent, I'll file a separate bug.
> >>
> >
> > Yes, emacs -Q is picking this font:
> >
> > xft:-unknown-Metal-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1
> >
> > from debian package ttf-arabeyes:
> >
> > /usr/share/fonts/truetype/ttf-arabeyes/ae_Metal.ttf
> >
> > and "emacs" this font (in accord with my default font customisation):
> >
> > xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
> >
> > Actually, I suspect (not that I know arabic) both cases are displaying
> > it incorrectly (not composed), but it looks particularly off with the
> > former, with the character cell for the character taking up half the
> > screen. This might be partially a problem with the font in question.
>
> (I'm going through old bug reports that have unfortunately gotten no
> attention yet.)
>
> I tried reproducing this in Emacs 27, but as far as I can tell, the
> Arabic text shows up composed for me (emacs -Q is using "Ubuntu Mono")
> on my GNU/Linux system.
>
> Are you still seeing this problem, or has it been fixed in the
> intervening years?
FWIW, I cannot see any problems, and am almost positive they were
either fixed or were due to a faulty font.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#6471
; Package
emacs
.
(Fri, 23 Aug 2019 00:14:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 6471 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> FWIW, I cannot see any problems, and am almost positive they were
> either fixed or were due to a faulty font.
OK; closing the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
6471 <at> debbugs.gnu.org and David De La Harpe Golden <david <at> harpegolden.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 23 Aug 2019 00:14:02 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, 20 Sep 2019 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 333 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.