GNU bug report logs - #46554
27.1; 180 degree rotated image is displayed in slightly different position

Previous Next

To reply to this bug, email your comments to 46554 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; 180 degree rotated image is displayed in slightly different
 position
Date: Tue, 16 Feb 2021 18:45:30 +0900

THe form below displays same image with different :rotation.
The third image is rotated by 180 degree and is displayed in slightly
different position. There is one pixel gap on the top and left edges of
the image.

(let ((buf (generate-new-buffer "tmp"))
      (svg "<svg width=\"50\" height=\"50\"
 version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\">
<rect x=\"0.5\" y=\"0.5\" width=\"49\" height=\"49\"
 stroke-width=\"1\" stroke=\"red\"/>
</svg>"))
  (switch-to-buffer buf)
  (insert " ")
  (insert-image (create-image svg 'svg t :scale 1))
  (insert " ")
  (insert-image (create-image svg 'svg t :scale 1 :rotation 90))
  (insert " ")
  (insert-image (create-image svg 'svg t :scale 1 :rotation 180))
  (insert " ")
  (insert-image (create-image svg 'svg t :scale 1 :rotation 270))
  (insert " ")
  (put-text-property (point-min) (point-max) 'face '(:background "grey"))
  )



In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-22 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Pro (v10.0.1909.18363.1379)

Recent messages:

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-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
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(gnutls network-stream nsm mailalias smtpmail auth-source eieio
eieio-core cl-macs eieio-loaddefs json map rect wid-edit descr-text
mule-util cl-extra help-fns radix-tree misearch multi-isearch pp shadow
sort emacsbug sendmail mail-extr message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader cl-seq image-mode exif
term/bobcat help-mode easymenu cl-loaddefs cl-lib japan-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu 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 charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 78058 27524)
 (symbols 48 21222 0)
 (strings 32 81348 5793)
 (string-bytes 1 1941613)
 (vectors 16 17946)
 (vector-slots 8 1025340 97128)
 (floats 8 49 310)
 (intervals 56 1794 449)
 (buffers 1000 25))

Message #8 received at 46554 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ynyaaa <at> gmail.com
Cc: 46554 <at> debbugs.gnu.org
Subject: Re: bug#46554: 27.1; 180 degree rotated image is displayed in
 slightly different position
Date: Tue, 16 Feb 2021 14:06:40 +0100

ynyaaa <at> gmail.com writes:

> THe form below displays same image with different :rotation.
> The third image is rotated by 180 degree and is displayed in slightly
> different position. There is one pixel gap on the top and left edges of
> the image.
>
> (let ((buf (generate-new-buffer "tmp"))
>       (svg "<svg width=\"50\" height=\"50\"
>  version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\">
> <rect x=\"0.5\" y=\"0.5\" width=\"49\" height=\"49\"

[...]

> System Description: Microsoft Windows 10 Pro (v10.0.1909.18363.1379)

I'm unable to reproduce this on Debian bullseye, so perhaps it's a
Windows-specific problem?  My guess it that it's system-dependent where
the OS sets the midpoint when rotating?  The image here is 49 pixels
high, though, so the midpoint should be unambiguous, but...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 46554 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: ynyaaa <at> gmail.com
Cc: 46554 <at> debbugs.gnu.org
Subject: Re: bug#46554: 27.1; 180 degree rotated image is displayed in
 slightly different position
Date: Tue, 16 Feb 2021 21:15:42 +0000

On Tue, Feb 16, 2021 at 06:45:30PM +0900, ynyaaa <at> gmail.com wrote:
> 
> THe form below displays same image with different :rotation.
> The third image is rotated by 180 degree and is displayed in slightly
> different position. There is one pixel gap on the top and left edges of
> the image.
> 
> (let ((buf (generate-new-buffer "tmp"))
>       (svg "<svg width=\"50\" height=\"50\"
>  version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\">
> <rect x=\"0.5\" y=\"0.5\" width=\"49\" height=\"49\"
>  stroke-width=\"1\" stroke=\"red\"/>
> </svg>"))
>   (switch-to-buffer buf)
>   (insert " ")
>   (insert-image (create-image svg 'svg t :scale 1))
>   (insert " ")
>   (insert-image (create-image svg 'svg t :scale 1 :rotation 90))
>   (insert " ")
>   (insert-image (create-image svg 'svg t :scale 1 :rotation 180))
>   (insert " ")
>   (insert-image (create-image svg 'svg t :scale 1 :rotation 270))
>   (insert " ")
>   (put-text-property (point-min) (point-max) 'face '(:background "grey"))
>   )

Does this only happen with SVG files, or do you see the same thing
with other image types?

(Windows and NS use the same rotation logic, so I'd be surprised if
some rounding error manifested on one but not the other, although
perhaps there's some difference in compilers... Seems unlikely.)
-- 
Alan Third

Message #14 received at 46554 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: larsi <at> gnus.org, ynyaaa <at> gmail.com, 46554 <at> debbugs.gnu.org
Subject: Re: bug#46554: 27.1;
 180 degree rotated image is displayed in slightly different position
Date: Wed, 17 Feb 2021 21:57:29 +0200

[Message part 1 (text/plain, inline)]

Ouch, I responded to the wrong bug report.  Redirecting.

> Date: Wed, 17 Feb 2021 19:26:38 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: larsi <at> gnus.org, ynyaaa <at> gmail.com, 46556 <at> debbugs.gnu.org
> 
> > I've now stepped through the code which implements rotation, and I see
> > nothing wrong with the results.  The pixel coordinates of the rotated
> > square are exact and accurate, without any roundoff that I could spot.
> > Each square starts exactly 50+8 = 58 pixels after the previous one (8
> > pixels are taken by the SPC character between the squares), and ends
> > exactly 50 pixels after it starts.
> > 
> > So I have no idea why the one-pixel shift happens.  Of course, I don't
> > really understand what that code does (although I hacked it quite
> > extensively), so maybe someone who really understands that stuff could
> > take a look and tell what's wrong there.
> 
> Can either you or the OP provide a screenshot? It's not entirely clear
> to me what's happening. It sounds like some of the behaviour of this
> bug would be explained by the mask not being rotated with the image,
> but other bits of the description don't seem to match that.

I attach a screenshot, note the 3rd square from the left, where the
red square line seems to be 1 pixel off to the right and down of the
black background.

> The other bug with the single pixel white line sounds more like an
> off-by-one in SVG production, but you'd see that in every image, so
> it's probably not that.

That's the bug I was talking about.  I didn't look closely at
bug#46556, as it talks about transparency, something I have no idea
how it works and indeed whether it's at all supported on MS-Windows.

[squares.PNG (image/png, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.