I have this little piece of KML code which shows an image when clicked on the placemark, all images i have are store locally, and it works fine when using the .kml file it self.
Once the file is compressed into .kmz i'll get a warning (yellow marked) on the first line of the CDATA, covering some of my text.
It says: "This balloon may be using incorrectly formatted image URL"
All of my images works fine, they are not missing, and the relative URL is correct, but the syntax is not.
Anyone out there know of a solution to get rid of that hardcoded message ? or even better how to "tune" the code, so this warnings don't show :)
I've seen a couple of examples, stating it should help, but none suits my need, unfortunally.
This was some of the solutions i've looked at, but still not got it working.
Option 1: Fix the URLs
Your base URL is one directory down from where you thought it was, so you can simply add “../” to the beginning of each offending relative URL. This works fine in earlier versions of Google Earth as well, because older versions will look in both directories (and as a bonus, your content will render faster in older versions).
To fix the above example, we’d change:
<img src="images/image.png”>
to
<img src="../images/image.png">
Option 2: Add a <base> tag
As with any other browser, you can add a <base> tag to your HTML to set the base URL of that content. The href parameter of the <base> tag must be an absolute URL, so you’ll have to hard-code your server name and path. Adding the <base> tag to your BalloonStyle can fix all of your URLs in one go.
To fix the above example, we’d add: <base href="http://host.example.com/kmz/somelayer/"> to the BalloonStyle (or description, if we only have a few affected placemarks).
Option 3: Move the files
If you can’t change the balloon content, you can still correct it by moving the resources it points to into the correct locations. Depending on the URL, there are a couple of ways to do this. In our example, you’d move or copy the “images” folder and its contents to the KMZ archive. If the offending URL was “../files/another_image.png” (which should have been “../../files/another_image.png”), you could move or copy the files folder into the somelayer folder to fix the problem.
In many cases, though, there will be many layers all referencing the files folder, so moving the files folder into each layer folder can get tedious. If you have access to the web server configuration, you can solve this by adding an HTTP redirect from each incorrect location that redirects up a directory. You could also move the KMZ file up a directory, but this will change the URL that people must use to access your KMZ file.
I wanted to look at your KML to see if it was properly formatted and test it on my end.
Related
I'm trying to move from Classic to Super dev mode and seeing a problem in the latter. The problem is two-fold. First, it is trying to use the code server to give the css files to the web page. Here is a line from the element in the resultant web page:
<link rel="stylesheet" href="http://127.0.0.1:9876/tdome/../resources/standard.css">
You can see that it is piping the reference through the code server, which is running on port 9876. Now, that wouldn't be a big deal if it would serve the file. But it won't. The styles in that file are missing in the resultant page. This URL straight to the code server:
http://127.0.0.1:9876/resources/standard.css
... gives "server error". Eclipse is tossing a null pointer exception. It seems to have heartburn with files that are not in the /tdome tree. Just snuffling around and pecking in the names of existing files, sometimes Eclipse says it is ignoring the request. Sometimes it says the file doesn't exist when it does, and sometimes (when it really matters, like here), it gives the nullPointerException. At WebServer.java:272, fwiw.
So I need to either get superdevmode to leave these references alone, or get it to serve the file.
Any ideas? Many thanks-
Well, I really didn't find a way to make Super Dev Mode serve the files where they are. But I figured out where they should be instead of where they are. Probably common knowledge to everybody else: make a 'public' directory next to the 'your-project.gwt.xml' file and put them there. The references to them are in that xml file and do not need any qualification- just the filename, no directory path. Super Dev Mode will package them up, serve them, and let you at them.
I'm using the Node.js version of TiddlyWiki, and I'd like to link to images on my filesystem.
The documentation listed here doesn't work; in the [img[path]] tag, for the path part I put something like /Users/documents/ken/path_to_image.jpg yet nothing shows up in the tiddler.
My wiki exists in /Users/documents/ken/wiki.
I know this is an old post, but zacts stated that you can use a macro plugin or simply use the [img] tag to point to the relative path of the image from the tiddlywiki.html file, but the op is using the node.js version, and zacts apparently didn't read that. There is no tiddlywiki.html file for TiddlyWiki on node.js. That only works with the static .html version of tiddlywiki, not the node.js version.
Currently there is no way to point to a local file through the node.js version of Tiddlywiki as node.js is not a webserver, therefore it does not see subfolders like /images/ off of the root url. The only way is to run a parallel web server on the same machine and use the full web url to the images served up from the web server.
In case someone else stumbles across this problem:
I could not find this documented anywhere, but what seems to work is to just copy the image in the tiddlers directory, then restart the nodejs server, and search for the image title from tiddlywiki. There will be a tiddler that contains that image, that you can edit at your leisure.
Alternatively, copy the image as image_name.png (or image_name.jpg) into the tiddlers directory, and create a image_name.png.meta text file with the following contents:
title: image_name
type: image/jpeg
Upon restart of the tiddlywiki nodejs server, a tiddler with title image_name which contains the image will be there.
If you are using the Node.js version, you can simply put it in the ./files folder, and then use [img[. /files/xxx.jpg]] to reference it.
I had this same issue recently, and I found a neat little solution for it. Let me send you the links, and I'll post the snippets here.
I happened to stumble across this tiddlywiki image gallery homepage that linked to a macro plugin that lets you link in local images. Here is the link to the tiddler for the plugin: http://www.richshumaker.com/tw5/tw-photo.html#External%20Image%20Path. Here is the original TiddlyWiki google groups post of the plugin for this: https://groups.google.com/forum/#!msg/tiddlywiki/ChRV6sjQpn4/bCm35_XhGmkJ.
I hope this helps! =) (note: when I get more time I may clean up the formatting of this post).
It is very simple, you use _canonical_uri field
_canonical_uri field
The field value is something like "./wiki/path_to_image.jpg" (mine is "./files") in the same level as the tiddlers folder. I did not experimented with files outside the root folder of the wiki. The dot in the path might be ommited.
The content type might be "audio/mp3" "image/jpg" look at the "parser" shadow tiddlers. Your Browser might support more content types like "audio/wav" but you would have to add this line to "$:/core/modules/parsers/audioparser.js" For example. Might be the same thing for images. Check your browser support.
I really do not know why this fact is so obscure, but it work wonders.
So I'm new to XUL.
As a language it seems easy enough and I'm already pretty handy at javascript, but the thing I can't wrap my mind around is the way you access resources from manifest files or from xul files. So I did the 'Getting started with XULRunner' tutorial... https://developer.mozilla.org/en/getting_started_with_xulrunner
and I'm more confused than ever... so I'm hoping someone can set me straight.
Here is why... (you may want to open the tutorial for this).
The manifest file, the prefs.js and the xul file all refer to a package called 'myapp', that if everything I've read thus far on MDN can be trusted means that inside the chrome directory there must be either a jar file or directory called myapp, but there is neither. The root directory of the whole app is called myapp, but I called mine something completely different and it still worked.
When I placed the content folder, inside another folder called 'foo', and changed all references to 'myapp' to 'foo', thus I thought creating a 'foo' package, a popup informed me that it couldn't find 'chrome://foo/content/main.xul', though that's exactly where it was.
Also in the xul file it links to a stylesheet inside 'chrome://global/skin/' which doesn't exist. Yet something is overriding any inline styling I try to do to the button. And when I create a css file and point the url to it, the program doesn't even run.
Can someone please explain what strange magic is going on here... I'm very confused.
When you register a content folder in a chrome.manifest you must use the following format:
content packagename uri/to/files/ [flags]
The uri/to/files/ may be absolute or relative to the location of the manifest. That is, it doesn't matter what the name of the containing folder is relative to your package name; the point is to tell chrome how to resolve URIs of the following form:
chrome://packagename/content/...
The packagename simply creates a mapping to the location of the files on disk (wherever that may be).
The chrome protocol defines a logical package structure, it simply maps one URL to another. The structure on disk might be entirely different and the files might not even be located on disk. When the protocol handler encounters an address like chrome://foo/content/main.xul it checks: "Do we have a manifest entry somewhere that defines the content mapping for package foo?" And if it then finds content foobar file:///something/ - it doesn't care whether that URL refers to a file, it simply resolves main.xul relatively to file:///something/ which results in file:///something/main.xul. So file:///something/browser.xul will be the URL from which the data will be read in the end - but you could also map a chrome package to another chrome URL, a jar URL or something else (theoretically you could even use http but that is forbidden for security reasons).
If you look into the Firefox/XULRunner directory you will see another chrome.manifest there (in Firefox 4/5 it is located inside omni.jar file). That's where the mappings for global package are defined for example.
I moved a set of templates to a new folder also named Templates so the instructional designer can see them in her "New page from Template" window. For some reason, I as the programmer can see the list if I try to make a new page from template, but the ID couldn't. While moving them allowed her to see them, it broke all the relative links to the js script src files. And when she tries to save the template page, it tells her to try and copy files and the absolute links don't get reset to their relative paths.
Is there a way to reset the relative links to those .dwt files? When I open the .dwt files, the relative links look correct; but when the ID makes a new page and then chooses a template to use, the links break at that point.
What do I need to do make the templates retain the relative links again?
Thanks in advance!
Carlos
When I moved the templates, it wasn't just in a new folder, but on a new level in the folder structure, so the old script src address "../../scripts/nav.js" wouldn't work because in its new location, it overshot the folder by one level and hence couldn't find the js file in question. Readjusting the relative links to compensate for its new location and structure level fixed this issue.
Carlos
I used http://site-perf.com/ to test the speed of my site (http://sweatingthebigstuff.com) and it shows one file that gives a 404 error. That file does not exist (hence the error), but how do I found out how to fix it? I don't know where it is being called (definitely not in the code).
The file in question is:
sweatingthebigstuff.com/wp-content/themes/WillTech_5_3_2010/lib/images/icon-rss.gif
I assume that I used to have a file but since deleted it. It was in a widget and it is now pointing to a png file.
Any ideas?
It was in a widget and it is now pointing to a png file.
There is a reference to it somewhere - in a forgotten HTML file, in a style sheet.... The easiest might be doing a full-text search for your whole (local) Wordpress directory for icon-rss.gif.
If that doesn't turn up anything - it should, though! - try using a downloader like GetLeft to fetch a full HTML copy of your site, and do a full text search on that. That should at least show you which page the offending line is on.