Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[tumashu]

Hello everyone:



   (1)    How to let A Chinese char width = 2 * Ascii char width is an eternal topic for Chinese new emacser.


it let all Chinese new users and many old users puzzle a lot, that is the reason my cnfonts package (a Chinese fonts setup utils) get >600 github star.
recent day, we talk about Emacs fonts, so I want to know, is it possible provide a feature in emacs core to solve this problem?
The way cnfonts provide just a hack way I think. https://github.com/tumashu/cnfonts



The two question is that: How to force set min line-width to a value?  Chinese emaser use will use two fonts generally, a Ascii fonts and A Chinese fonts.
Two fonts will use different height to let 1 Chinese Char width = 2 * Ascii char width,  but this set will get other problem:


     (2)                     Chinese char Height > Ascii char height,


The results is that head-line, mode-line and minibuffer's height will shark (change frequently depend Chinese char exist or not).
it looks very very ugly.


These two questions make Chinese Emacs new users feel that Emacs is particularly low ！！！


Thanks！

Re:Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[tumashu]

At 2021-11-13 22:36:11, "tumashu" <tumashu@163.com> wrote:
>
>Hello everyone:
>
>
>
>   (1)    How to let A Chinese char width = 2 * Ascii char width is an eternal topic for Chinese new emacser.
>
>
>it let all Chinese new users and many old users puzzle a lot, that is the reason my cnfonts package (a Chinese fonts setup utils) get >600 github star.
>recent day, we talk about Emacs fonts, so I want to know, is it possible provide a feature in emacs core to solve this problem?
>The way cnfonts provide just a hack way I think. https://github.com/tumashu/cnfonts
>
>
>
>The two question is that: How to force set min line-width to a value?  Chinese emaser use will use two fonts generally, a Ascii fonts and A Chinese fonts.

Sorry, is min line-height, not min line-width.

>Two fonts will use different height to let 1 Chinese Char width = 2 * Ascii char width,  but this set will get other problem:
>
>
>     (2)                     Chinese char Height > Ascii char height,
>
>
>The results is that head-line, mode-line and minibuffer's height will shark (change frequently depend Chinese char exist or not).
>it looks very very ugly.
>
>
>These two questions make Chinese Emacs new users feel that Emacs is particularly low ！！！
>
>
>Thanks！
>
>
>
>
>
>
>
>
>
>
>
>

Re:Re:Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[tumashu]

[-- Attachment #1: Type: text/plain, Size: 8593 bytes --]

I have found a hack patch to deal with this problem: it is created by cjacker in 2012,

After this patch can not apply, I created cnfonts as a Chinese new emacser.






--- emacs-23.4/src/xftfont.c    2012-01-15 10:53:31.000000000 +0800
+++ emacs-23.4n/src/xftfont.c    2012-04-18 08:59:40.218009268 +0800
@@ -61,6 +61,8 @@
   Display *display;
   int screen;
   XftFont *xftfont;
+  FRAME_PTR frame; /* hold frame ptr, cjk double width fix need it */
+  int is_cjk; /* Flag to tell if it is CJK font or not. */
 };
 
 /* Structure pointed by (struct face *)->extra  */
@@ -141,6 +143,86 @@
     }
 }
 
+static int xftfont_is_cjk_font(struct xftfont_info *);
+static int xftfont_get_cjk_padding(int, int, int*);
+static int xftfont_get_default_width(struct xftfont_info *);
+
+/* Check whether the font contains CJK Ideograph 'number one', 0x4E00,
+   It should be ok for Chinese/Japanese font.
+   Or font contains Korean script syllable 'Ka',0xAC00,
+   because Korean fonts may not have any Chinese characters at all.
+   codes from xterm.*/
+static int
+xftfont_is_cjk_font(struct xftfont_info *xftfont_info)
+{
+  if(XftCharExists(xftfont_info->display, xftfont_info->xftfont, 0x4E00) ||
+      XftCharExists(xftfont_info->display, xftfont_info->xftfont, 0xAC00))
+    return 1;
+  return 0;
+}
+
+/* Get the padding according to default monospace font width */
+static int
+xftfont_get_cjk_padding(int default_width, int char_width, int *half_width_cjk)
+{
+  int padding = 0;
+  if(half_width_cjk)
+    *half_width_cjk = 0;
+
+  if( default_width == 0 || /* something wrong */
+      default_width == -1 || /* default font is not monospace */
+      char_width == default_width) /* already good */
+    return 0;
+  if( char_width < default_width) {
+    /* almost impossible, but we can handle it */
+    padding = default_width - char_width;
+    if(half_width_cjk)
+        *half_width_cjk = 1;
+  } else /* get the padding, all cjk symbols is DOUBLE width */
+    padding = default_width * 2 - char_width;
+  /* 1, Some old CJK pcf fonts may bigger than 2*default_width.
+     2, User may set a very big font size for script HAN manually.
+     Keep it unchanged, NOT adjust default font width. */
+  return (padding > 0 && padding < default_width) ? padding : 0;                  
+}
+
+/* Get the font width of monospace font.
+   Something wrong: return 0;
+   Default is not monospace: return -1;
+   Otherwise: return monospace font width; */
+static int
+xftfont_get_default_width(struct xftfont_info *xftfont_info)
+{
+  Lisp_Object font_object;
+  double request_pixel_size;
+  FRAME_PTR frame = xftfont_info->frame;
+  FcPattern * pattern = xftfont_info->xftfont->pattern;
+  int id = lookup_basic_face (frame, DEFAULT_FACE_ID);
+  struct face *face = FACE_FROM_ID (frame, id);
+  if(!face && !face->font)
+    return 0;
+  XSETFONT (font_object, face->font);
+  /* default font is not monospace */
+  if (XINT(AREF (font_object, FONT_SPACING_INDEX)) != FONT_SPACING_MONO)
+    return -1;
+  if(FcPatternGetDouble(pattern, FC_PIXEL_SIZE, 0, &request_pixel_size) != FcResultMatch)
+    return 0;
+  /* the font of minibuf/modeline never changed when rescaling.
+     it's a little bit difficult to determine where the xftfont draw to.
+     for example, when use mule/leim to input some CJK text.
+     it will draw on the selected frame and minibuf(candidate string).
+     by the way, the 'int' conversion should be ok. */
+  if(FRAME_FONT(frame)->pixel_size == (int)request_pixel_size)
+    return FRAME_SPACE_WIDTH(frame);
+  /* User may set a fixed font size for script han manually,
+     the font will not rescale when issue rescaling,
+     should not ajust the width offset and avoid to make it too wide.
+     its alignment will be wrong, but let's respect user settings.*/
+  if(face->font->pixel_size != (int)request_pixel_size)
+    return FRAME_SPACE_WIDTH(frame);
+  /* otherwise return the current font width */
+  return face->font->space_width;
+}
 
 static Lisp_Object xftfont_list P_ ((Lisp_Object, Lisp_Object));
 static Lisp_Object xftfont_match P_ ((Lisp_Object, Lisp_Object));
