zifimage

Introduction

This is my first attempt at a Drupal module. I undertook the project based on my need to display large panoramic images in a view-port scenic setting. The old zoomify module had flaws. It caused directory bloat (at least on my system). Many of my images require over 1000 tiles converting all images on my site caused its directory structure to exceed Hostmonster's recommended limits. I could saw no way around this and abandoned the use of the viewer. After a while, actually a year or a few years, I became aware that Zoomify had come up with a modified big tiff format file which would allow my thousands of tile files to be combined into a single entity. Thus solving the directory bloat problem. I tried to get the maintainers for the zoomify module to add this support but I was unable to contact them. I have had no contact with them in any form for over two years. I decided if I wanted it done I'd have to do it myself and so we have this sandbox project

Features deleted

I found that I had to delete a few features some that I thought were not needed in the first place and others that were surprising to me.

Support for generation of tiles

I found that the generation of tile file by your own module was in fact considered a violation of the viewer's license by the Zoomify company. So that ability had to go regardless of its usefulness.. Of course I don't believe that it is of any real use. Basically if your website has images on it now that can be displayed adequately by scaling these images cannot be effectively zoomified. They will inevitably be too small and give poor results when magnified.

Support for uploading Sets of tiles

while I found that you could generate individual tile files with the free converter program. Handling these files is complicated. After all you may have 1000 1500 files in many tears. Uploading 1500 files is not a trivial matter. If so I decided that I would simply not support it. The whole point of this module is to get away form individual tiles afterall.

Support for the free viewer.
Zoomify has a free viewer. I was surprised to find out that this viewer is only capable of recognizing the tile file system. It will not support the zip file format. I briefly considered adding the ability to upload tile files so that people who wanted Psalms ability to use a modified images but who did not wish to actually buy the more advanced versions could still use the module. In the end I decided against it. I think that the zoomify companies products are reasonably priced and sufficiently powerful that they should be paid for. And you can afford to pay for them and that their licensing terms are not particularly onerous. You can expect to pay on the order of $50 for these programs.

Features Added

I have talked about the areas where preachers had to be eliminated and now let me go on to enumerate features which I believe need to be added to have a actually functional program.

Support for the zif format

The most importance to me was the addition of support for the zip format. This actually was the easiest feature to implement one simply has to get the viewer that supports the zip format and pass it the entire file name and path for the zip file this is pretty much a trivial case. It works and works well at least on my system.(Win 10/Mysql/PHP/Apache)

Support for use on XML controls

The advanced applications of the zoomify viewer are quite fascinating and are generally controlled via the use of XML files. Thus to implement the use of the system for comparisons animations virtual tours and other items is only necessary to be able to pass the viewer the requisite XML file. Drupal hass a facility that allows you to have multiple entries on a single field. So any node can have one or more XML files. This should allow far better usage of these in the viewer and it's fmore complex capabilities. One of the things I will try to do eventually is to take the example code sent by Zoomify company and set up a set of examples so that you can see just how this arrangement can be used with this module.. I may evan write something of xml file generator to aid in authoring tours and other advanced configuration.

Support for Configurable Default Values

When I first reviewed the zoomify module I noticed that it possessed an extensive configuration form. The problem is that all the commands are applied to every zoomified file in the entire site. This one size fits all concept strikes me as inane. I know that some people believe that you should constrain your images by of the framing system. But I have never found that to be reasonable. The image determines its own size based on artistic considerations rather than a robotic performance to a rule.
So I have decided to come up with a system where by default values are made available which can be applied throughout a site provide a basis of uniformity but which can be overridden at need to provide necessary flexibility in design.. My initial attempt at this was very cumbersome and while I have left it in place I intend that it be replaced in a future edition. What is this from the configuration file that applies to the site and I look to see if that command is in the command string supplied by the nose if it isn't there I stick it in if it's fair I do not. This is done on every page load. I had thought about attempting to maintain a combined command string as a separate entity in the database but I found that keeping it current would be problems. Not only that but it's possible our probable that ridiculous sets of commands could be created. For instance you can set the initial zoom level of your image you can also tell the image to zoom until it fills the viewer size you would not necessarily want to do both but which command override switch I'm not sure but I don't want to have to try and sort any of that out. For ease of use its simplest just to present all the requisite variables in the know dad for and read their default values from the sitewide variables. The sitewide variables will have default values which are reasonable and which can be overridden as desired. These can be displayed as collapsible array and if you need to override one you can. But I'm not there yet

Support for bi-level input validation

