GNU bug report logs - #7556
24.0.50; visiting an EPS file with preview TIFF image and with one long line

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#7556: closed (24.0.50; visiting an EPS file with preview TIFF
 image and with one long line)
Date: Tue, 07 Dec 2010 18:39:03 +0000

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

Your message dated Tue, 07 Dec 2010 20:44:39 +0200
with message-id <83lj412zjc.fsf <at> gnu.org>
and subject line Re: bug#7556: 24.0.50; visiting an EPS file with preview TIFF image and with one long line
has caused the GNU bug report #7556,
regarding 24.0.50; visiting an EPS file with preview TIFF image and with one long line
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
7556: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7556
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50;
	visiting an EPS file with preview TIFF image and with one long line
Date: Sat, 4 Dec 2010 22:59:29 +0100

Hello!

I have an EPS file created by Adobe Illustrator 15 with a "DOS EPS  
Binary File Header" according to 5002.EPSF_Spec and a TIFF preview at  
the end, in mac-roman-mac encoding. Size: 643 KB. When I visit that  
file from a dired buffer in PostScript DocView View mode and scroll  
down near the end of the PostScript section where the TIFF preview  
starts, it happens that GNU Emacs becomes inoperable for seven hours  
while consuming all remaining CPU power. The first line of the TIFF  
section, starting with II*, is approximately 314,899 characters  long  
(GNU Emacs is a bad tool, it counts ASCII NUL ^@ as two columns).  
Rendering this in a window of 55 lines and around 120 columns takes  
these 7 h. And more: GNU Emacs creates a #file.eps# backup file,  
larger in size (50 %) than the original file. Is that the expected  
behaviour?

In GNU Emacs 24.0.50.1 (powerpc-apple-darwin9.8.0, X toolkit, Xaw3d  
scroll bars)
 of 2010-11-13 on localhost
Windowing system distributor `The X.Org Foundation', version  
11.0.10902901
configured using `configure  '--without-sound' '--without-dbus' '-- 
without-pop' '--without-gconf' '--with-x-toolkit=athena' '--x- 
libraries=/usr/X11/lib' '--x-includes=/usr/X11/include' '--with- 
imagemagick' '--enable-locallisppath=/Library/Application Support/ 
Emacs/calendar24:/Library/Application Support/Emacs' 'CFLAGS=-g -H - 
pipe -fPIC -fno-common -mcpu=7450 -mtune=7450 -faltivec -fast'  
'CPPFLAGS=-I/usr/local/include -idirafter /sw/include' 'LDFLAGS=-L/usr/ 
local/lib -Wl,-dead_strip_dylibs' 'CC=gcc-4.2' 'CPP=cpp-4.2'  
'PKG_CONFIG_PATH=/sw/lib/pango-ft219/lib/pkgconfig:/sw/lib/xft2/lib/ 
pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/freetype219/lib/ 
pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/sw/lib/ 
pkgconfig:/sw/share/pkgconfig:/usr/lib/pkgconfig:/usr/X11/lib/ 
pkgconfig:/usr/X11/share/pkgconfig''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: de_DE.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Calendar

Minor modes in effect:
  TeX-PDF-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  show-paren-mode: t
  display-time-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-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
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t



--
Greetings

  Pete

Without vi there is only GNU Emacs

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: 7556-done <at> debbugs.gnu.org
Subject: Re: bug#7556: 24.0.50;
	visiting an EPS file with preview TIFF image and with one long line
Date: Tue, 07 Dec 2010 20:44:39 +0200

> Cc: 7556 <at> debbugs.gnu.org
> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Tue, 7 Dec 2010 10:43:33 +0100
> 
> The elder NS variant is faster than the X client and did not produce a  
> backup file. I did not wait until the up-to-date X client finished  
> scrolling or creating the backup file but killed it with xkill. *This*  
> produced the backup file. The date of this file and that of my action  
> is the same, to the minute. Previously I killed GNU Emacs when it  
> became inoperable and not knowing the cause of this behaviour. After  
> this I visited the directory in dired mode and saw the backup files  
> and concluded they might have been created when GNU Emacs started to  
> consume all CPU power–now in some irregular working mode–while in fact  
> this was perhaps a minute later when I killed it.

Yes, when Emacs catches a fatal signal, it auto-saves.  This is normal
behavior.

Closing.  Thanks for looking into this.

Previous Next

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