@@ -450,6 +532,14 @@
       XftTextExtents8 (display, xftfont, ascii_printable + 1, 94, &extents);
       font->average_width = (font->space_width + extents.xOff) / 95;
     }
+
+  /* to fix CJK double width alignment issue.
+     pass FRAME_PTR to every xftfont_info structure,
+     we can not get it in "xftfont_text_extents". */
+  xftfont_info->frame = f;
+  /* mark it is CJK font or not when font opened,
+     avoid calling "xftfont_is_cjk_font" many times. */
+  xftfont_info->is_cjk = xftfont_is_cjk_font(xftfont_info);
   UNBLOCK_INPUT;
 
   font->ascent = xftfont->ascent;
@@ -625,20 +715,27 @@
 {
   struct xftfont_info *xftfont_info = (struct xftfont_info *) font;
   XGlyphInfo extents;
-
+  int cjk_padding = 0;
+  int l_padding = 0;
+  int r_padding = 0;
   BLOCK_INPUT;
   XftGlyphExtents (xftfont_info->display, xftfont_info->xftfont, code, nglyphs,
            &extents);
+  if(xftfont_info->is_cjk)
+    cjk_padding = xftfont_get_cjk_padding(xftfont_get_default_width(xftfont_info), extents.xOff, NULL);
+  /* cjk_padding may equals to 0, then all is zero, still ok */
+  l_padding = cjk_padding >> 1; /* get half */
+  r_padding = cjk_padding - l_padding; /* may not divided by 2 exactly */
   UNBLOCK_INPUT;
   if (metrics)
     {
-      metrics->lbearing = - extents.x;
-      metrics->rbearing = - extents.x + extents.width;
-      metrics->width = extents.xOff;
+      metrics->lbearing = - extents.x - l_padding;
+      metrics->rbearing = - extents.x + extents.width + r_padding;
+      metrics->width = extents.xOff + cjk_padding;
       metrics->ascent = extents.y;
       metrics->descent = extents.height - extents.y;
     }
-  return extents.xOff;
+  return extents.xOff + cjk_padding;
 }
 
 static XftDraw *
@@ -699,9 +796,27 @@
     for (i = 0; i < len; i++)
       XftDrawGlyphs (xft_draw, &fg, xftfont_info->xftfont,
              x + i, y, code + i, 1);
-  else
-    XftDrawGlyphs (xft_draw, &fg, xftfont_info->xftfont,
-           x, y, code, len);
+  else {
+      int default_width = xftfont_get_default_width(xftfont_info);
+      if(!xftfont_info->is_cjk || default_width == -1) /* not cjk or default not monospace */
+        XftDrawGlyphs (xft_draw, &fg, xftfont_info->xftfont, x, y, code, len);
+      else /* draw CJK glyphs one by one and adjust the offset */
+         for (i = 0; i < len; i++) {
+           int cjk_padding = 0;
+           int offset = 0;
+           int half_width_cjk = 0;
+           XGlyphInfo extents;
+           XftGlyphExtents (xftfont_info->display, xftfont_info->xftfont, code+i, 1,
+                            &extents);
+           cjk_padding = xftfont_get_cjk_padding(default_width,extents.xOff, &half_width_cjk);
+           if(cjk_padding)
+             offset = default_width * i * (half_width_cjk ? 1 : 2) + (cjk_padding>>1);
+           else
+             offset = extents.xOff * i;
+           XftDrawGlyphs (xft_draw, &fg, xftfont_info->xftfont,
+                            x+offset, y, code+i, 1);
+         }
+  }
   UNBLOCK_INPUT;
 
   return len;



















At 2021-11-13 22:49:15, "tumashu" <tumashu@163.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>At 2021-11-13 22:36:11, "tumashu" <tumashu@163.com> wrote:
>>
>>Hello everyone:
>>
>>
>>
>>   (1)    How to let A Chinese char width = 2 * Ascii char width is an eternal topic for Chinese new emacser.
>>
>>
>>it let all Chinese new users and many old users puzzle a lot, that is the reason my cnfonts package (a Chinese fonts setup utils) get >600 github star.
>>recent day, we talk about Emacs fonts, so I want to know, is it possible provide a feature in emacs core to solve this problem?
>>The way cnfonts provide just a hack way I think. https://github.com/tumashu/cnfonts
>>
>>
>>
>>The two question is that: How to force set min line-width to a value?  Chinese emaser use will use two fonts generally, a Ascii fonts and A Chinese fonts.
>
>Sorry, is min line-height, not min line-width.
>
>>Two fonts will use different height to let 1 Chinese Char width = 2 * Ascii char width,  but this set will get other problem:
>>
>>
>>     (2)                     Chinese char Height > Ascii char height,
>>
>>
>>The results is that head-line, mode-line and minibuffer's height will shark (change frequently depend Chinese char exist or not).
>>it looks very very ugly.
>>
>>
>>These two questions make Chinese Emacs new users feel that Emacs is particularly low ！！！
>>
>>
>>Thanks！
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 12924 bytes --]

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> Date: Sat, 13 Nov 2021 23:03:10 +0800 (CST)
> From: tumashu  <tumashu@163.com>
> 
> I have found a hack patch to deal with this problem: it is created by cjacker in 2012, 
> After this patch can not apply, I created cnfonts as a Chinese new emacser.

