http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5738 Doug Dearden <dearden@sarsf.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Hours Worked| |8 Remaining Hours|16.0 |8.0 --- Comment #13 from Doug Dearden <dearden@sarsf.org> 2011-03-16 15:06:19 UTC --- (In reply to comment #12)
I haven't tested this yet, but I have a comment. This initial patch doesn't seem to support MIME types (e.g. "image/jpeg") in the subfield 'q'. Is there a specific reason why you feel that this feature shouldn't be activated by "image/jpeg", or would you be open to a follow-up patch?
Regards, Jared
Jared - The image display is triggered off a MIME extension in 856q ("jpg", not "image/jpeg"). Currently it is looking for one of 23 MIME extensions - bmp, cod, gif, ief, jpe, jpeg, jpg, jfif, png, svg, tif, tiff, ras, cmx, ico, pnm, pbm, pgm, ppm, rgb, xbm, xpm, xwd . I also added a generic "img" option. I am fine with the feature being activated in whatever way the community feels is valid, but kept it to the MIME extensions for a couple of reasons. First this creates a rather long "or" statement in the code that will get even longer if we add image/jpeg, image/gif, etc. Secondly Ian Walls and I communicated about the need for a script that would populate the 856q field based on the value in the 856u field, and my thought on that was to check the file extension at the end of the URI in the 856u field, and if it is one of the 23 MIME extensions copy it into the 856q field (if empty). I suppose we could use MIME types instead of MIME extensions, but I don't see any reason to use both. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.