Update:
I was asked “Why not apt?” As it turns out, the repositories still have Flash 7 listed in them. Nevertheless, this article may be a better/different way to install Flash 9, especially as it looks like it would include automatic updating, and it uses a more standard way of updating (which generally should be via apt; the tricky issue as always is when one wants something not in the repositories).

So earlier this month I installed Flash 9 for Linux on my Firefox from a HowtoForge article. Flash is one of those necessary evils*, I suppose, but it gets more difficult to ignore entirely so while I refuse to use it myself, I do install it so I can see what the heck is going on in some of the sites I visit. Not to mention that YouTube and VideoEgg both use Flash (the latter version 9 in particular).

To install it, I went to the Adobe download site. It automatically detects the incoming OS, so this step needs to be done from the Linux OS. This brings up a tar.gz file which I downloaded and saved. Using a terminal window, I unpacked it via

tar xvfz install_flash_player_9_linux.tar.gz

That gave me a new directory, which I cd’d to. I ran the installer:

sudo ./flashplayer-installer

After getting the root password, there’s some information and verbiage, until eventually it asks:

Please enter the installation path of the Mozilla, SeaMonkey, or Firefox browser...

At this point, I entered /usr/lib/firefox — more on that in a moment. After doing this, it chugged along for a few more seconds before informing me it was done. So now I fired up a Firefox window and all looked well. This was back in the first week of February.

Then about a week ago, I started noticing little oddities. Some of the places I was visiting started using something called VideoEgg, which simply would not run — it just spun in place forever as if it was downloading. I got very hit and miss behaviors, so I checked my plugins on Firefox via about:plugins. Lo and behold, it said I had version 7! Scratching my head, I went through the same process as above, checked again, and it showed 9. This kind of thing made me grumpy, especially when I spotted the same problem next time I started up Firefox. This time I kept searching on “Shockwave” in the about:plugins page and voila! I found I had both versions installed; and the behavior depended on which came up first.

I knew, from that plugin page, the relevant file name is libflashplayer.so. So I used a terminal window and looked for it using

locate libflashplayer.so

and what I found was a copy in /usr/lib/firefox/plugins as well as in ~/.mozilla/plugins. So I renamed the one in .mozilla (as having the older date) to another name, shut Firefox down, and started it up again. This time only one version of Flash (yay!) and at version 9 (yay!). It turns out that Firefox pretty much looks at four places: the global Mozilla and Firefox directories, and the local (home account) Mozilla and Firefox directories. It will find plugins in all of them (and probably a few more for all I know) so using any of these directories in the initial flashplayer-installer script will “work” but if it isn’t the same directory that the previous flash installation resides in, that double plugin situation will occur.

So, what I would recommend before installing Flash 9 is to first see where any older flash plugins are residing (via the locate command above) and either use that as the directory to give to the original flashplayer-installer script, or clean up afterwards, as I did.

And have I got a test site for Flash..

---

*Look at the date on that Flash article!. There are numerous other reasons to hate it as well, but the mockery it makes of accessibility issues, particularly for the visually impaired, is the number one for me.

Seems everything’s updating all at once –

Internet Explorer 7 for XP

Updated to this at work, no problems. Seems to be running just fine. I’ve snagged the standalone version for 6.0 so that I should be able to continue with testing/development on both. Sigh. Not quite at the point of setting up multiboot between XP and Vista, but we’ll see.

Firefox 2.0

Update on my Windows machine, no problems. Looks VERY nice. I appreciate the tabbing features except for the fall-off scrolling at both ends. I was prepared to hate the close tabs, but they only show up once the tab is active, which means I don’t hit them by accident the way I used to when I tried an older extension. I love the integration with the various feed readers, I was able to remove the Bloglines button and with the MiniMenu extension save some serious real estate on the top. Will be nice to upgrade to 2.0 on my laptop, where the real estate would really be handy.

Ubuntu 6.10

I had no trouble with upgrading from Hoary to Dapper, but a friend did. So this time ’round I’m sitting out the upgrade for a little while. And it sounds like Edgy has some rough spots, so I’m in no hurry. A fresh install may work better than an update over Dapper, but I’ll monitor it for a while longer.

Wordpress 2.0.5

Important security upgrade, you should do it — here and also here. It only takes a few seconds to upgrade if you use Mark’s diff zip file, which I did. Even with the potential bug (which he has a fix for), I would go ahead and update. Keep an eye on Mark’s blog for more info on 2.0.5.

Unicode — Supplementary Planes

Back to Unicode. Even Unicode needs room to expand. The Basic Multilingual Plane (BMP, also known as Plane 0) has codepoints 0 through FFFF hex (0 through 65,535) and contains, ignoring various special mathematical characters, historical quirks, and just plain oddities, most of the current alphabets and symbols in use today, even including the vast array of Chinese kanji. But of course there’s more room needed once historical alphabets and other special character sets are also considered. Supplementary planes such as Plane 1 are simply sets of 65,535 code points following Plane 0 (some of us refer to these as astral planes ). Using hexadecimal notation, it’s easy to spot Plane 1: all Plane 0 codepoints use four hexadecimal digits; all Plane 1 use five, etc.

