Itemviewer Image Conversion
From DLXS Documentation
Main Page > Mounting Collections: Class-specific Steps > Mounting a Text Class Collection > Newspaper Clip Image Access Mechanisms > Itemviewer Image Conversion
Contents |
<a name="GeneralInfo"></a>General Information
Itemview.pm is a DLXS Perl class module, found in $DLXSROOT/lib. It contains, among other things, the methods (handlers) that may invoke external image conversion programs. $DLXSROOT/cgi/t/text/PageView.pm and $DLXSROOT/cgi/t/text/ClipView.pm are both subclasses of it, and so therefore inherit those methods.
<a name="HandlerResolution" id="HandlerResolution"></a>Handler Resolution
After a Pageview or ClipView object is instantiated, it contains information about every page in the document, including how many and what kinds of image files are stored for each page. Based on the CGI's request for a particular output format in which to view a page image (whether to retrieve and display a PDF or a GIF or a JPG file) and the types of file formats available for that page, the application object can determine which conversion "helper" program to use.
<a name="Scenarios" id="Scenarios"></a>Scenarios
- General information about scenarios
- Scenario 1: "image" requested
- Scenario 2: "pdf" requested
General information about scenarios
In the running of pageviewer-idx and its running of PVApp/CVApp, a PageView/ClipView object is instantiated. By using the Pageview/ArticleClips table in the dlxs database, and querying by the document's idno and the page's sequence number, the object is loaded up with all the page information necessary for a particular document. Therefore, it reflects every page and which file formats are stored on disk for each page.
PVApp/CVApp, invoked by pagevewer-idx and through its parent object, ItemViewApp, would look at the "stored image format" and the "requested image format", and using a hash found in $DLXSROOT/lib/ItemView.cfg, would determine the proper method to invoke the conversion, which is in turn coded to use a particular helper app.
Scenario 1: "image" requested
Assume that the CGI requests "image". First, the application checks the %gStoredFilePriorityMap hash in ItemView.cfg. This hash says that if the CGI is requesting an "image" file, the first file format to look for, stored on disk, is "jp2". If there is a JP2 file on disk, it will be used, then the Jp2ToJpgHandler would be used, which in turn, would use the helper app kdu_expand_jpg which is a wrapper script we provide to run kdu_expand_jpg with the proper parameters.
If there is no JP2 file on disk, the next file format to look for is "sid"; that is, MrSid. If there is a MrSid file on disk, then the SidToJpgHandler would be used, which in turn, would use the helper app mr_sid_retrieve.
If there is no MrSid file on disk, the next file format to look for is "jpg". If there is a JPG file on disk, then the requested and stored file formats match. Whenever this is the case, DeliverFileHandler is used, which simply copies the file from its storage location ($DLXSROOT/obj/... to the cached image directory $DLXSROOT/web/cache/...).
Finally, if there is no JPG file available on disk, a TIF file is looked for. If there is a TIF file, available, then the TifTGifHandler is called which in turn uses tif2web.
Scenario 2: "pdf" requested
Assume that the CGI requests "pdf". First, the application checks the %gStoredFilePriorityMap hash in ItemView.cfg. This hash says that if the CGI is requesting a pdf file, the first file format to look for (on disk, known via the Pageview database table and therefore via the PageView or ItemView object), is PDF.
If there is a PDF file, then the requested format matches the stored image format and the DeliverFileHandler method is called, which simply copies the file from its storage location ($DLXSROOT/obj/... to the cached image directory $DLXSROOT/web/cache/...).
If there is no PDF file stored, then the %gStoredFilePriorityMap says to look for a TIF file. If there is one stored, then the Tif2PdfHandler is called which in turn uses c42pdf.
