PDF links crashing in IE9

[skynyrd]

I have all up and running with the Zoom Engine, custom search website etc. and all is working well, apart one thing.
For some reason some of the links in IE9 for PDF files are not working where all works fine in Firefox etc. no single link is broken.
I do require IE9 to work as this is our default browser in my work for which I`m building the website and search engine.
When I`m changing the file name to some short simple one that works but I know that I will be unable to change every file on some 500 000 files when indexing.

Picture below with the response from IE9.

Anyone having idea ?

[Ray]

It seems like your base URL is a bit unusual so it's created a search result link that is only compatible wiht Firefox and not IE9.

Perhaps you can clarify if you are using Offline mode or Spider mode, and what your Start Folder and Base URL settings are.

The search result links are also relevant -- and they're hidden from view since you disabled the URL under "Configure"->"Results Layout"->"URL".

But you can also see what they are by right clicking on each search result and selecting "Copy shortcut" or "Copy URL" and you can paste the link to Notepad and see what it actually is pointing to.

[skynyrd]

Hi Ray,

Thank you for your help.
This is an offline javascript search engine. At the moment for some reason from 200 PDF files scanned only a few experienced that problem.
Links on the picture above are for test purpose only (local filders on desktop), we are planning to implement search engine on our Intranet site at work with indexed folders over the network. For now I`m working on the website and testing Zoom Search Software at home.
I created a few folders with PDF docs and indexed them to familiarise myself with the software. I created the custom search page and all works fine apart these few broken links and only in IE9.


I will try again when I get home.

Thank you

Thomas

[skynyrd]

Ray,

Website is a local intranet site without the web server, unfortunatelly due to the security reasons our IT dept. don`t allow us to use web serwer for this site, so all the links are relative links where the indexed PDF files are stored in the shared network drives. At the moment I`m simulating this at home for testing purposes with the plan to implement that solution in our website at work.

I`m indexing three categories MBMS, MBFD and MBDS PDF files stored inside the SPEC folder. Categories works great all data in search results works fine to, aparat these few broken links.
So SPEC folder is on my desktop and Website with Zoom Sarch generated files is also on my desktop in separate folder. But the best thing happens when I copied broken link from one of the files in search results and pasted in to the new TAB in IE9 and all works fine !

Now I`m confused completely I`m sure there have to be some simple solution.

Below is the copied link:

file:///C:/Users/twzorek/Desktop/SPECS/Material%20Specifications/MBMS016%20-Tubing%20Steel%20Corrosion%20Resistant%20%28Cres%2 0321%29%203.5%20OD.pdf#search=%22mbms%22



And the link below Is the copy of the above one converted by the IE9 when I pasted in the new TAB and it works without any problems.

C:\Users\twzorek\Desktop\SPECS\Material Specifications\MBMS016 -Tubing Steel Corrosion Resistant (Cres 321) 3.5 OD.pdf



Below is one picture with the URL option added. Not sure whether this will help you.



Thank you,

Thomas

[skynyrd]

Hi Ray,

I`m sorry for messing around but I just find out what was the problem.

I believe that brackets are confusing Zoom or IE9, ASCII Encoding "%28 and %29" markup indicates "()" and all files with broken links in my website contains brackets, so removing them from the file title solved my problems. However I`m not sure how many files like this are in our folders at work which possibly could create trouble for me in the future.

I tried changing the options in Zoom Search Engine in Language tab --> Encoding and character set from Windows 1252 to UTF-8 but this did not resolve the problem.

If you will find some better solution then removing brackets from files names please let me know.


Thank you again for help, highly appreciated.

Thomas

[skynyrd]

Hi Ray,

And it looks like I get back to the beginning. IE9 is failing to open any PDF file with COMMA (,) in the title.

