# HG changeset patch # User Glenn Morris # Date 1283999431 25200 # Node ID dc71fe13a42c69f96f63c014b27a1975666672d0 # Parent 60d36a04fc8773d2bf9761dc5c6c35b90cbb9cc8 * README.imagemagick: Remove. * etc/NEWS: Move remaining ImageMagick items here. diff -r 60d36a04fc87 -r dc71fe13a42c README.imagemagick --- a/README.imagemagick Wed Sep 08 19:25:12 2010 -0700 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -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 -r 60d36a04fc87 -r dc71fe13a42c etc/TODO --- a/etc/TODO Wed Sep 08 19:25:12 2010 -0700 +++ b/etc/TODO Wed Sep 08 19:30:31 2010 -0700 @@ -625,6 +625,51 @@ 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