unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#54688: 29.0.50; Sliced image in margin looks bad
@ 2022-04-03  6:50 dalanicolai
  2022-04-03  8:57 ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: dalanicolai @ 2022-04-03  6:50 UTC (permalink / raw)
  To: 54688

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

Passing 'left-margin' for the AREA parameter in `insert-sliced-image`
results in bad looking image. To reproduce from `emacs -q` evaluate the
following code example:

(with-current-buffer (get-buffer-create "test")
  (setq left-margin-width 5)
  (insert-sliced-image (svg-image (let* ((ph (line-pixel-height))
                                         (size (* 2 ph))
                                         (svg (svg-create size size)))
                                    (svg-circle svg ph ph ph :fill "red")
                                    svg))
                       nil
                       'left-margin
                       2)
  (switch-to-buffer (current-buffer)))

when instead of 'left-margin', nil is passed as value (i.e. the text is
inserted in the text area), then everything looks fine.

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31,
cairo version 1.17.4)
 of 2022-01-29 built on fedora
Repository revision: 96533c18b7f9d75dce9e6bb534a16ed4ccf44ad1
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 35 (Workstation Edition)

Configured using:
 'configure --with-modules --with-cairo --with-native-compilation
 --with-json'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  marginalia-mode: t
  savehist-mode: t
  vertico-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  recentf-mode: t
  shell-dirtrack-mode: t
  evil-mode: t
  evil-local-mode: t
  windmove-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message yank-media rmc dired
dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config gnus-util
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mule-util cursor-sensor format-all language-id inheritenv
gitter derived pcase let-alist posframe transient format-spec request
autorevert filenotify mail-utils notifications dbus avy
shr-tag-pre-highlight language-detection shr text-property-search
pixel-fill kinsoku puny svg xml ewoc marginalia savehist orderless
vertico evil-surround evil-nerd-commenter evil-nerd-commenter-operator
evil-nerd-commenter-sdk sgml-mode facemenu dom which-key bind-map
recentf tree-widget wid-edit evil evil-keybindings evil-integration
evil-maps evil-commands reveal flyspell ispell evil-jumps
evil-command-window evil-types evil-search evil-ex shell pcomplete
comint ansi-color evil-macros evil-repeat evil-states evil-core comp
comp-cstr warnings rx advice evil-common windmove thingatpt rect
evil-digraphs evil-vars ring edmacro kmacro undo-tree diff cl-extra
help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core finder-inf info 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 cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map url-vars seq
gv subr-x byte-opt bytecomp byte-compile cconv cl-loaddefs cl-lib
chemacs 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
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 350688 17872)
 (symbols 48 22237 1)
 (strings 32 115274 5006)
 (string-bytes 1 3507701)
 (vectors 16 225348)
 (vector-slots 8 1419197 79043)
 (floats 8 90951 50)
 (intervals 56 651 0)
 (buffers 992 13))

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03  6:50 bug#54688: 29.0.50; Sliced image in margin looks bad dalanicolai
@ 2022-04-03  8:57 ` Eli Zaretskii
  2022-04-03 10:33   ` dalanicolai
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2022-04-03  8:57 UTC (permalink / raw)
  To: dalanicolai; +Cc: 54688

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Sun, 3 Apr 2022 08:50:20 +0200
> 
> Passing 'left-margin' for the AREA parameter in `insert-sliced-image`
> results in bad looking image. To reproduce from `emacs -q` evaluate the
> following code example:
> 
> (with-current-buffer (get-buffer-create "test")
>   (setq left-margin-width 5)
>   (insert-sliced-image (svg-image (let* ((ph (line-pixel-height))
>                                          (size (* 2 ph))
>                                          (svg (svg-create size size)))
>                                     (svg-circle svg ph ph ph :fill "red")
>                                     svg))
>                        nil
>                        'left-margin
>                        2)
>   (switch-to-buffer (current-buffer)))
> 
> when instead of 'left-margin', nil is passed as value (i.e. the text is
> inserted in the text area), then everything looks fine.

"Everything looks fine" until you insert some text after the 2 slices
of the image.  That is, after evaluating the form with left-margin
replaced by nil, do this:

  C-u 2 M-g c  ;; go to buffer position 2
  x            ;; insert a character
  C-n          ;; go to next line
  x            ;; insert another character

The problem is that your images are smaller than the default height of
the screen line, as determined by the 'default' face.  So slices of
the image do not produce a single circle, but two semi-circles with
empty space between them.

If this is the problem, then I see nothing wrong with this: to have
the two slices come together, you need to fit the size of the image to
the height of the default face.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03  8:57 ` Eli Zaretskii
@ 2022-04-03 10:33   ` dalanicolai
  2022-04-03 10:54     ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: dalanicolai @ 2022-04-03 10:33 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 54688

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

