Over-ride server Content-Type ??

[Gary Evans]

Is there a way to do this in V6?

e.g. (Open Source) Gallery creates webpages with the extension ".jpg.html" that contain individual .jpg images.

In spite of listing ".jpg.html" as a specific file type, (complete with an associated image, different from ".html" file type), in the Indexer, the Zoom Search results page displays the .html image for both ".html" and ".jpg.html" files.

[David]

We'll have a look at it, but it doesn't make sense to return .JPG files with a .HTML extension? It is a silly thing to do and just asking for confusion in my opinion.

[Gary Evans]

Perhaps I described the issue poorly. Agree there is little point in arguing with the Content-Type returned by the server.

The issue is that the Indexer / script does not correctly interpret my definition ".jpg.html" as a distinct filetype extension, (with a distinct associated image - regardless of the Content-Type actually being either jpg or html).

All my files with extension ".jpg.html" are indexed as ".html", (and displayed with the (incorrect) html image - not the one I defined for ".jpg.html"

The script should be able to handle ANY string of allowable characters entered to as a distinct file extension, (not just go back from the end of the string to the first ".")

'Compound' file extensions are not all that uncommon.

[Ray]

Right, we get what you mean now. While we agree such a scenario exist, it is debatable as to how they should be treated. On Windows platforms (and remember Zoom does support indexing offline from the Windows filesystem), a ".jpg.html" file would be treated as if it was a ".html" file and the ".jpg" part would be considered part of the filename.

I don't think we can easily change the behaviour of this without making an assumption that might break other users expectations (e.g. someone else could be depending on it identifying "mypage.bak.html" as a ".html" file and not a ".bak.html" file).

But if we get more people asking for this, we would look into it.

In the meantime, perhaps you could look at adding ZOOMIMAGE meta tags on the relevant pages by modding the Gallery script?

[Gary Evans]

Understand the off-line complication. Unfortunately, my Gallery is built and filled, so adding ZOOMIMAGE tags is not an option.

Would it be worth investigating a method to allow users to associate images only with (user)-defined file types, (i.e. ignore the actual Content-type) ?

For example, pdf can wrap any type of file content, but it would be useful, (to me, anyway), to indicate to a user, (by means of an associated graphic), whether the pdf contains; image, text, or tabular, (spreadsheet) info, or even other characteristics, like whether it's a single or mult-page document.

TIA

[Ray]

Understand the off-line complication. Unfortunately, my Gallery is built and filled, so adding ZOOMIMAGE tags is not an option.

My impression of Gallery was that it was a PHP based script, and all pages are dynamically generated. So I didn't think it would matter if the image gallery was already built. It would just mean changing the script that displays the image pages in question, to check the filename (or any other available parameter) to print a ZOOMIMAGE meta tag as required. But this would require experience with PHP scripting.

If Gallery actually pre-generates static HTML pages, then, yes, this would indeed require re-building. But that would seem to be a very inefficient image gallery management system, as you would need to rebuilld every time you add something across all the pages (e.g. a menu item).

Would it be worth investigating a method to allow users to associate images only with (user)-defined file types, (i.e. ignore the actual Content-type) ?

For example, pdf can wrap any type of file content, but it would be useful, (to me, anyway), to indicate to a user, (by means of an associated graphic), whether the pdf contains; image, text, or tabular, (spreadsheet) info, or even other characteristics, like whether it's a single or mult-page document.

Not sure what you mean by "user defined file types" and how this would be defined. I can only presume this would be specified by file extension, in which case, it seems to be the same feature/request as what we were previously discussing? How would Zoom determine a PDF contains any of the aforementioned types of data you just mentioned?

Ultimately, the ZOOMIMAGE meta tag was designed to allow you to associate any image with any particular file. With a CMS (content management system) or most dynamically generated website, this can be a scripted relationship determined by any criteria of your choosing. In the case of PDF files, you can use .DESC files to specify the meta tag needed.

[Gary Evans]

Thanks for sticking with this thread. Zoom Search is definitely a top-drawer product 'as-is'.

Gallery is indeed PHP, using a MySQL database, (and quite bloated with features - including its own Search function, complete with per-image keywords). Its already complete, though I have not ventured farther than a couple of minor configuration customizations. I believe pages are actually static, (since Zoom Search actually Indexes them), but perhaps I'll dig deeper and see if there might be a way to automate the addition of ZOOMIMAGE meta tags.

[Ray]

Zoom can index dynamic (non-static) pages in Spider Mode. It makes a request to your web server, your web server will then execute the script, and generate the HTML response, and send that back to the client (Zoom), which will index the resulting page. So they are not necessarily static pages because Zoom indexes them. Best of luck with the investigating.