From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.bugs Subject: bug#54688: 29.0.50; Sliced image in margin looks bad Date: Sun, 3 Apr 2022 15:05:44 +0200 Message-ID: References: <83zgl235pb.fsf@gnu.org> <83v8vq30aa.fsf@gnu.org> <83sfqu2x2o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000011536205dbbfac8d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17156"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 54688@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 03 15:07:10 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1nazwk-0004Kz-ME for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Apr 2022 15:07:10 +0200 Original-Received: from localhost ([::1]:36612 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nazwj-0007tx-Eg for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Apr 2022 09:07:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nazwc-0007to-W8 for bug-gnu-emacs@gnu.org; Sun, 03 Apr 2022 09:07:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54097) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nazwc-0004xF-Nc for bug-gnu-emacs@gnu.org; Sun, 03 Apr 2022 09:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nazwc-0006Cy-GS for bug-gnu-emacs@gnu.org; Sun, 03 Apr 2022 09:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Apr 2022 13:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54688 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 54688-submit@debbugs.gnu.org id=B54688.164899116423794 (code B ref 54688); Sun, 03 Apr 2022 13:07:02 +0000 Original-Received: (at 54688) by debbugs.gnu.org; 3 Apr 2022 13:06:04 +0000 Original-Received: from localhost ([127.0.0.1]:47993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nazvf-0006Bi-Is for submit@debbugs.gnu.org; Sun, 03 Apr 2022 09:06:03 -0400 Original-Received: from mail-yb1-f173.google.com ([209.85.219.173]:34600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nazvd-0006BC-8Y for 54688@debbugs.gnu.org; Sun, 03 Apr 2022 09:06:01 -0400 Original-Received: by mail-yb1-f173.google.com with SMTP id g9so13100606ybf.1 for <54688@debbugs.gnu.org>; Sun, 03 Apr 2022 06:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7hzcuvqTktlQ/fFA2znlIyDpUE7LKwkIjzElz4nFUx8=; b=GYqkIpsFvRcxPbZxsMuMWJJPD2GbYaQXqv29IQq73PT/8jrvUebbeMuL6vsJPjolf4 WyMpsW3F5ozvcJrDd5z4whAWo/KnCP+9oluQSzIAW2ns+RnVXFiBwMsUF0wHPdTsknMm LeVTM/PLICwRb3OjbiWotRj71SLU07I7KUyhDT48PuW9vndP78JdjBNVB9NY6RkczbJT 7qJy5WiZe7GWy002SfGE2wWcBFhAz7eDJEMd/aZGXpzlJBlQ+G7We7HXniw5Z54zS0oS /PNF5T8st/M2/XNjmj6OvSKmWtlIAxPP+OqShXMDyflZ01zs6aR8+p3+YysirQWE38UX 8smA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7hzcuvqTktlQ/fFA2znlIyDpUE7LKwkIjzElz4nFUx8=; b=n/v9Rn2Y8U1EFzRFKO4ZkA2rixa5uw46eYvnxB62DYwEsD2Esx4dMEEh1o88HpIuZU gvmgLeLsYU58cePS+qFNHEn+lECFYUO5EMlDyVQAjA5mzcybSkAhy+bOtEOQ+YV3nl+S 1gOHh6pZmnz3jBw1cF0mNyUlKkfvMtoLQIFrxjrCvj1QF9RLMy71SC/neBDOaQbUpg+s TU7ZmlXLihkZhtKXbYNXAr3+wj6IT5/7bDb+EpKz/72BtLD82d08FAdfoPEUb6UaIIVp WgEBpLICU4XCtez9h+swyXTFy1ZR21H/rdYcwoZmrMdLDOjx4RkHB7OYFF4FsY2HTaut MIEA== X-Gm-Message-State: AOAM530n8xRbI+6Nwwtc/wLz2GcqeqirI6CMh7mikwDgzbfQ4wdyyPng oe6VAj3Vim+JDqX3zIuJ8Ev0use0/35Fw0LKSoIZVICLMHXk0Q== X-Google-Smtp-Source: ABdhPJw6ZaKNqpL2r5LDxcGZ3Gxh/8NIG6Ml9nJ3NmKkR7Gu5ZEKUZmr0qNif399qzouY2mg9zuiVQdp8DaiB3sYSNk= X-Received: by 2002:a25:2fcf:0:b0:63d:9aa5:934c with SMTP id v198-20020a252fcf000000b0063d9aa5934cmr5147470ybv.488.1648991155605; Sun, 03 Apr 2022 06:05:55 -0700 (PDT) In-Reply-To: <83sfqu2x2o.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:229348 Archived-At: --00000000000011536205dbbfac8d Content-Type: text/plain; charset="UTF-8" > > Does this mean the problem is solved, and we can close this bug? I am not sure. It depends on what is the intended behavior. I would say it is desirable if inserting text after an image, of height equal to the text height, would not increase the `line-pixel-height`. The elisp manual mentions that the default value for :ascent is 50, in which case the `line-pixel-height` is larger than the both the 'image height' and the 'text height'. So maybe the default value of :ascent should be 80, in which case the 'line-pixel-height' 'remains' equal to the image height and text height. However, there might be various arguments for the current default value of 50 (and its behavior of increasing the 'line-pixel'height' when combining images with text on a single line). > I would think that this :ascent of 80, behaves how :ascent 50 (the > default) > > is supposed to behave? > > I don't think I understand the question. > I mean that I would expect the default behavior to be that, when combining images and text of equal height on a single line, the 'line-pixel-height' would also be/stay of equal height. But as mentioned before, there might be various arguments for the current behavior, however (as a layman) I am not aware of any. If the current behavior is the desired behavior, then indeed this issue can be closed. On Sun, 3 Apr 2022 at 14:03, Eli Zaretskii wrote: > > From: dalanicolai > > Date: Sun, 3 Apr 2022 13:03:27 +0200 > > Cc: 54688@debbugs.gnu.org > > > > Playing around with :ascent, makes possible to keep the > line-pixel-height fixed. > > > > So in the following I simply use `insert-image`. Without the :ascent, the > > 'line-pixel-height' increases when inserting another character. With the > > :ascent it is possible to reduce this 'increase'. For me the increase is > 0 > > when I use an ascent value of 80. > > (below the used code) > > > > (with-current-buffer (get-buffer-create "test") > > (setq left-margin-width 5) > > (insert-image (svg-image (let* ((ph (line-pixel-height)) > > (size ph) > > (svg (svg-create size size))) > > (svg-circle svg ph ph ph :fill "red") > > svg) > > :ascent 80)) > > (switch-to-buffer (current-buffer))) > > Does this mean the problem is solved, and we can close this bug? > --00000000000011536205dbbfac8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does thi= s mean the problem is solved, and we can close this bug?
<= br>
I am not sure. It depends on what is the intended behavior. I= would say it is desirable
if inserting text after an image, of h= eight equal to the text height, would not increase
the `line-pixe= l-height`. The elisp manual mentions that the default= value for :ascent is
50, in which case the `line-pixel-height` i= s larger than the both the 'image height' and
the 'te= xt height'. So maybe the default value of :ascent should be 80, in whic= h case
the 'line-pixel-height' 'remains' equal to= the image height and text height.

