Pocket Query Hints Problem

[+Marvin Gardens]

I am having problems with two PQs, one for Winthrop WA (zip 98862), and the second for Omak WA (98841). The area of these queries overlap and share many of the same caches. Both queries only output several pages of hints and then truncates the rest of the hints after the cache GC96E8.

 

I looked at the PQ with Mobipocket v4.9 on both my PocketPC PDA and on my laptop. On both systems, the hint for GC96E8 has several "A" characters with a carrot over them. I went to the GC96E8 cache description on the Geocaching web site and checked the "Ignore listing" box and regenerated the PQ with the "Are not on my ignore list" box checked. With this configuration, the PQ seemed to generate the hints correctly. It appears that there is a problem with the GC96E8 cache that is causing a problem with the PQ. I looked at the cache page and did not see any unusual characters.

 

If anybody has any ideals about this, please let me know.

 

Thanks

[robertlipe]

The good news is that the PQ engine itself is treating this one about as sensibly as it can. The problem, as you've deduced, looks to be that cache itself. It's a poster child for embedding malformed HTML.

 

The hint contains a doctype tag (which is almost surely the result of overzealous cut and pate from some HTML editor) and a number of characters in an unstated character encoding that will render as an "a character with a caret over them".

 

Ask the cache owner (or bribe your favorite reviewer) to remove the doctype from the hint, the stray html tag, the forced br, the closing body (that was never opened), the closing html (that wasnt opened) and the two occurrences of the weird characters.

 

Short description and long description have similar issues that should be addressed.

 

(Closing tags in a field that weren't opened in that field is the kind of thing that drives software batty. Those closing tags are liklely why your app croaked.)

[+Marvin Gardens]

Thanks for the informative reply. I will send an email to the cache owner to see if he can take a look at his listing code. The problem might not be with the PQ itself but it could be that Mobipocket might be running into a piece of code that it does not like. I need to look at the PQ with GSAK and see if I get the same results.

 

Thanks a lot.

[robertlipe]

You're welcome.

 

I meant to pound on that last sentence a little more. Most applications (and I can't speak for the Mobi generator) that try to do something intelligent with PQ's expect any HTML to be reasonly well formed. GPSBabel's own HTML code pretty aggressively throws things away and yet there are still 20 things on this one cache that make it through that cause 'tidy' to complain. I'm confident that I could find (or create) pages with naughty HTML that would make GSAK - or just about any other program - unhappy.

 

There are a number of conformance problems, but I won't analyze this specific cache to death unless asked to do so by the cache owner. My money is on the doctype, html, and body tags being the low-hanging fruit here as the cause of Mobi being grumpy.

[Jeremy]

Thanks robertlipe. I have no excuse for letting that stuff through, but we'll be adding htmltidy to new caches soon. This will clean out the majority of malformed html entries.

 

Doing this to old cache pages would be problematic though

[+Hemlock]

Ask the cache owner (or bribe your favorite reviewer) to remove ...

Cache descriptions and hint have been cleaned up. The only "funny characters" I saw were specified using html entities so I left them alone.

[+Marvin Gardens]

Thanks all for the quick response. I just removed the cache listing from my ignore list and reset the queries. I will let you know if I have any further problems.

 

Thanks again - Marvin

[robertlipe]

Thanks robertlipe. I have no excuse for letting that stuff through, but we'll be adding htmltidy to new caches soon. This will clean out the majority of malformed html entries.

Groovy. htmltidy rocks. It really should clean up a lot of issues in this area caused by "amateur hour" in HTMLsville and overzealous cut and paste from other apps - many of which generate broken HTML themselves.

 

And no excuse is needed. It's a hard problem to fix arbitrarily broken input. I've already confessed that in my own glass house, GPSBabel throws away _most_ of the decorations on this page but it, too, doesn't fix enough of it to result in really valid XHTML/HTML output. You're wise to farm this problem out to Tidy.

 

Doing this to old cache pages would be problematic though

I won't venture a guess on what percentage of the worlds cache pages will be irreparably damaged, but my experience with tidy shows it should be manageable. If a browser can do something basically readable for a page, tidy generally will too. Anything that it really dogmeatifies was already dogmeat and probably didn't work as intended _anyway_. For example, it improved the cache page in question here.

 

Any page that's so broken that Tidy can't make a good effort to fix probably doesn't work right in most browsers already. The kind of pages I've seen Tidy totally trash are the kind of pages that are so horribly broken that they don't work in _any_ browser, so I suspect you're OK retroactively "fixing" these.

[+as77]

we'll be adding htmltidy to new caches soon. This will clean out the majority of malformed html entries.

While you're at it, try it on the main page of the site, too. Or just any other page on the site for that matter.

[+as77]

btw do we need html in the hints at all?