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)
  

SVG: Compatibility between Adobe and Firefox

I did some compatibility testing for the SMS project. Follows are notes related to that testing.

---

svgDocument does not appear to be part of the W3C spec (from what I can tell). It is the equivalent of the document object, which I would recommend using from now on. Existing code can be made compatible with Firefox by adding the following line of code:

if (typeof(svgDocument) != "object") { svgDocument = document; }

Trying to declare var svgDocument will return an error in AdobeSVG because svgDocument appears to be a defined constant in AdobeSVG. Luckily JavaScript is flexible enough to still recognize this as a global variable.

---

While Firefox supports the getBBox() method, using it onload does not work as expected. The release notes for v1.5 indicate this is a problem with the current implementation of the load event. I was able to work around the problem by declaring the global variables that rely on getBBox() but not setting their values. The values are set in a function that's called through a setTimeout().

This setup requires that the init() function be removed from the SVG document's load event and called after the global variables have all been populated. As a fix it's not particularly elegant ... but it seems to work. I'm not entirely sure it's worth incorporating this one; I would this issue will be fixed in a later release.

See:

• http://jibbering.com/2005/9/getBBox.svg
• http://developer.mozilla.org/en/docs/SVG_in_Firefox_1.5#Events
  

---

I believe that Firefox rewrites documents internally when rendering. Apparently the transform attribute is rewritten such that translate(0,0) is rewritten as translate(0). A way to work around this problem would be to write the function using regular expressions to parse the transform attribute. To get around this problem temporarily I rewrote the translate as (1,1).

---

I think the contextMenu object may be proprietary to AdobeSVG. At the very least Firefox does not recognize it. Errors can be avoided by using the following to determine if contextMenu exists prior to performing options on it:

if (typeof(contextMenu) != "undefined") { ... }

---

Firefox 1.5 does not support the selectSubString() method.

---

Despite many examples that have only two parameters in the setProperty() function it requires three. The third parameter can be null or an empty string ... but it has to be there. To fix just add a third parameter ("") to each instance of setProperty().

See:

• http://developer.mozilla.org/en/docs/SVG:Scripting#setProperty_has_three_parameters
• http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration-setProperty
  
• http://www.quirksmode.org/dom/w3c_css.html
  

---

Firefox diverges from the SVG spec with regards to the font-size style declaration. The spec indicates that a unit identifier (px, pt, etc.) is not necessary. However, Firefox chokes on a font-size declaration that does not have a unit identifier. The fix is easy enough ... provide an identifier for font sizes.

Mass Mailing: 2061 Connections - January/February 2006

The January/February 2006 issue of 2061 Connections went out on 23 Feb 2006 at 4:29:54 PM to 3818 recipients.

Mass Mailing: Workshops

The workshop notification went out on 13 Feb 2006 at 3:51 PM to 2457 recipients.