You shouldn't have posted the code, because we cannot use non-trivial
patches from someone who doesn't have a copyright assignment.
Instead, you should describe what the patch does, so someone else
could code it independently; then we could use the resulting patch, if
we think it's a good idea.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 13 Nov 2021 23:03:10 +0800 (CST)
>> From: tumashu  <tumashu@163.com>
>> 
>> I have found a hack patch to deal with this problem: it is created by cjacker in 2012, 
>> After this patch can not apply, I created cnfonts as a Chinese new emacser.
>
> You shouldn't have posted the code, because we cannot use non-trivial
> patches from someone who doesn't have a copyright assignment.
> Instead, you should describe what the patch does, so someone else
> could code it independently; then we could use the resulting patch, if
> we think it's a good idea.

I know, this patch just an example, it is too old and can not apply to
master.

I use the method of terminal to solve "1 Chinese char width = 2 * Ascii
char width", by add extra padding when faced Chinese fonts. 

Maybe we can provide a custom to control this padding's width?
I do not know this is a good idea or not.



-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Date: Sun, 14 Nov 2021 00:19:48 +0800
> Cc: emacs-devel@gnu.org
> 
> Maybe we can provide a custom to control this padding's width?
> I do not know this is a good idea or not.

How would we compute that padding width?  Emacs could use several
different fonts for both ASCII and Chinese.  For example, the bold and
italic styles could use different font metrics, and sometimes we use
special fonts for specialized faces, like the variable-pitch face etc.
A single value of padding can never DTRT in all of those cases.

I'm actually surprised that there are no font pairs that already solve
this problem.  Did no one find a solution for this problem, so that
Emacs needs to invent a wheel that no one thought about?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Date: Sun, 14 Nov 2021 00:19:48 +0800
>> Cc: emacs-devel@gnu.org
>> 
>> Maybe we can provide a custom to control this padding's width?
>> I do not know this is a good idea or not.
>
> How would we compute that padding width?  Emacs could use several
> different fonts for both ASCII and Chinese.  For example, the bold and
> italic styles could use different font metrics, and sometimes we use
> special fonts for specialized faces, like the variable-pitch face etc.
> A single value of padding can never DTRT in all of those cases.
>
> I'm actually surprised that there are no font pairs that already solve

font parirs?  do you mean Chinese fonts and Ascii fonts use different
size? 

> this problem.  Did no one find a solution for this problem, so that
> Emacs needs to invent a wheel that no one thought about?

-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 03:35:39 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm actually surprised that there are no font pairs that already solve
> 
> font parirs?  do you mean Chinese fonts and Ascii fonts use different
> size? 

I mean a pair of fonts, one for ASCII, the other for Chinese, such
that the Chinese characters take exactly twice the width as ASCII
characters.  Aren't there such pairs of fonts?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 14 Nov 2021 03:35:39 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I'm actually surprised that there are no font pairs that already solve
>> 
>> font parirs?  do you mean Chinese fonts and Ascii fonts use different
>> size? 
>
> I mean a pair of fonts, one for ASCII, the other for Chinese, such
> that the Chinese characters take exactly twice the width as ASCII
> characters.  Aren't there such pairs of fonts?

ASCII fonts and Chinese fonts with same number? for exampe:

   ("Inconsolata-10" "MicroSoft Yahei-10")

I think very few, it need a lanky ASCII font, like: PragmataPro, or more
lanky.



-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eric Abrahamsen]

"Feng Shu" <tumashu@163.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: "Feng Shu" <tumashu@163.com>
>>> Cc: emacs-devel@gnu.org
>>> Date: Sun, 14 Nov 2021 03:35:39 +0800
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > I'm actually surprised that there are no font pairs that already solve
>>> 
>>> font parirs?  do you mean Chinese fonts and Ascii fonts use different
>>> size? 
>>
>> I mean a pair of fonts, one for ASCII, the other for Chinese, such
>> that the Chinese characters take exactly twice the width as ASCII
>> characters.  Aren't there such pairs of fonts?
>
> ASCII fonts and Chinese fonts with same number? for exampe:
>
>    ("Inconsolata-10" "MicroSoft Yahei-10")
>
> I think very few, it need a lanky ASCII font, like: PragmataPro, or more
> lanky.

I have this exact same problem (also in my window manager), and use
this:

Noto Sans Mono CJK SC

That's solved the issue for me.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 13 Nov 2021 16:28:11 -0800
> 
> "Feng Shu" <tumashu@163.com> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> From: "Feng Shu" <tumashu@163.com>
> >>> Cc: emacs-devel@gnu.org
> >>> Date: Sun, 14 Nov 2021 03:35:39 +0800
> >>> 
> >>> Eli Zaretskii <eliz@gnu.org> writes:
> >>> 
> >>> > I'm actually surprised that there are no font pairs that already solve
> >>> 
> >>> font parirs?  do you mean Chinese fonts and Ascii fonts use different
> >>> size? 
> >>
> >> I mean a pair of fonts, one for ASCII, the other for Chinese, such
> >> that the Chinese characters take exactly twice the width as ASCII
> >> characters.  Aren't there such pairs of fonts?
> >
> > ASCII fonts and Chinese fonts with same number? for exampe:
> >
> >    ("Inconsolata-10" "MicroSoft Yahei-10")
> >
> > I think very few, it need a lanky ASCII font, like: PragmataPro, or more
> > lanky.
> 
> I have this exact same problem (also in my window manager), and use
> this:
> 
> Noto Sans Mono CJK SC
> 
> That's solved the issue for me.

Does this font support both CJK and non-CJK characters?  Or are you
using other fonts for other scripts?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Does this font support both CJK and non-CJK characters?  Or are you
> using other fonts for other scripts?

