My Thoughts on Bell/Rogers purchasing the Toronto Maple Leafs

ACC seating will be changed from Platinum/Gold etc. to an even split of Blue / Red and in addition to a general price increase, seat prices will probably increase while at the game for no apparent reason. If you want to switch from the Blue to Red section you’ll have to pay a cancellation fee, and may be forced to sign up for season’s tickets. Arena blackouts will become common in unplug to reset scenarios, video feeds may fail or become unresponsive (especially in bad weather), frequently hardwood will be laid for Leafs games, and there will be more commercials stating the Leafs have more or even the most players in HD than any other NHL team!?@#! If you have to leave the game early they will charge you a $100 2^nd/ 3^rd period cancellation fee etc. Getting tickets will be really easy over the phone or online, however you’ll never be totally sure you got the right Leafs/Raptors/TFC/Marlies or Blue Jays tickets until the bill arrives in the mail. Rogers will bait and switch Leafs tickets for Blue Jays. The CRTC will start regulating Pheneauf hits and be a major contributor to banning fighting in hockey. The Leafs will frequently stop playing, or significantly slow down to the point where you wonder if they have crashed. It will become impossible for the Raptors to beat the shot clock and should someone “catch fire”, they will be throttled. If you drink beer at the game, you will have to pay a second fee, in addition to the $11 for the beer to compensate Bell/Rogers for subsidizing your subsequent buzz. Should it be determined you were drunk when leaving the arena you would have to pay an overage fee on said service. Moreover, if a game went into overtime, you would automatically be charged an additional 35% on ticket price again, as an overage fee. Should a shootout occur, you will be charged the maximum. If you call to complain about any of this, you will need to provide the 10 digit account number clearly written on the part of the ticket that is torn off and disposed of by ACC staff when entering the venue. Moreover should you have any further problems, you will be directed to contact Rogers, who will direct you to contact Bell, who will direct you to contact Rogers, who will direct you to contact Bell, who will... Meanwhile … in Leaf Land …

Hack Fix For typeface.js JavaScript Error " 'undefined' is null or not an object"

In IE the following JavaScript error is thrown in circumstances where there is no match for an individual character code in your font glyph map (you know that file you generated for your font):

Error " 'undefined' is null or not an object"

Line: 601 (uncompressed source code).

At time of posting I am using typeface-0.14.js.

The visual result of this error is the sudden disappearance of all headings after the heading which contains the erroneous character on your page. If you inspect your markup, you will notice your missing head tags ALL contain style="visible: hidden" yet have no VML content. This is a result of typeface hiding markup elements before ensuring it can successfully emit the resulting vml syntax & an error.

The Hack fix, which merely seeks to allow typeface to continue processing all "non-corrupt" words on the page (rather than an ugly fail & missing headings) is to modify typeface.js with the following:

1) In the _renderWord method, wrap all calls to: "this.renderGlyph" in a try catch statement.

2) If an Exception occurs return null.

You will find renderGlyph is invoked VIA the renderWord & recursively VIA the renderGlyph method(s). Fortunately for us, the method that calls renderWord (getRenderedText) performs a null check on the renderWord result. If the return from the renderWord method is null, the word will be "ignored" by the portion of the method responsible for creating the VML, and therefore will NOT cause a catastrophic failure in typeface enabling rendering of subsequent words & headings.

So that's the solution. It works. To be honest, I don't like this solution for a bunch of reasons:

1) I don't like try ... catch oriented programming. If there is an error, I want to be told of it so I can treat its root cause rather than at its symptoms. However, circumstances do arise which make it difficult to ensure issues are treated for root cause (EX// CMS Systems which do not impose such limitations on user generated content).

2) The primary reason: This is a 3rd party library for my app. Inevitably, at some point in the SDLC, someone smart is going to take over this project and say: "I can't believe they are using typeface-0.14.js, don't they know it's at version 3 right now". Other than the fact the file is named typeface-0.14-CUSTOM.js & loaded with customization comments, there is no indication to developers that this file has been customized (devs tend to look at code & runtime behavior vs ReadMe files & comments). And you know the rest of the story that starts with: I,E,6; Ends with: "hack fix"; and resounds in a high pitched user saying: "Everything was working fine until your last deployment".

