From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Evgeny Zajcev Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Add support for `ch' and `cw' dimension specifiers for the image Date: Thu, 28 Mar 2024 22:34:32 +0300 Message-ID: References: <86sf0j1q0c.fsf@gnu.org> <86cyrehdre.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009f16760614bd9d3a" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22082"; mail-complaints-to="usenet@ciao.gmane.io" To: Alan Third , Evgeny Zajcev , Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 28 20:35:34 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rpvXB-0005Xa-PX for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Mar 2024 20:35:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpvWZ-0006pJ-CS; Thu, 28 Mar 2024 15:34:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rpvWU-0006on-A2 for emacs-devel@gnu.org; Thu, 28 Mar 2024 15:34:50 -0400 Original-Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rpvWS-0003Vc-9p; Thu, 28 Mar 2024 15:34:49 -0400 Original-Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-6ea8a0d1a05so1608383b3a.1; Thu, 28 Mar 2024 12:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711654486; x=1712259286; darn=gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=cdftyb1SdJc9xFbVk/m9QEmdNI9C7VPTcfFivyU+aeY=; b=Z0PZjrs3Zaj44PCLRovaxzcvVRh+Uwuh6M5HBwSBPOmM/qJXns+6ejuvCe5zSkp9ZE pbfDVC++PAncLhPBAzBoxFCEpXUTLsuuKlYOD+v53UmmF9ofFyE6O1NHfCk9mVXLrFiO lmzD1BHqVRZjygmGneHTZsg8RPHh4rDLc5IiFBw36usA1j9RS7K+XORwk1KzuGOJFnBz XHTbTiCvRfB1WPCj51cG5PpHAEh5CG+8mnx/6M3pBaGBxzMZt7DVRDfNGHzCp0qwmmjv ZprR5pDXLGs6f0/8H7WbJy8uK+7uurS+cPWo6jOopglE5E/bpqIefuJpa0AbweCK/+ha khBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711654486; x=1712259286; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cdftyb1SdJc9xFbVk/m9QEmdNI9C7VPTcfFivyU+aeY=; b=oSilw87YzDsKnDpLYlvXJG3nZWz0lLUkSEFXzfPHf0xD0icU5XIKUrtHJefbL7SN11 hxVNC76KU8b59HNram1zZGptFBitOkrTvexwBWjUDla6AjuB7O6s18SzioOhLecJGJiC jBY4D72VBd61SwxNG0DMWhaZwF1iDQIt3+r6wQ6xM+svadoXvzTLRSgEMos8w12lr/2P WM61s7ECLPrZ4w2vd3gjjrOXWExdP8lqBbfPGOxWRD7+skNZoUbaWte6pEpvSPfx+qP2 iwJhugRuBD5EIJH4lLXGutOeaCkoBwHe5jR0uy158pS9Hj94TEclFAr/oUn00aetuW4a 1B4Q== X-Forwarded-Encrypted: i=1; AJvYcCUw9RhXNUYTHixXpsAOnZstnhP+yJ5tPg+j5yPEgH0P0oI4MN/K1eA8mLCK7KnO1eHMoDO4UEqlW5V7d7d78rCQO1zcF9wnGcfeG8FupRe+Wjk= X-Gm-Message-State: AOJu0YxCaA2wNjQLyMZ5UD/xs8MmuNeY+i2Cmsgf/eUeddAcF00U8TY/ XGPKFv1xcjojG5J8c5AwiGu2a5KDEOXreb7xWea3PHGXr6q7nGl86xRuVmebaO+d0e/RoOqO6zb Wm5YkIwjXWaq77bc6S+HXqePBdbc= X-Google-Smtp-Source: AGHT+IEgSTe5wtYhS7uiNVf/ZYX9s5is2eqJ8PMA04BKtgwJnx6Ri8t02P6q3Ei5GFlWJCaj2KvRVaZ3s+VRg0Z9O+0= X-Received: by 2002:a17:902:d50b:b0:1e0:b3bb:c921 with SMTP id b11-20020a170902d50b00b001e0b3bbc921mr561285plg.32.1711654486084; Thu, 28 Mar 2024 12:34:46 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::42c; envelope-from=lg.zevlg@gmail.com; helo=mail-pf1-x42c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317369 Archived-At: --0000000000009f16760614bd9d3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=87=D1=82, 28 =D0=BC=D0=B0=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 14:41, Ala= n Third : > On Thu, Mar 28, 2024 at 01:50:37PM +0300, Evgeny Zajcev wrote: > > Yes, this is intentional, because saying "height of the font" in docs, > when > > font's pixel size is used in code, is misleading and it took me some ti= me > > to understand why image renders smaller then font height if '(1 . em) i= s > > specified as dimension modifier. That's why I started using coefficien= t > > (calculated with `my-em-height-ratio') to `em' specifier > > Does this mean we have em wrong? It should ideally, IMO, be equivalent > to em in a web browser because that seems the most common use Emacs > users will be aware of. If we're using the wrong value then we should > change it. > Not wrong, but different. I don't know what `em' in web browser means, however, in web browser, for example, it is possible to create an image of 3em height and display it like this: .----------. | | Text line 1 | | Text line 2 | | Text line 3 `----------' And image will be displayed solely and will fit into 3 lines height. In Emacs, if image with 3em in height is displayed using slices, it will result in a gap in the final slice, because 1em (font's size) is less in pixels, than 1ch (font's height and final line height). Let me elaborate: For example we have 45px font, with ascent 38px and descent 10px, resulting in font height equal to 48px. And we create 3em image, which will be 45*3 =3D 135px in height. Now, we display this image using slices: first slice will be: 0,48 (to occupy full line height), second slice - 48,48, and third slice 96,39. Last slice is 39px in height and if you display it with :ascent 'center it will have 4px gap. If you display it with :ascent 100, it will increase final line height by 1px, because 39-38. You probably can calculate correct :ascent value to get exact value of ascent in %, but, unfortunatety, ascent is integer and in general integer number of percents is not enough to get exact value (for example for fonts larger then 100px). Also, this forces to modify :ascent value for the last slice, which leads to additional garbage. `ch' and `cw' specifiers solves two problems: 1) Makes it possible to create image intended for slices display without gaps, and automatically adopts to text-scale changes. 2) Makes it possible to align images precisely to the width of the given number of characters, especially this makes sense when monospace font is used. Also adopts to text-scale changes. --=20 lg --0000000000009f16760614bd9d3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
=D1=87=D1=82, 28 =D0=BC=D0=B0=D1=80. = 2024=E2=80=AF=D0=B3. =D0=B2 14:41, Alan Third <alan@idiocy.org>:
On Thu, Mar 28, 2024 at 01:50:37PM +0300, Evgeny Zajcev = wrote:
> Yes, this is intentional, because saying "height of the font"= ; in docs, when
> font's pixel size is used in code, is misleading and it took me so= me time
> to understand why image renders smaller then font height if '(1 . = em) is
> specified as dimension modifier.=C2=A0 That's why I started using = coefficient
> (calculated with `my-em-height-ratio') to `em' specifier

Does this mean we have em wrong? It should ideally, IMO, be equivalent
to em in a web browser because that seems the most common use Emacs
users will be aware of. If we're using the wrong value then we should change it.

Not wrong, but different.
I don't know what `em' in web browser means, however, in web b= rowser,
for example, it is possible to create an image of 3em height and=
display it like this:

.----------.
| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Text line 1
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Text line = 2
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Text line 3
`----------'<= br>
And image will be displayed solely and will fit into 3 lines height.=

In Emacs, if image with 3em in height is displayed using slices, it=
will result in a gap in the final slice, because 1em (font's size) = is
less in pixels, than 1ch (font's height and final line height).
Let me elaborate: For example we have 45px font, with ascent 38px and=
descent 10px, resulting in font height equal to 48px.=C2=A0 And we crea= te
3em image, which will be 45*3 =3D 135px in height.=C2=A0 Now, we disp= lay this
image using slices: first slice will be: 0,48 (to occupy full l= ine
height), second slice - 48,48, and third slice 96,39.=C2=A0 Last sli= ce is
39px in height and if you display it with :ascent 'center it w= ill have
4px gap.=C2=A0 If you display it with :ascent 100, it will incr= ease final
line height by 1px, because 39-38.=C2=A0 You probably can cal= culate correct
:ascent value to get exact value of ascent in %, but, unf= ortunatety,
ascent is integer and in general integer number of percents = is not
enough to get exact value (for example for fonts larger then 100p= x).
Also, this forces to modify :ascent value for the last slice, which<= br>leads to additional garbage.

`ch' and `cw' specifiers sol= ves two problems:
1) Makes it possible to create image intended for slic= es display
without gaps, and automatically adopts to text-scale changes.=

2) Makes it possible to align images precisely to the width of the<= br>given number of characters, especially this makes sense when monospacefont is used.=C2=A0 Also adopts to text-scale changes.

--
lg
--0000000000009f16760614bd9d3a--