Thank you for the quick reply. However, the height of the image,
(* 2 (line-pixel-height)), is equal to twice the `default-font-height`
(the 'line-pixel-height' and 'default-font-height' are equal, here both
17).

So before I add the character after the image, (line-pixel-height)
returns 17. But when I insert a character after it (with
'default-font-height' is 17), the `line-pixel-height` increases to
22. So I am not sure how to not let the line height increase.
I will try to play a little with the :ascent value.

On Sun, 3 Apr 2022 at 10:57, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: dalanicolai <dalanicolai@gmail.com>
> > Date: Sun, 3 Apr 2022 08:50:20 +0200
> >
> > Passing 'left-margin' for the AREA parameter in `insert-sliced-image`
> > results in bad looking image. To reproduce from `emacs -q` evaluate the
> > following code example:
> >
> > (with-current-buffer (get-buffer-create "test")
> >   (setq left-margin-width 5)
> >   (insert-sliced-image (svg-image (let* ((ph (line-pixel-height))
> >                                          (size (* 2 ph))
> >                                          (svg (svg-create size size)))
> >                                     (svg-circle svg ph ph ph :fill "red")
> >                                     svg))
> >                        nil
> >                        'left-margin
> >                        2)
> >   (switch-to-buffer (current-buffer)))
> >
> > when instead of 'left-margin', nil is passed as value (i.e. the text is
> > inserted in the text area), then everything looks fine.
>
> "Everything looks fine" until you insert some text after the 2 slices
> of the image.  That is, after evaluating the form with left-margin
> replaced by nil, do this:
>
>   C-u 2 M-g c  ;; go to buffer position 2
>   x            ;; insert a character
>   C-n          ;; go to next line
>   x            ;; insert another character
>
> The problem is that your images are smaller than the default height of
> the screen line, as determined by the 'default' face.  So slices of
> the image do not produce a single circle, but two semi-circles with
> empty space between them.
>
> If this is the problem, then I see nothing wrong with this: to have
> the two slices come together, you need to fit the size of the image to
> the height of the default face.
>

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03 10:33   ` dalanicolai
@ 2022-04-03 10:54     ` Eli Zaretskii
  2022-04-03 11:03       ` dalanicolai
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2022-04-03 10:54 UTC (permalink / raw)
  To: dalanicolai; +Cc: 54688

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Sun, 3 Apr 2022 12:33:01 +0200
> Cc: 54688@debbugs.gnu.org
> 
> Thank you for the quick reply. However, the height of the image,
> (* 2 (line-pixel-height)), is equal to twice the `default-font-height`
> (the 'line-pixel-height' and 'default-font-height' are equal, here both
> 17).
> 
> So before I add the character after the image, (line-pixel-height)
> returns 17. But when I insert a character after it (with
> 'default-font-height' is 17), the `line-pixel-height` increases to
> 22. So I am not sure how to not let the line height increase.
> I will try to play a little with the :ascent value.

Images can also have margins:

  int
  image_ascent (struct image *img, struct face *face, struct glyph_slice *slice)
  {
    int height;
    int ascent;

    if (slice->height == img->height)
      height = img->height + img->vmargin;
    else if (slice->y == 0)
      height = slice->height + img->vmargin;
    else
      height = slice->height;

Maybe those make the difference?

In any case, once I add a character, the line height grows, which
tells us some vertical dimension somewhere is unaccounted for.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03 10:54     ` Eli Zaretskii
@ 2022-04-03 11:03       ` dalanicolai
  2022-04-03 11:04         ` dalanicolai
  2022-04-03 12:03         ` Eli Zaretskii
  0 siblings, 2 replies; 10+ messages in thread
From: dalanicolai @ 2022-04-03 11:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 54688

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

(Once more using reply-all)

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)))

On Sun, 3 Apr 2022 at 12:54, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: dalanicolai <dalanicolai@gmail.com>
> > Date: Sun, 3 Apr 2022 12:33:01 +0200
> > Cc: 54688@debbugs.gnu.org
> >
> > Thank you for the quick reply. However, the height of the image,
> > (* 2 (line-pixel-height)), is equal to twice the `default-font-height`
> > (the 'line-pixel-height' and 'default-font-height' are equal, here both
> > 17).
> >
> > So before I add the character after the image, (line-pixel-height)
> > returns 17. But when I insert a character after it (with
> > 'default-font-height' is 17), the `line-pixel-height` increases to
> > 22. So I am not sure how to not let the line height increase.
> > I will try to play a little with the :ascent value.
>
> Images can also have margins:
>
>   int
>   image_ascent (struct image *img, struct face *face, struct glyph_slice
> *slice)
>   {
>     int height;
>     int ascent;
>
>     if (slice->height == img->height)
>       height = img->height + img->vmargin;
>     else if (slice->y == 0)
>       height = slice->height + img->vmargin;
>     else
>       height = slice->height;
>
> Maybe those make the difference?
>
> In any case, once I add a character, the line height grows, which
> tells us some vertical dimension somewhere is unaccounted for.
>

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03 11:03       ` dalanicolai
@ 2022-04-03 11:04         ` dalanicolai
  2022-04-03 12:02           ` Eli Zaretskii
  2022-04-03 12:03         ` Eli Zaretskii
  1 sibling, 1 reply; 10+ messages in thread
From: dalanicolai @ 2022-04-03 11:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 54688

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

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

On Sun, 3 Apr 2022 at 13:03, dalanicolai <dalanicolai@gmail.com> wrote:

> (Once more using reply-all)
>
> 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)))
>
> On Sun, 3 Apr 2022 at 12:54, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: dalanicolai <dalanicolai@gmail.com>
>> > Date: Sun, 3 Apr 2022 12:33:01 +0200
>> > Cc: 54688@debbugs.gnu.org
>> >
>> > Thank you for the quick reply. However, the height of the image,
>> > (* 2 (line-pixel-height)), is equal to twice the `default-font-height`
>> > (the 'line-pixel-height' and 'default-font-height' are equal, here both
>> > 17).
>> >
>> > So before I add the character after the image, (line-pixel-height)
>> > returns 17. But when I insert a character after it (with
>> > 'default-font-height' is 17), the `line-pixel-height` increases to
>> > 22. So I am not sure how to not let the line height increase.
>> > I will try to play a little with the :ascent value.
>>
>> Images can also have margins:
>>
>>   int
>>   image_ascent (struct image *img, struct face *face, struct glyph_slice
>> *slice)
>>   {
>>     int height;
>>     int ascent;
>>
>>     if (slice->height == img->height)
>>       height = img->height + img->vmargin;
>>     else if (slice->y == 0)
>>       height = slice->height + img->vmargin;
>>     else
>>       height = slice->height;
>>
>> Maybe those make the difference?
>>
>> In any case, once I add a character, the line height grows, which
>> tells us some vertical dimension somewhere is unaccounted for.
>>
>

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03 11:04         ` dalanicolai
@ 2022-04-03 12:02           ` Eli Zaretskii
  0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2022-04-03 12:02 UTC (permalink / raw)
  To: dalanicolai; +Cc: 54688

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Sun, 3 Apr 2022 13:04:55 +0200
> Cc: 54688@debbugs.gnu.org
> 
> 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.

(Is it still relevant, given your followup?)





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03 11:03       ` dalanicolai
  2022-04-03 11:04         ` dalanicolai
@ 2022-04-03 12:03         ` Eli Zaretskii
  2022-04-03 13:05           ` dalanicolai
  1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2022-04-03 12:03 UTC (permalink / raw)
  To: dalanicolai; +Cc: 54688

> From: dalanicolai <dalanicolai@gmail.com>
> 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?





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03 12:03         ` Eli Zaretskii
@ 2022-04-03 13:05           ` dalanicolai
  2022-04-03 13:09             ` dalanicolai
  0 siblings, 1 reply; 10+ messages in thread