However, there = might be various arguments for the current default value of 50 (and its
behavior of increasing the 'line-pixel'height' when comb= ining images with text on a
single line).

> I would think that this :ascent of 80, behaves how :ascent 50 (the d= efault)
> is supposed to behave?

 I don't think I understand the question.

I mean that I would expect the default behavior to be that, when co= mbining images and
text of equal height on a single line, the = 9;line-pixel-height' would also be/stay of equal
height.
But as mentioned before, there might be various arguments for the cur= rent behavior,
however (as a layman) I am not aware of any.
=

If the current behavior is the desired behavior, then i= ndeed this issue can be closed.

On Sun, 3 Apr 2022 at 14:03, Eli Z= aretskii <eliz@gnu.org> wrote:
> From: dalanic= olai <dalanic= olai@gmail.com>
> Date: Sun, 3 Apr 2022 13:03:27 +0200
> Cc: 54688@d= ebbugs.gnu.org
>
> Playing around with :ascent, makes possible to keep the line-pixel-hei= ght fixed.
>
> So in the following I simply use `insert-image`. Without the :ascent, = the
> 'line-pixel-height' increases when inserting another character= . With the
> :ascent it is possible to reduce this 'increase'. For me the i= ncrease is 0
> when I use an ascent value of 80.
> (below the used code)
>
> (with-current-buffer (get-buffer-create "test")
>=C2=A0 =C2=A0(setq left-margin-width 5)
>=C2=A0 =C2=A0(insert-image (svg-image (let* ((ph (line-pixel-height)) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(size ph)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(svg (svg-create siz= e size)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (svg-circle svg ph ph ph :fill "red= ")
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 svg)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 :ascent 80))
>=C2=A0 =C2=A0(switch-to-buffer (current-buffer)))

Does this mean the problem is solved, and we can close this bug?
--00000000000011536205dbbfac8d--