SVG: Authoring Guidelines

The authoring guide posted at jwatt.org indicates that using the style attribute on a tag should not be done. No reason is given beyond the fact that SVG-Tiny doesn't support styling. I'll need to do some more research to determine if this is truly valid guidance. I don't think we'll be moving away from CSS since there is much common styling across the elements of the Atlas maps ... but it may mean we should investigate using classes or IDs.

SVG: Firefox text rendering

I was working on getting some consistency between IE and Firefox when viewing one of the Atlas SVG maps being developed and ran across an odd problem in Firefox 1.5.0.1. There appears to be some kind of hard limit on the minimum size that can be assigned to a font via CSS. I haven't done full testing so it's hard to describe the exact nature of the problem. However, as I was working on the map Firefox would not go smaller than 10px. To get around the problem I had to increase the size of the map (in Illustrator source) so that I could size the text appropriately.

IERI: JavaScript escape() function

To work around some problems I modified the utility at one point to ask for the location of a movie each time it's loaded. The main reason being the difficulty in writing any kind of JavaScript that works cross-browser/cross-platform that can determine the location of the movie automatically. To do this I used a standard HTML form with a file input. Upon submission I grab the value of the file input element and redirect to a page. In order to avoid URL problems I was using the escape() method to URL encode the filename.

Unfortunately, the escape() method does not encode the plus (+) character which, though rarely used, has been encountered in a filename. A little research led me to some new methods available as of JavaScript v1.5. I've modified the script to use the encodeURIComponent() method if available and the escape() method as a fallback.

References:

• Comparing escape(), encodeURI(), and encodeURIComponent()
  

IERI: Revision 3 Development

I've begun development of the next revision of the IERI utility. Currently I'm working on the basic shell of the utility and the login system. The process is going a bit slow as I'm spending quite a bit of time trying to think ahead about how the choices I make now regarding programming and file structure will affect things as I get further along in development. Plus I want to be sure to spend time documenting the code as I go as much as possible.

I'll try and keep notes of interesting and useful information on the blog while I work. Here's two to start.

1) I'm curious as to what the most appropriate HTTP status code would be for redirecting to a log in page. The closest status code would be the 401 but that only allows for HTTP authentication using the WWW-Authenticate header field. There doesn't appear to be a return status that would reflect the desire to authenticate via HTML forms, so for now I guess I'll stick with the standard 301.

2) I'm pretty new to PHP, but the language is easy enough to pick up considering the extensive work I've done in VBScript, JavaScript, and even perl. One interesting feature I've come across which should prove handy is that error messages normally output to the browser can be suppressed by appending '@' to the beginning of a line. The main use I have in mind is for including via PHP regular HTML that the page can live without (such as header and footer content). If I'm planning on using this, though, I should probably also investigate methods of checking for errors in case I run into an instance where a page doesn't work as expected but no errors are returned because they are suppressed (and I've forgotten that I had suppressed them). Hopefully I can create a global setting for the application in the common.php file.

References:

• HTTP/1.1: Status Code Definitions
  
• Error Control Operators (@php.net)
  
• Error Handling and Loggging Function (@php.net)