Here is an example of a Plane 1 character: 𝔊 which renders as 𝔊 (marks a septaugint reference). In case anyone viewing this is having trouble, here’s an image:

To set things up to view this can be an interesting process. First of all it’s necessary to find a unicode font that supports plane 1 characters. Not all such will actually show the above, for example Code2001, an otherwise excellent unicode font, does not include historical Greek musical notation however Cardo works nicely. Just because a font is unicode based does not mean it will be “complete” (such a font would be staggeringly large). In particular, when choosing among unicode fonts, pay attention to which version of unicode is being supported, and what the target languages are. Plane 1 characters start to appear in Unicode versions 3.2 and up.

Second, the operating system might need slight adjusting to see Plane 1. I’m talking, of course, about Windows, XP and earlier versions. This page discusses how to do the registry edits necessary both for the operating system and for IE6 .

Linux/*nix, Mac, and Vista are all presently able to handle Plane 1 without modifications. My understanding is that for Windows Me and anything prior to NT, it’s hopeless.

Third, applications in general and browsers in particular may need slight tweaking to see Plane 1 characters. As usual, IE6 is the worst offender in this regard requiring not just setup but also a registry edit. In general, once the browser is set up with a Plane 1 aware font, it’s good to go. Firefox, Safari, Opera, and Konqueror all fall under this category.

A few notes: IE6 needs to be set to user-defined encoding plus the extended font needs to be listed under User Defined (rather than any of the specific regions listed, which refer back to non-unicode encodings as discussed in part 1). Opera actually reverses from the general MO of other browsers: under Tools->Preferences->Advanced->International Fonts, it’s possible to set a particular unicode font to a particular language (going by Unicode’s code blocks). This is the direction other browsers should no doubt take in the future.

Since javascript is a client side implementation (meaning that it is the browser and not the host site (such as is the case with php/perl/other cgi scripting) that actually runs the script) this means I can have endless fun finding out the many ways in which javascript gets completely hosed up.

I mean, take a pretty simple bit of javascripting:
document.getElementById('cleanslate').innerHTML = s;
where s is a nice little list of selectable (checkbox) items in a list to be output.

And then of course, in the html we have:
<span id = "cleanslate"></span>

How much simpler does it get?

Well. It worked beautifully in Firefox.
Didn’t do a single thing in IE6.

And it’s hard to figure out where to even start. In no amount of googling have I found a book, or a faq, or any kind of documentation that extensively details the ways in which Javascript differs from browser to browser. I would think this would be a huge niche. I certainly found many many questions on this stuff. Even if the differences are under constant change, I would still expect at least some online resources to be out there. (Anyone know of any?)

I did find another site that demonstrated a very similar problem: Chameleon but which offered no solution, only the illustration.

After much experimenting, I finally figured out that the issue was really this:

<p>
<span id = "cleanslate"></span>

There is something about the unclosed <p> that IE6 does not like. This actually kind of makes sense — since it’s not closed (yes, I know, slap my hands already), the question is what is the actual DOM? Firefox obviously defaults to something reasonable to handle it, IE6 takes the novel approach of displaying nothing at all. Well the “Sun Java Console” (now there’s a misnomer if there ever was) does come up with the every helpful:
"Unknown run time error on line..."

As an aside: I just gotta love this “Sun Java Console” for its utter uselessness. It’s not even possible to copy and paste the message somewhere for future reference. I can’t make use of IE6 until I close the window. It offers no means of running anything, debugging, tracing, etc. There’s an extension available at Microsoft but even after I jumped through the WGA hoops to download it, when I ran it to install it, it said “No Installation Data available.” It’s particularly annoying after using so many lovely Firefox extensions that enable extensive Javascript debugging.

But here’s the odd part. Removing the <p> altogether fixed IE6. Finishing it off before the opening <span> worked, as well. But enclosing the span within the paragraph did not work. Throughout all these variations, Firefox worked throughout.

Opera, unfortunately, is an entirely different story…! It looks fine, on the first pass. But it’s clearly not actually getting the checkboxed items into its form when the form button on that page is pressed. Ugh.

Precomposed versus Combining

In the course of putting together the encodings (called code points) in Unicode, a number of decisions had to be made regarding the current existing encodings, particularly well known and/or well established ones. In some cases, even though the Unicode Consortium has a particular policy regarding some encode vs render issues, there are inconsistent inclusions due to this grandfathering of prior established encodings and (to be quite honest) outright mistakes on the part of the Consortium. The question of precomposed characters versus combining characters is a classic one.

Read the rest of this entry »