From: dalanicolai @ 2022-04-03 13:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 54688

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

>
> 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
<https://www.gnu.org/software/emacs/manual/html_node/elisp/Image-Descriptors.html>
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 <eliz@gnu.org> wrote:

> > From: dalanicolai <dalanicolai@gmail.com>
> > 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?
>

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#54688: 29.0.50; Sliced image in margin looks bad
  2022-04-03 13:05           ` dalanicolai
@ 2022-04-03 13:09             ` dalanicolai
  0 siblings, 0 replies; 10+ messages in thread
From: dalanicolai @ 2022-04-03 13:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 54688

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

In the first sentence, I mean text of the same height as the image height.
When I say 'current behavior' I mean that the 'line-pixel-height' when
combining
images and text of equal height on a single line, is larger than the
text/image height.

On Sun, 3 Apr 2022 at 15:05, dalanicolai <dalanicolai@gmail.com> wrote:

> 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
> <https://www.gnu.org/software/emacs/manual/html_node/elisp/Image-Descriptors.html>
> 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 <eliz@gnu.org> wrote:
>
>> > From: dalanicolai <dalanicolai@gmail.com>
>> > 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?
>>
>

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-04-03 13:09 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-04-03  6:50 bug#54688: 29.0.50; Sliced image in margin looks bad dalanicolai
2022-04-03  8:57 ` Eli Zaretskii
2022-04-03 10:33   ` dalanicolai
2022-04-03 10:54     ` Eli Zaretskii
2022-04-03 11:03       ` dalanicolai
2022-04-03 11:04         ` dalanicolai
2022-04-03 12:02           ` Eli Zaretskii
2022-04-03 12:03         ` Eli Zaretskii
2022-04-03 13:05           ` dalanicolai
2022-04-03 13:09             ` dalanicolai

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).