I think it supports both, but Noto CJK fonts tend to have glyphs for
Chinese characters that are badly designed and in many cases, plain out
incorrect.  This is why I wouldn't call this font a real solution for
this problem.

Thanks.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Werner LEMBERG]

> [...] Noto CJK fonts tend to have glyphs for Chinese characters that
> are badly designed and in many cases, plain out incorrect.

Interesting.  AFAIK, the CJKV glyphs are based on the 'Adobe Source'
family.  Could you point out some of the problems?  Or maybe do you
have links to bug reports?  Normally, both the Adobe and Google font
folks are quite willing to fix such issues.


    Werner

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Werner LEMBERG <wl@gnu.org> writes:

> Interesting.  AFAIK, the CJKV glyphs are based on the 'Adobe Source'
> family.  Could you point out some of the problems?  Or maybe do you
> have links to bug reports?  Normally, both the Adobe and Google font
> folks are quite willing to fix such issues.

I can't give specific examples right now, but I would be willing to
switch to Noto CJK for a while and report any problems I see.

But Noto CJK having disagreeable glyphs is a relatively well known piece
of received wisdom around here, so someone else can probably chime in.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Byung-Hee HWANG]

Po Lu <luangruo@yahoo.com> writes:

> Werner LEMBERG <wl@gnu.org> writes:
>
>> Interesting.  AFAIK, the CJKV glyphs are based on the 'Adobe Source'
>> family.  Could you point out some of the problems?  Or maybe do you
>> have links to bug reports?  Normally, both the Adobe and Google font
>> folks are quite willing to fix such issues.
>
> I can't give specific examples right now, but I would be willing to
> switch to Noto CJK for a while and report any problems I see.
>
> But Noto CJK having disagreeable glyphs is a relatively well known piece
> of received wisdom around here, so someone else can probably chime in.

As Korean CJK user, i would like to add this thread as "star
mark". Personally Korean Hanja is not bad under Google Noto CJK.

"START: 한강 漢江 대한민국 大韓民國 -- This is Google Noto CJK"

attached as screenshot:
https://gitlab.com/soyeomul/Gnus/-/raw/86707860b5733ffa398683750a4bab01f79e1ffa/ss/google-noto-cjk-test.png


Sincerely, Gnus fan Byung-Hee

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 07:38:49 +0800
> 
> > I mean a pair of fonts, one for ASCII, the other for Chinese, such
> > that the Chinese characters take exactly twice the width as ASCII
> > characters.  Aren't there such pairs of fonts?
> 
> ASCII fonts and Chinese fonts with same number? for exampe:
> 
>    ("Inconsolata-10" "MicroSoft Yahei-10")
> 
> I think very few, it need a lanky ASCII font, like: PragmataPro, or more
> lanky.

Something like that, yes.  But mainly I wonder how do other GUI
applications solve this.  Emacs cannot be the first one to bump into
this problem.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Something like that, yes.  But mainly I wonder how do other GUI
> applications solve this.  Emacs cannot be the first one to bump into
> this problem.

They define the height of their bars to some constant value not
determined by the size of the text.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: "Feng Shu" <tumashu@163.com>,  emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 15:36:14 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Something like that, yes.  But mainly I wonder how do other GUI
> > applications solve this.  Emacs cannot be the first one to bump into
> > this problem.
> 
> They define the height of their bars to some constant value not
> determined by the size of the text.

What do you mean by "bars"?

And I believe the issue was more general than just the height of the
mode line and the mini-window.  The issue was how to make sure the CJK
wide characters take exactly twice the width of Latin characters in a
fixed-pitch font.  The height issue is sometimes _caused_ by the width
issue: users specify a larger CJK font to satisfy the width
requirement, and then have the problem with height because of the
larger font.

So my question was about both issues: the width and the height.  The
later should also be solved in the body of the window, not just in
mode-line and header-line parts, I believe.

If anyone knows or could find out how other applications solve these
issues, it could help us come up with ideas that are not only useful,
but also help users by presenting similar solutions to what they are
already used to.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: "Feng Shu" <tumashu@163.com>,  emacs-devel@gnu.org
>> Date: Sun, 14 Nov 2021 15:36:14 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Something like that, yes.  But mainly I wonder how do other GUI
>> > applications solve this.  Emacs cannot be the first one to bump into
>> > this problem.
>> 
>> They define the height of their bars to some constant value not
>> determined by the size of the text.
>
> What do you mean by "bars"?

Do this like box in latex?

A box in the TeX term for an invisible container that can hold a visible element.

>
> And I believe the issue was more general than just the height of the
> mode line and the mini-window.  The issue was how to make sure the CJK
> wide characters take exactly twice the width of Latin characters in a
> fixed-pitch font.  The height issue is sometimes _caused_ by the width
> issue: users specify a larger CJK font to satisfy the width
> requirement, and then have the problem with height because of the
> larger font.
>
> So my question was about both issues: the width and the height.  The
> later should also be solved in the body of the window, not just in
> mode-line and header-line parts, I believe.
>
> If anyone knows or could find out how other applications solve these
> issues, it could help us come up with ideas that are not only useful,
> but also help users by presenting similar solutions to what they are
> already used to.

Your are right, the problem is just like you said. :-)

-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> What do you mean by "bars"?

Tab bars and status bars, mostly: the former act like Emacs tab lines,
and the latter act like Emacs modelines.

> And I believe the issue was more general than just the height of the
> mode line and the mini-window.  The issue was how to make sure the CJK
> wide characters take exactly twice the width of Latin characters in a
> fixed-pitch font.  The height issue is sometimes _caused_ by the width
> issue: users specify a larger CJK font to satisfy the width
> requirement, and then have the problem with height because of the
> larger font.

See below, thanks.

> So my question was about both issues: the width and the height.  The
> later should also be solved in the body of the window, not just in
> mode-line and header-line parts, I believe.