there's a lot of talkon the Drupal systems about not trusting user input. I could not find a good method of sanitizing user input stream areas by use of Drupal's internal functions. I devised my own systgem. The first level being restricting the input character strings to alphanumeric characters along with those characters necessary to allow input of pass and the separation and indication of values. A more intense level of scrutiny is also available and consists of the ability to parse the command string in the command value pairs.. Each command can be compared with the available zoomify commands and if it is not listed within the command set it is held to be invalid. For every valid command and expected value type is determined and return. This allows the value to be examined to see that it is of the type that it is supposed to be. The only problem with this is that there are 196 commands and I have not had time to test most of them. I very poor with regex in this routine is regex heavy. I have simply taken the regex expressions from published works on the web. The system is configurable in that you can select the level of scrutiny you want to apply both to the sitewide configuration command area and the note command area. If he gives you trouble turn it off. Or of course the alternative is to just go and fix it it's very simple just a giant switch with regex expressions.

Current Status

What works

currently the zip file support works quite well. At least on Windows can. There are problems in generating for Linux systems. .this mainly affects the selection of skins for the toolbar. Needless to say this problem is my focus at this time.

What needs work

there are many areas that need work. In particular I need to implement a reasonable method of supplying configurable default values to the node at four. I am not familiar with forms in Drupal and I have to say that using forms has been a very hard slog. The problem I'm facing is that much of the code that is posted on the Internet and used in books simply doesn't work. Once I attempted to parse out the various form components by hand. I found that one set of the $form_values array returned some 13 K. When dumped through a text editor this generated some 10,000 lines of code far more than I could parse through. I also found that some of what looked to be values were not updated so that you could fail a validation go back to the form change the text and then find that the old text is still presented as a current value I did not find a truly satisfying solution to this problem. However I did get it to work.

The XML files while present have not been tested to any extent. I presume that they will in fact fail initial testing and changes in this area will be needed. Some changes may be conceptual as I do not know for sure whether you must pass only a single file or multiple XML files to the viewer. I have referred this question to Zoomify support.

The directory structure is still under development. At the present time I'm using the public
file system and I am placing all the files under the project name in the default file.. Each type of file has its own subdirectory so that all the images will be in an image subdirectory all the zip files in the zip file subdirectory. There are many other files that could be uploaded into the system. Many of these files are of a generic nature and could be shared among different notes. In fact even possess files could be shared among different notes all that would be necessary would be to install the ability to select a file in the filesystem

aat this time I expect to have files classified by image this and XML characteristics but I can foresee the need to have a place in the directory structure for hotspots, audio files, watermarks, copyrights, and other miscellaneous items may be referred to by the XML file. In my current conception I believe these files should be uploaded via FTP or a program such as files a lot and simply reference by files attached to a particular node. I will probably discuss the structure in detail with Zoomify support at a later date

Installation Requirements

the program installs like any module it's pretty simple but you've got to spell it correctly. Yes and by spell it correctly I mean the entries are case-sensitive. I believe that is a artifact of the Linux operating system. There seems to be some built-in expectations in the JavaScript as well. This is part of the difficulty I am having with paths at this time.

Library structures

The program is requires a Zuma five library. This library can be very simple. Create a file folder entry under library with the title “zoomify' and within this folder create another folder entitled “Assets” inside this folder create another folder entitled “Skins”. Copy this gens subdirectories from the assets folder supplied to you by the Zoomify company. Copie the JavaScript files for the different viewers as supplied the by Zoomify company into the main “zoomify” library folder. You need to be careful that the files folders are capitalized correctly because if they are not the program will not find them. If the program does not find them you will get nasty error messages from Drupal.

Usage

Once the module is installed it's advisable to configure it. Go to the configuration menu and you can set the size of the simplify window and determine other items such as whether to have a tab or not. These commands are not alterable at this time but I plan on making them fully configurable in the later version. You will see that you have the ability to select the amount of input validation that you wish to apply and to select one of the three skins as they say which are used to provide various customized toolbar looks. If you wish you can actually purchase premade fancy toolbar skins and these scans should be placed in the assets in subdirectory. The scans subdirectory should contain nothing but directories you will be given a chance to select one skin directory from that list.
The program as I have conceived it provides its own content type and no which I call a Ziff image. The node consists of a title 80 body field a JPEG image and a zip file and a XML field. None of these feels are mandatory. In order to see the Ziff field it is necessary at this time to configure the display for the content type. Normally I display a thumbnail version of the GIFs with a link to a color box image which is related to the size of the GIS. The zoo modified image is displayed only for full content displays. So it is necessary to set the display to display and Azumah five image in order to get module to create the viewer if you fail to set the display for the field and type of display you will find yourself looking at a generic file name instead of a zoomified image. I've done it many times

you can of course embellish the node if you want to add more files fields or anything else it's just like any other piece of content and you can change it to your hearts content. I presume you know how to do this.. And that is about it.

As I said this is my first attempt at writing a Drupal module. If you have any ideas hence or recommendations for better coder coding practices I will be most pleased to receive them. I really would rather spend my time photographing the countryside rather than pounding on this keyboard.

Actually I dictated this rather long winded diatribe with Dragon. My typing is poor and my vision is not too good either. So please excuse any typographic error I missed.