3) A "JavaScript plugin" with such a pervasive behaviors, to a certain degree could be better programmed to isolate and tolerate faults. NO, this is not a contradiction to #1 above, but rather, represents an authors conscious decision to say: "Ok, with respect to what I'm trying to do, I CAN tolerate this fault, but I CANNOT tolerate that fault". In the case of this fix, I have made a conscious decision to say: "It's better if I just fail this one word than risk failing every subsequently unprocessed heading and word on the document".

4) 1#: I am in no way speaking down or pointing a finger at the typespace developers. I think everyone in the community owes them a stand up applause. Seriously. Amazing work & great contribution guys! I have contributed this fix. But in developing a site, and having to decide on how typography would be handled, and being in an " obviously IT" time crunch, I really don't have time for errors like this. More specifically, having written & proofed an opposable dynamic font solution to typeface, when I saw these errors, I immediately sought to rip typeface out of my application. This developer decision directly contradicts mass adoption of these technologies. Let's be honest, with the typeface source code, and a web browser, it's pretty easy to figure out this work around, but for the 90% of users that don't have the skill, it's a three point shot into the garbage bin. In not patching this gap, the door swings open (insert firm kick from behind) for developers to consider alternatives & for this to never truly mature. For example my train of thought: P - "undefined error in typeface (3rd party js lib??)" -- TOT - "another hack library not doing null checks" -- R - "ctrl+f5 on browser" -- NEXT - P "undefined error in typeface" -- TOT - "this is a third party library, is it even reasonable to try to crack the hood?" -- R - "build new matrix of reasons I'm using typeface and not my guaranteed image based solution" -- NEXT -- P "is typeface the right tool for this?" -- TOT "evaluate guaranteed solution vs. unexplored option" -- R "how much time required to fix" -- NEXT -- P "what is the quickest means to an end: risk debugging typeface VS. introducing jQuery convention" -- TOT "I can justify spending 10mins debugging typeface, after that, I'm pulling out and inserting my fontSprite". OUTCOME: typeface is a really well designed script that is easy to diagnose and repair problems in therefore 10 mins spent investing and repairing problem in typeface source was worth the effort. I conclude this is true ONLY because the resolution was simple. And this is my reservation: we use these scripts to gain a level footing on different platforms. When platform comparability issues are prevalent in X-Platform platforms, it's difficult to remain confident about that platform. Aren't the five lines of code required to implement this fix / ensure failure is logged (nice logging BTW) worth the end user inconvenience even if it is merely makeup? The vs. personality of the algorithm/argument is: "Nice headings dude, but, but, but, a word isn't printed because a) it contains illegal characters, b) etc. reasons. Sorry dude, I tried my best." vs. "Rookie Undefined Error dude. LOL - you seriously want me printing mo headings after that BS!". IE sucks, but the point of using typeface is to eliminate this issue. I don't think putting this fix on hold or on me is the way it should be. I get the point.

At EOD, typeface was used and the project was a success. However, it is unrealistic to expect shops to jump into 3rd party JavaScript libraries & build custom fixes. I fully understand the philosophy behind not fixing this problem however, I fail to see how not fixing this problem works in the best interest of typeface or the JS community.

Moreover, and to set the record straight for concerned readers: this problem is really uncommon. In any controlled environment it would be completely avoidable. This is a manifestation of how our lazy CMS (SharePoint 2010) emits character data with hexadecimal encoding (you know those invisible characters with "" values and character codes in the 80k range).

Typeface is there for you on the 99.9% side, my point merely talks to one specific circumstance in what is otherwise a really amazing product.

Over and Out.

Matt

Need Help Moving Boat June 11th - Cleveland to Welland

I need help moving my C&C 40 Centerboard from Cleveland to Welland.

Please leave your contact information in a comment (will be moderated so nobody will see except me).