* README.imagemagick: Remove.

* etc/NEWS: Move remaining ImageMagick items here.

2 files changed, 45 insertions, 151 deletions

diff --git a/README.imagemagick b/README.imagemagick
deleted file mode 100644
index 792e9fd90ea..00000000000
--- a/README.imagemagick
+++ /dev/null
@@ -1,151 +0,0 @@
-* README for the ImageMagick Emacs branch
-
-This is the imagemagick branch of Emacs. Imagemagick can now be used
-to load many new image formats, and also do useful transforms like
-scaling and rotation.
-
-This file will attempt to contain draft NEWS, Changelog and manual
-entries for the new functionality. 
-
-You might need to regenerate the configure scripts:
-aclocal
-automake
-autoheader
-autoconf
-./configure --with-imagemagick
-
-
-* TODO  image-type-header-regexps priorities the jpeg loader over the
-imagemagick one. This is not wrong, but how should a user go about
-prefering the imagemagick loader? The user might like zooming etc in
-jpegs. 
-
-try (setq image-type-header-regexps nil) for a quick hack to prefer
-imagemagick over the jpg loader.
-
-* TODO  For some reason its unbearably slow to look at a page in a large
-  image bundle using the :index feature. The imagemagick "display"
-  command is also a bit slow, but nowhere near as slow as the emacs
-  code. It seems imagemagick tries to unpack every page when loading
-  the bundle. This feature is not the primary usecase for the
-  imagemagick patch though.
-
-  ImageMagick 6.6.2-9 introduced a bugfix for single page djvu load.
-  It is now way faster to use the :index feature, but its still not
-  very fast.
-
-** DONE optimize number of pages calculation for bundles as suggested by
-  imagemagick forum: "set the density to something low like 2 and use
-  MagickPingImage()"
-  
-** TODO try to cache the num pages calculation. it can take a while to
-  calculate the number of pages, and if you need to do it for each
-  page view, page-flipping becomes uselessly slow.
-
-* TODO integrate with image-dired
-
-* TODO integrate with docview. 
-  
-* TODO integrate with image-mode
-Some work has been done, M-x image-transform-fit-to-height will fit
-the image to the height of the Emacs window for instance.
-
-* TODO look for optimizations for handling images with low depth
-Currently the code seems to default to 24 bit RGB which is costly for
-images with lower bit depth.
-
-* TODO complete documentation drafts below
-
-* DONE fix inconsistencys with spelling of imagemagick in the src
-* DONE report number of images in image bundle types somehow
-Works like for "gif" support. Thanks to Juri Linkov.
-* DONE probably add pdf to inhibited types
-* DONE inhibit types is defconst should probably be defcustom
-* TODO decide what to do with some uncommitted imagemagick support
-  functions for image size etc.
-* TODO Test with more systems
-Tested on Fedora 12, Fedora 14 so far, and the libmagick that ships with it.
-Ubuntu 8.04 was also tested, but it seems it ships a broken
-ImageMagick.
-
-I also tried using an imagemagick compiled from their SVN, in
-parallell with the one packaged by Fedora, it worked well.
-
-* DONE Also need some way to handle render methods that only work on newer ImageMagicks
-Is handled by configure now
-
-* Some nits from Stefan Monnier
-I just took a quick look at the code and I see the following nits to fix:
-
-** DONE obviously a merge will have to come with a good ChangeLog.
-** DONE also the merge will need to come with documentation.  Maybe not in the
-   Texinfo form yet, but at least in the etc/NEWS with enough info that
-   describes the `scale' and other such arguments that someone can start
-   using them.
-** DONE the README talks about naming inconsistencies, I think these should be
-  fixed before a first commit (should be straightforward).
-
-** DONE the "let" in image.el should not be followed by a line break and the while
-   should be replaced by a dolist.
-
-** DONE the prototype of imagemagick_load_image has some odd indentation in ([[2010.06.14]])
-   its args, not sure what happened.
-** DONE a few lines in the C code break the 80columns limit.
-** DONE please use ANSI style function declarations rather than K&R for new code. ([[2010.06.14]])
-** DONE you can get rid of the prototypes by reordering the code. ([[2010.06.14]])
-** DONE the docstrings in DEFUN should not be indented (they'll display ([[2010.06.14]])
-   weirdly otherwise in C-h f).
-** DONE Some "{" are at the end of a for/if rather than on their own line. ([[2010.06.14]])
-** DONE why use "*( imtypes + i)" rather than "imtypes[i]"? ([[2010.06.14]])
-** DONE some "," lack a space after them. ([[2010.06.14]])
-** DONE several "=" and "==" lack spaces around them. ([[2010.06.14]])
-  
-
-* NEWS entry
-** ImageMagick support
-It is now possible to use the Imagemagick library to load many new
-image formats in Emacs.
-
-To enable, use the following configure option:
---with-imagemagick
-
-The new function (imagemagick-types) returns a list of image file
-extensions that your installation of imagemagick supports.
-
-The function (imagemagick-register-types) will enable the imagemagick
-support for the extensions in imagemagick-types minus the types listed
-in imagemagick-types-inhibit.
-
-imagemagick-types-inhibit has the value  '(C HTML HTM TXT PDF) by default.
-This means imagemagick will be used also to load jpeg files, if you
-have both jpeg and imagemagick libraries linked. Add 'JPG to
-imagemagick-types-inhibit if you do not want this.
-
-imagemagick-render-type is a new variable which can be set to choose
-between screen render methods.
-
-- 0 is a conservative metod which works with older ImageMagick
-  versions. It is a bit slow, but robust.
-
-- 1 utilizes a newer ImageMagick method   
-
-
-Images loaded with imagemagick will support a couple of new display
-specification behaviours:
-
-- if the :width and :height keywords are specified, these values are
-used for scaling the image. If only one of :width or :height is
-specified, the other one will be calculated so as to preserve the
-aspect ratio.If both :width and :height are specified, aspect ratio
-will not be preserved.
-
-- :rotation specifies a rotation angle in degrees.
-
-- :index specifies which image inside an image bundle file format, such
-as TIFF or DJVM, to view.
-
-The image-metadata function can be used to retrieve the total number
-of images in an image bundle. This is simmilar to how GIF files work.
-
-* Manual entry
-nothing yet, but the NEWS entry could be adapted.
diff --git a/etc/TODO b/etc/TODO
index d58eb8be3d8..e76e1054043 100644
--- a/etc/TODO
+++ b/etc/TODO
@@ -625,6 +625,51 @@ http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02234.html
    the window associated with that modeline.
    http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg02416.html
 
+* Things to be done for specific packages or features
+
+** ImageMagick support
+
+*** image-type-header-regexps priorities the jpeg loader over the
+ImageMagick one.  This is not wrong, but how should a user go about
+prefering the ImageMagick loader?  The user might like zooming etc in jpegs.
+
+Try (setq image-type-header-regexps nil) for a quick hack to prefer
+ImageMagick over the jpg loader.
+
+*** For some reason its unbearably slow to look at a page in a large
+image bundle using the :index feature.  The ImageMagick "display"
+command is also a bit slow, but nowhere near as slow as the Emacs
+code.  It seems ImageMagick tries to unpack every page when loading the
+bundle.  This feature is not the primary usecase in Emacs though.
+
+ImageMagick 6.6.2-9 introduced a bugfix for single page djvu load.  It
+is now much faster to use the :index feature, but still not very fast.
+
+*** Try to cache the num pages calculation.  It can take a while to
+calculate the number of pages, and if you need to do it for each page
+view, page-flipping becomes uselessly slow.
+
+*** Integrate with image-dired.
+
+*** Integrate with docview. 
+  
+*** Integrate with image-mode.
+Some work has been done, e.g. M-x image-transform-fit-to-height will
+fit the image to the height of the Emacs window.
+
+*** Look for optimizations for handling images with low depth.
+Currently the code seems to default to 24 bit RGB which is costly for
+images with lower bit depth.
+
+*** Decide what to do with some uncommitted imagemagick support
+functions for image size etc.
+
+*** Test with more systems.
+Tested on Fedora 12, 14, and the libmagick that ships with it.
+I also tried using an ImageMagick compiled from their SVN, in
+parallel with the one packaged by Fedora, it worked well.
+Ubuntu 8.04 was tested, but it seems it ships a broken ImageMagick.
+
 * Internal changes
 
 ** Cleanup all the GC_ mark bit stuff -- there is no longer any distinction