Don`t know what to do, we have more than 500.000 files to index, and many of them are having brackets or commas in the titles.

I tried to replace %2C in zoom_pageinfo.js with actual comma (,) and this solved the problem in IE9 but this is not the solution for me right now in case where I have to index so many files.

In the link below I replaced %2C (,) with proper comma and it works fine.

file:///C:/Users/twzorek/Desktop/SPECS/MBFD%20Specifications/MBFD66%20Issue%203%20-%20Webbing,%20Polyester,%2025mm,%208900%20N.pdf#se arch=%22mbfd66%22

I think this is closely related to this article.

http://www.wrensoft.com/forum/showth...ive-file-paths

I tried also other software to see how links are generated, I used Search Engine Composer from mtoptsoft, all links working. Below is the link from both programs. Please take a notice that the link generated by Search Engine Composer is having a proper (,) commas.


Search Engine composer - file:///C:/Users/twzorek/Desktop/SPECS/MBFD%20Specifications/MBFD66%20Issue%203%20-%20Webbing,%20Polyester,%2025mm,%208900%20N.pdf

Zoom Search Engine - file:///C:/Users/twzorek/Desktop/SPECS/MBFD%20Specifications/MBFD66%20Issue%203%20-%20Webbing%2C%20Polyester%2C%2025mm%2C%208900%20N. pdf#search=%22mbfd66%22

I really like and prefer Zoom Search Engine but I will be unable to use it with these issues.

Thank you,

Thomas

[Ray]

Thanks for the details.

I can confirm I was able to reproduce the problems in IE11.

Note however, that the problem only occurs with this combination:
1) Using offline file:// URLs, and
2) Using IE (11 in this case), and
3) PDF files, and
4) Having "Highlight and locate matched words within PDF document viewer" selected (under "Configure"->"Scan options"->".pdf"->"Configure"

Long story short, this is really an IE problem.

IE11 does not have this problem with http:// URLs. All of the above percent encoded characters (parentheses, commas) are handled just fine by IE otherwise. And this is expected and required elsewhere by other browsers and web software.

But when it's a local file, IE has a different bit of code doing the decoding which has left parentheses and commas out of this process.

This appears to be triggered by the fact that the "Highlight and locate ... within PDF" feature adds the parameters "#search=mysearchword" at the end of the URL.

When this appears in the file:// URL, it appears to be when IE switches over to a different URL decoding method which leaves off decoding parentheses and commas.

Quick short term solution: Disable the "Highlight and locate ... within PDF document viewer" feature. Do this from "Configure"->"Scan options", config ".pdf" file and uncheck said option.

I've tested this here with IE11 and the problem is eliminated, and IE is once again able to handle the correctly escaped URLs with parentheses and commas encoded correctly according to standards.

Long term: we'll revisit whether we should keep these characters in our escape list and consider what makes sense more: to comply to the standards or support some idiosyncrasies of IE. Or have an option to do the latter.

[skynyrd]

Hi Ray,

Thank you once again for help.

I will try to follow your sugestion tonight but I admit, higlighting the searched words in PDF doc. was the most desirable option for me. This program will be used to scan 500.000 technical drawings and the main purpose of this search engine was to allow people keyword searching and highlighting their search results in the PDF files after opening them. Maybe I have to wait for our IT dept. to bring the updates for IE.

One solution I`m using is to edit zoom_pageinfo.js file using Dreamweaver advanced search option and replace function : find "%2C" and replace with (,) comma and so on. It works amazingly fast and links are working after that correction, the only problem is this have to be done after every indexing.


Thank you Ray

Thomas

[Ray]

We've decided to remove the parentheses and commas from our escape list to bring it in line with our previous behaviour (in V6). This will be in the next build (V7 build 1016).

Hopefully we won't have to cross that bridge when somebody comes back to us and shows us a different scenario where those characters have to be escaped for it to work in their situation.

[skynyrd]

Hi Ray,

I don`t want to be responsible for that change . I just notice that in my case there are other special characters apart commas and brackets. Not sure whether this will help you but I listed below the once I had to replace with the original characters in order to make the links working.

%28 - ( - Left Bracket
%29 - ) - Right Bracket
%27 - ' - Apostrophe
' - ' - Apostrophe
%2C - , - Comma
%26 - & - Ampersand


Thank you for your help and quick reply.

Thomas

[Ray]

Perhaps we'll make it an option to switch to "Microsoft" behaviour. V6 and earlier used the Windows API function UrlEscape() which is documented here.

This is likely also used by IE for certain situations (but apparently not all). Unfortunately this function had a whole bunch of other problems (such as not encoding in UTF-8 for non-latin characters as required by many other situations). So we've since replaced it with an in-house solution but naturally, following standards doesn't necessarily ensure widest compatibility "in the wild" (so to speak).

So not escaping a bunch of characters would help if your target audience (or particular situation) happens to be for IE. We'll give it some more thought, but at the end of the day, should have a solution that will work for your case.

[skynyrd]

Hi Ray,

Great news and thank you for help.

Thomas