> If anyone knows or could find out how other applications solve these
> issues, it could help us come up with ideas that are not only useful,
> but also help users by presenting similar solutions to what they are
> already used to.

Other programs do not try to solve the more general problem here, only
the lines.  And I think solving the problem with the mode-line and
header-line and tab bar and tab lines is enough to make people happy,
because I've never heard anyone complain about this for any other
reason.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tumashu@163.com,  emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 17:41:44 +0800
> 
> Other programs do not try to solve the more general problem here, only
> the lines.  And I think solving the problem with the mode-line and
> header-line and tab bar and tab lines is enough to make people happy,
> because I've never heard anyone complain about this for any other
> reason.

But there's also the mini-window: if we don't do something there,
you'll see the mode line move up and down in annoying ways, depending
on what text is displayed in the mini-window and which fonts it uses.
And the mini-window is mostly just another window.  So I think we
should decide what to do with window-body display as well (see my
other message about this in bug#51821 discussion), not just with
mode-line, tab-line, etc.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> But there's also the mini-window: if we don't do something there,
> you'll see the mode line move up and down in annoying ways, depending
> on what text is displayed in the mini-window and which fonts it uses.
> And the mini-window is mostly just another window.  So I think we
> should decide what to do with window-body display as well (see my
> other message about this in bug#51821 discussion), not just with
> mode-line, tab-line, etc.

Sadly, that means we are on our own here: other programs do not have
such a mini-window.

The closest to them that exist in other GUI programs are the URL and
search boxes in modern web browsers.  FWIW, they are also of a fixed
height and do not change in size based on their contents.

Re:Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[tumashu]

>If anyone knows or could find out how other applications solve these
>issues, it could help us come up with ideas that are not only useful,
>but also help users by presenting similar solutions to what they are
>already used to.

The below is a Chinese emacser  SuperMMX's  info:

In fact, there were solutions to this problem long ago in the BBS era, such as the implementation of various terms. There are generally two solutions.

The first principle is mainly based on a font, such as the height and width of a Chinese font under a certain size, and then use this size 
to calculate the size that other fonts should set, so as to ensure that two ASCII characters are the same as a Chinese character,
and the height is the same. Therefore, the width is aligned, and the height is subject to the higher one. 
But I remember one disadvantage, non Chinese will be bigger. This should be the solution of cnfonts.
However, CN Fonts is not fully automatic, but allows users to manually select the appropriate one, 
and it is impossible to control the height.

The second method is to adding padding. No matter how many fonts and sizes (subject to user settings), the height is the largest,
the width is the widest, and two ASCII characters correspond to one Chinese text. When drawing, the baseline should be adjusted,
and then left and right, and padding when necessary. The disadvantage is that the space may be too large and not good-looking, 
but it is a user selection problem. Another disadvantage is that there will be more calculations. It seems to be called adjusting tracking

I don't know how Emacs is done. It can be done in theory.

For example, qterm: https://github.com/qterm/qterm/blob/master/src/qtermscreen.cpp 2 screen:: getfontmetrics(), even the second 
method (adding padding).

Re:Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[tumashu]

>If anyone knows or could find out how other applications solve these
>issues, it could help us come up with ideas that are not only useful,
>but also help users by presenting similar solutions to what they are
>already used to.


Can we caculate line-height based on the max fonts height in fontset, 
instead of ASCII font?

Or can we let user choose a subset of fonts to caculate max height?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> Date: Mon, 15 Nov 2021 08:48:35 +0800 (CST)
> From: tumashu  <tumashu@163.com>
> Cc: "Po Lu" <luangruo@yahoo.com>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> Can we caculate line-height based on the max fonts height in fontset, 
> instead of ASCII font?

Fontsets don't usually define sizes of fonts.  And if you do define
the size, what happens when Emacs needs a smaller or larger font for
the same script or range of characters?

> Or can we let user choose a subset of fonts to caculate max height?

The main problem is not with the calculation of the size, the problem
is with application of the size: to which characters to apply it and
under what circumstances?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Can we caculate line-height based on the max fonts height in fontset, 
>> instead of ASCII font?
>
> Fontsets don't usually define sizes of fonts.  And if you do define
> the size, what happens when Emacs needs a smaller or larger font for
> the same script or range of characters?

I did some experimentation with another commonly used GUI application,
Chromium.  I take back what I said earlier about GUI programs not doing
anything to resolve this problem: it simply scales the larger font's
glyphs until it fits into some predefined line height, which I think is
defined in CSS.

Thanks.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tumashu <tumashu@163.com>,  emacs-devel@gnu.org
> Date: Mon, 15 Nov 2021 20:47:15 +0800
> 
> I did some experimentation with another commonly used GUI application,
> Chromium.  I take back what I said earlier about GUI programs not doing
> anything to resolve this problem: it simply scales the larger font's
> glyphs until it fits into some predefined line height, which I think is
> defined in CSS.

Not sure how can we do something like that in Emacs, since in Emacs
it's the other way around: we select a font based on all kinds of
criteria, and then the line metrics are computed from that.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> Date: Sat, 13 Nov 2021 22:36:11 +0800 (CST)
> From: tumashu <tumashu@163.com>
> 
> Hello everyone:
> 
>    (1)    How to let A Chinese char width = 2 * Ascii char width is an eternal topic for Chinese new emacser.

On GUI frames Emacs takes the width of each character in pixels from
the font that is being used.  So if you want each Chinese character to
take exactly 2 character cells of an ASCII character, you need to find
a pair of fonts that satisfy this relation.  Because the font used for
ASCII varies between users, and the font used for Chinese probably
varies as well, I don't think I see how Emacs can solve this problem,
because Emacs doesn't understand the significance of each font.

> it let all Chinese new users and many old users puzzle a lot, that is the reason my cnfonts package (a Chinese fonts setup utils) get >600 github star.
> recent day, we talk about Emacs fonts, so I want to know, is it possible provide a feature in emacs core to solve this problem?

Which problem is that?  The 2 questions you asked or something else?

> The two question is that: How to force set min line-width to a value?

What do you mean by "min line-width" here?

> Chinese emaser use will use two fonts generally, a Ascii fonts and A Chinese fonts.
> Two fonts will use different height to let 1 Chinese Char width = 2 * Ascii char width,  but this set will get other problem:
> 
>      (2)                     Chinese char Height > Ascii char height,
> 
> 
> The results is that head-line, mode-line and minibuffer's height will shark (change frequently depend Chinese char exist or not).
> it looks very very ugly.

Did you try to set the line-height text property on the newline of
each line?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 13 Nov 2021 22:36:11 +0800 (CST)
>> From: tumashu <tumashu@163.com>
>> 
>> Hello everyone:
>> 
>>    (1)    How to let A Chinese char width = 2 * Ascii char width is an eternal topic for Chinese new emacser.
>
> On GUI frames Emacs takes the width of each character in pixels from
> the font that is being used.  So if you want each Chinese character to
> take exactly 2 character cells of an ASCII character, you need to find
> a pair of fonts that satisfy this relation.  Because the font used for

This is the main way Chinese emacser used, like below, but it 
will have question 2:  Chinese Char Height > Ascii Char Height.

(progn
  (set-face-attribute
   'default nil
   :font (font-spec :name "PragmataPro"
                    :weight 'normal
                    :slant 'normal
                    :size 16.0))
  (dolist (charset '(kana han symbol cjk-misc bopomofo))
    (set-fontset-font
     "fontset-default"
     charset
     (font-spec :name "黑体"
                :weight 'normal
                :slant 'normal
                :size 16.0))))

>> it let all Chinese new users and many old users puzzle a lot, that
>> is the reason my cnfonts package (a Chinese fonts setup utils) get
>> >600 github star.
>> recent day, we talk about Emacs fonts, so I want to know, is it
>> possible provide a feature in emacs core to solve this problem?
>
> Which problem is that?  The 2 questions you asked or something else?

What I said is question 1: "A Chinese char width = 2 * Ascii char"




-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>>      (2)                     Chinese char Height > Ascii char height,
>> 
>> 
>> The results is that head-line, mode-line and minibuffer's height
>> will shark (change frequently depend Chinese char exist or not).
>> it looks very very ugly.
>
> Did you try to set the line-height text property on the newline of
> each line?

I think not:

The below two line:

  1. Hello and 你好  (line-pixel-height) = 30

  2. Hello           (line-pixel-height) = 24


I want to a way to set min line pixel height, and let line height 
always 30, no matter Chinese exist or not.

for example:

    line-pixel-min-height-factor = 1.25

which mean: line-pixel-min-height = 1.25 * 24 = 30









-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 00:12:42 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>      (2)                     Chinese char Height > Ascii char height,
> >> 
> >> 
> >> The results is that head-line, mode-line and minibuffer's height
> >> will shark (change frequently depend Chinese char exist or not).
> >> it looks very very ugly.
> >
> > Did you try to set the line-height text property on the newline of
> > each line?
> 
> I think not:
> 
> The below two line:
> 
>   1. Hello and 你好  (line-pixel-height) = 30
> 
>   2. Hello           (line-pixel-height) = 24

I don't understand what that means, sorry.  Are you saying that it
doesn't work?  If so, please show what you did to try it.

> I want to a way to set min line pixel height, and let line height 
> always 30, no matter Chinese exist or not.

That's what line-height does, see the ELisp manual, node "Line
Height".

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:


>> The below two line:
>> 
>>   1. Hello and 你好  (line-pixel-height) = 30
>> 
>>   2. Hello           (line-pixel-height) = 24
>
> I don't understand what that means, sorry.  Are you saying that it
> doesn't work?  If so, please show what you did to try it.
>
>> I want to a way to set min line pixel height, and let line height 
>> always 30, no matter Chinese exist or not.
>
> That's what line-height does, see the ELisp manual, node "Line
> Height".

I have try the below code, and it work

  (insert (propertize "\n" 'line-height 1.4))

But how to apply it global? why line-height is not a variable?

in mode-line, header-line and tab-line, this approach do not work, for
mode-line seem to disallow include "\n"


-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

"Feng Shu" <tumashu@163.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>
>>> The below two line:
>>> 
>>>   1. Hello and 你好  (line-pixel-height) = 30
>>> 
>>>   2. Hello           (line-pixel-height) = 24
>>
>> I don't understand what that means, sorry.  Are you saying that it
>> doesn't work?  If so, please show what you did to try it.
>>
>>> I want to a way to set min line pixel height, and let line height 
>>> always 30, no matter Chinese exist or not.
>>
>> That's what line-height does, see the ELisp manual, node "Line
>> Height".
>
> I have try the below code, and it work
>
>   (insert (propertize "\n" 'line-height 1.4))
>
> But how to apply it global? why line-height is not a variable?
>
> in mode-line, header-line and tab-line, this approach do not work, for
> mode-line seem to disallow include "\n"

By the way, how to control mode/header/tab-line's height? 

-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 03:54:43 +0800
> 
> By the way, how to control mode/header/tab-line's height? 

Via their faces, I presume?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 14 Nov 2021 03:54:43 +0800
>> 
>> By the way, how to control mode/header/tab-line's height? 
>
> Via their faces, I presume?

ok, If via face, I think it can not deal with my problem,
maybe line-height variable or frame para are right way.

-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 07:31:19 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: "Feng Shu" <tumashu@163.com>
> >> Cc: emacs-devel@gnu.org
> >> Date: Sun, 14 Nov 2021 03:54:43 +0800
> >> 
> >> By the way, how to control mode/header/tab-line's height? 
> >
> > Via their faces, I presume?
> 
> ok, If via face, I think it can not deal with my problem,

Why not?  How did you think this should be done via faces?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>
> Why not?  How did you think this should be done via faces?

Because I want to the mode/tab-bar's height unchange, no matter Chinese
char exist or not. Is it easy deal with via face? I do not know.



-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 03:33:25 +0800
> 
> I have try the below code, and it work
> 
>   (insert (propertize "\n" 'line-height 1.4))
> 
> But how to apply it global? why line-height is not a variable?

We could add a variable, like we have with line-spacing.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 14 Nov 2021 03:33:25 +0800
>> 
>> I have try the below code, and it work
>> 
>>   (insert (propertize "\n" 'line-height 1.4))
>> 
>> But how to apply it global? why line-height is not a variable?
>
> We could add a variable, like we have with line-spacing.

Should be a good idea.


-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Phil Sainty]

On 2021-11-14 04:21, Eli Zaretskii wrote:
> On GUI frames Emacs takes the width of each character in pixels from
> the font that is being used.

Potentially Emacs could provide a defcustom mapping of fonts to minimum
character widths, and if the actual width of any character is less than
the customized minimum then the (larger) minimum width is used instead
(I guess padding either side of the character).

I've no clue whether this is practical -- I know very little about 
fonts.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 2021-11-14 04:21, Eli Zaretskii wrote:
>> On GUI frames Emacs takes the width of each character in pixels from
>> the font that is being used.
>
> Potentially Emacs could provide a defcustom mapping of fonts to minimum
> character widths, and if the actual width of any character is less than
> the customized minimum then the (larger) minimum width is used instead
> (I guess padding either side of the character).

Maybe we just need a padding api, and let user control the number px or pecent of
padding.

"let 1 Chinese Char width = 2 * Ascii Char width" main useful in table
like environment, for example org-table, org-agenda buffer, gnus buffer
and so on. so let user choice a padding is possible solution, 

And We should pad Chinese instead of Ascii, for 

     H e l l o 你好

looks ugly :-)



>
> I've no clue whether this is practical -- I know very little about
> fonts.
>
>

-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

"Feng Shu" <tumashu@163.com> writes:

> Phil Sainty <psainty@orcon.net.nz> writes:
>
>> On 2021-11-14 04:21, Eli Zaretskii wrote:
>>> On GUI frames Emacs takes the width of each character in pixels from
>>> the font that is being used.
>>
>> Potentially Emacs could provide a defcustom mapping of fonts to minimum
>> character widths, and if the actual width of any character is less than
>> the customized minimum then the (larger) minimum width is used instead
>> (I guess padding either side of the character).
>
> Maybe we just need a padding api, and let user control the number px or pecent of
> padding.

   What about: (font-spec :name "Microsoft Yahei" :padding 2)

   Mean Micorsoft Yahei will pad 2px to 1 char when showed?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 08:18:49 +0800
> 
> "Feng Shu" <tumashu@163.com> writes:
> 
> > Phil Sainty <psainty@orcon.net.nz> writes:
> >
> >> On 2021-11-14 04:21, Eli Zaretskii wrote:
> >>> On GUI frames Emacs takes the width of each character in pixels from
> >>> the font that is being used.
> >>
> >> Potentially Emacs could provide a defcustom mapping of fonts to minimum
> >> character widths, and if the actual width of any character is less than
> >> the customized minimum then the (larger) minimum width is used instead
> >> (I guess padding either side of the character).
> >
> > Maybe we just need a padding api, and let user control the number px or pecent of
> > padding.
> 
>    What about: (font-spec :name "Microsoft Yahei" :padding 2)
> 
>    Mean Micorsoft Yahei will pad 2px to 1 char when showed?

How would you know that the value 2 is the one to use?

This kind of solution sounds like a terrible kludge to me.  It is also
unreliable, because the font designers didn't promise us the padding
value will not have to change when more characters are added.  And the
value depends on the ASCII font being used as well, not just the CJK
font, so even the syntax of the spec is incomplete (it doesn't mention
the ASCII font).

Would someone please investigate how do other GUI editors solve this
problem, and post a summary?  I'm sure there are better solutions than
asking users to provide pixel values for each pair of fonts.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> How would you know that the value 2 is the one to use?
>
> This kind of solution sounds like a terrible kludge to me.  It is also
> unreliable, because the font designers didn't promise us the padding
> value will not have to change when more characters are added.  And the
> value depends on the ASCII font being used as well, not just the CJK
> font, so even the syntax of the spec is incomplete (it doesn't mention
> the ASCII font).

> Would someone please investigate how do other GUI editors solve this
> problem, and post a summary?  I'm sure there are better solutions than
> asking users to provide pixel values for each pair of fonts.

From a quick investigation (not at all conclusive) of GNOME Builder, it
seems to define some fixed height for its various 'bars', which doesn't
change based on the characters inside.

Other GUI editors behave similarly.  But I have no significant
experience with them to speak of.

Thanks.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: "Feng Shu" <tumashu@163.com>,  psainty@orcon.net.nz,  emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 15:54:41 +0800
> 
> > Would someone please investigate how do other GUI editors solve this
> > problem, and post a summary?  I'm sure there are better solutions than
> > asking users to provide pixel values for each pair of fonts.
> 
> >From a quick investigation (not at all conclusive) of GNOME Builder, it
> seems to define some fixed height for its various 'bars', which doesn't
> change based on the characters inside.
> 
> Other GUI editors behave similarly.  But I have no significant
> experience with them to speak of.

And what do they do with the width issue?

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> And what do they do with the width issue?

They do nothing with the width issue.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> Date: Sun, 14 Nov 2021 12:14:39 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: tumashu <tumashu@163.com>, emacs-devel@gnu.org
> 
> On 2021-11-14 04:21, Eli Zaretskii wrote:
> > On GUI frames Emacs takes the width of each character in pixels from
> > the font that is being used.
> 
> Potentially Emacs could provide a defcustom mapping of fonts to minimum
> character widths, and if the actual width of any character is less than
> the customized minimum then the (larger) minimum width is used instead
> (I guess padding either side of the character).
> 
> I've no clue whether this is practical -- I know very little about 
> fonts.

This could be done, but as I already asked up-thread: how will the
user know what value to give to the defcustom?  Especially if Emacs is
using more than one pair of fonts, due to several important features
using non-default faces?  And even with the default face, what happens
if the user does "C-x C-+"?

I feel that I don't understand the issue well enough, because it
sounds strange that Emacs needs to invent a solution for a problem
that was probably already solved umpteen times in other programs (and
I don't mean terminal emulators, I mean GUI programs).  I very much
doubt that those other applications provide such a user option, so
some more sensible solution must exist.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 14 Nov 2021 12:14:39 +1300
>> From: Phil Sainty <psainty@orcon.net.nz>
>> Cc: tumashu <tumashu@163.com>, emacs-devel@gnu.org
>> 
>> On 2021-11-14 04:21, Eli Zaretskii wrote:
>> > On GUI frames Emacs takes the width of each character in pixels from
>> > the font that is being used.
>> 
>> Potentially Emacs could provide a defcustom mapping of fonts to minimum
>> character widths, and if the actual width of any character is less than
>> the customized minimum then the (larger) minimum width is used instead
>> (I guess padding either side of the character).
>> 
>> I've no clue whether this is practical -- I know very little about 
>> fonts.
>
> This could be done, but as I already asked up-thread: how will the
> user know what value to give to the defcustom?  Especially if Emacs is

Try from 1px to 100px, until align properly :-), we find proper size
Chinese fonts by same way :-)

> using more than one pair of fonts, due to several important features

"1 Chinese char width = 2 * ascii char width" only meanful in "table"
style environment, for example: org md table, gnus, org-agenda ....
In most case, it can not use many fonts.


> using non-default faces?  And even with the default face, what happens
> if the user does "C-x C-+"?

This is the most case, as for "C-x C-+", we just do not use it, or
rewrite to a new function.


As Chinese emacser users, we just expect align proper *in most case* :-)

>
> I feel that I don't understand the issue well enough, because it
> sounds strange that Emacs needs to invent a solution for a problem
> that was probably already solved umpteen times in other programs (and
> I don't mean terminal emulators, I mean GUI programs).  I very much

I do not know, maybe other GUI programs less use aligned text to create UI.

> doubt that those other applications provide such a user option, so
> some more sensible solution must exist.

-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: Phil Sainty <psainty@orcon.net.nz>,  emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 15:17:07 +0800
> 
> > using more than one pair of fonts, due to several important features
> 
> "1 Chinese char width = 2 * ascii char width" only meanful in "table"
> style environment, for example: org md table, gnus, org-agenda ....
> In most case, it can not use many fonts.

This will also be a problem in any descendant of tabulated-list-mode,
and those do use different faces.  Even "C-x C-b" already uses regular
and bold styles, and bold will definitely have characters that are
wider than regular with some fonts.

> > using non-default faces?  And even with the default face, what happens
> > if the user does "C-x C-+"?
> 
> This is the most case, as for "C-x C-+", we just do not use it, or
> rewrite to a new function.
> 
> As Chinese emacser users, we just expect align proper *in most case* :-)

I'd like to come up with a solution that doesn't look like a hack,
please.  Something we could be proud of.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> On GUI frames Emacs takes the width of each character in pixels from
> the font that is being used.  So if you want each Chinese character to
> take exactly 2 character cells of an ASCII character, you need to find
> a pair of fonts that satisfy this relation.  Because the font used for
> ASCII varies between users, and the font used for Chinese probably
> varies as well, I don't think I see how Emacs can solve this problem,
> because Emacs doesn't understand the significance of each font.

What he is trying to say, is that the height of the mode line adjusts
itself based on the height of the characters inside.

So, if your modeline contains (because you have such a file open in a
buffer):

    汉语 PDF 样本文件.pdf

Then it will display as taller than if it just contains:

    PDF sample file.pdf

I personally don't find it annoying, but it is a common complaint
amongst Emacs users in China.

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Feng Shu]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> On GUI frames Emacs takes the width of each character in pixels from
>> the font that is being used.  So if you want each Chinese character to
>> take exactly 2 character cells of an ASCII character, you need to find
>> a pair of fonts that satisfy this relation.  Because the font used for
>> ASCII varies between users, and the font used for Chinese probably
>> varies as well, I don't think I see how Emacs can solve this problem,
>> because Emacs doesn't understand the significance of each font.
>
> What he is trying to say, is that the height of the mode line adjusts
> itself based on the height of the characters inside.
>
> So, if your modeline contains (because you have such a file open in a
> buffer):
>
>     汉语 PDF 样本文件.pdf
>
> Then it will display as taller than if it just contains:
>
>     PDF sample file.pdf
>
> I personally don't find it annoying, but it is a common complaint
> amongst Emacs users in China.

Yes, not only mode-line, header-line, tab-bar/line, minibuffer have this
problem too. when user user ivy or vertico, this problem will worse.
User will find mode-line will jump up and down when scroll ivy/vertico
candidates, depend have Chinese char or not.

What a pity is that we can not force ASCII char Height = Chinese char
Height, if we do, we will faced table like environment unalign problem.


That's why we need min-line-height feature.



-- 

Re: Any new method to deal with Emacs Fonts settings puzzles nearly every Chinese emacser？

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tumashu <tumashu@163.com>,  emacs-devel@gnu.org
> Date: Sun, 14 Nov 2021 09:12:01 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > On GUI frames Emacs takes the width of each character in pixels from
> > the font that is being used.  So if you want each Chinese character to
> > take exactly 2 character cells of an ASCII character, you need to find
> > a pair of fonts that satisfy this relation.  Because the font used for
> > ASCII varies between users, and the font used for Chinese probably
> > varies as well, I don't think I see how Emacs can solve this problem,
> > because Emacs doesn't understand the significance of each font.
> 
> What he is trying to say, is that the height of the mode line adjusts
> itself based on the height of the characters inside.
> 
> So, if your modeline contains (because you have such a file open in a
> buffer):
> 
>     汉语 PDF 样本文件.pdf
> 
> Then it will display as taller than if it just contains:
> 
>     PDF sample file.pdf

Yes, I understand all that, I just wonder how do other GUI
applications solve this.