The reasoning behind the nickname, as one probably already guess it, was the phonetic similarity with my own name – Helder, in case you’ve missed it!

Thing is, when I started using international servers (freenode, Mozilla IRC Network and so on) the “Hell” caused some disturbance in users from countries where the name Helder is uncommon, probably associating it with chaotic and destructive users… I then (temporarily) stopped using it, and started using the “boring” OwnnameLastname in most services, although it didn’t feel like a nickname at all.

Today, I decided to start using a “decent” nickname again. It’ll be using yet another pun: Lthere. It seems even more confusing, which is the idea after all.

So, if you don’t see HelderMagalhaes around anymore, just scroll to the “L” word (not that one, silly! ) and that’s probably me.

Cheers,
Lthere

Update 2011-01-11: Added Batman-inspired image created from logo (shamelessly copied from here); “Batman Returns” font found here.

Screenshot of SVG image after rotation, zoom and pan

I’ve just finished a demo which tries to fill a long caveat among SVG implementations: a consistent front-end for internal document navigation (zoom, pan, etc.). It took me a while to workaround and document a few subtle bugs in several implementations, as well as recently integrating SVG Web, which has it’s own set of limitations, but it’s ready (at last!).

What are you waiting for? Go ahead and try it!

Firefox screenshot after rendering the page

OK, I better start by stating this post’s title is actually a pun: as far as I know, Emacs doesn’t cause any interoperability issues with SVG implementations, but I thought like a sensationalist headline from time to time won’t hurt…

Today I stumbled across emacsformacosx.com, a nice HTML+SVG use-case: HTML for the actual text content and SVG for visual improvements, which would degrade whenever no support is available (Internet Explorer, essentially). Unfortunately, the site seems to have triggered a few bugs in several implementations…

Firefox rendering issue in pen clip

In a Firefox 3.6a nightly build:

• The pen clip sometimes hides during mouse drags (see bug 541883)

In a Firefox 3.0.x previous release:

• The pen clip only shows up when triggering the context menu over the “Download” button (see bug 541883)

Opera rendering issue in text selection

In an Opera 10.10b weekly build:

• The whole drawing doesn’t even show up initially, usually only after forcing a page reload
• Bringing up the context menu on the broken loaded image (only with the vertical gradient visible) and selecting “Original size” (to force a redraw) only displays the graphics: text portions are not (re)drawn
• Selecting the text within the star from a line up to the line above shows text selection redraw issues

In Opera 9.64 release:

• The whole drawing doesn’t even show up initially, usually only after forcing a page reload
• Selecting the text within the star from a line up to the line above shows text selection redraw issues

(Behavior is similar to version 10.10, with the exception that using “Original size” to force a redraw actually works.)

IE8+ASV6 rendering issue in inline SVG

Using Internet Explorer 8 RTM + ASV 6 (SVG viewer plug-in):

• HTML+SVG integration on page breaks pretty bad

Note that, by default, IE8 doesn’t allow in-line SVG in HTML: this result was obtained using tweaked settings. An untouched IE installation will properly display the text-only version of the website.

At least WebKit behaved (surprisingly?) well! Given that the site is for a Mac OS application download, I imagine the author was using Safari (which is built upon WebKit) and therefore might not have realized these small issues… (By the way, I’m contacting the author as soon as this post goes on-line.)

Update 2009-11-22: Added screenshot of the page rendering for posterity.
Update 2010-01-31: Added link to Firefox bug report; Fixed WebKit word case.

Properties screenshot of a file shipped with Adobe Reader 8

A common belief is that ASV 6 Developer Release 1 was the last version of the famous Adobe SVG Viewer software (ASV 3.03 being the last stable release). Well, apparently not…

Distributed with Adobe Reader 8, one can take a peek at the ImageViewer.API file, placed within the plug_ins directory (full path will typically be %ProgramFiles%\Adobe\Reader\plug_ins\ImageViewer.API. The original filename, NPSVG8.dll (see screenshot), is probably familiar to whoever has played with previous ASV versions: NPSVGX.dll stands for Netscape Plugin, where X is the major version number; the file was used for deploying the plug-in in browsers, such as Firefox (Gecko) and Safari (WebKit), who didn’t natively support SVG by then. As of today, at least Firefox is no longer compatible with the plug-in (and Safari will likely follow) but they don’t need to anyway: a good level of native SVG support is available in modern browsers.

When first I noticed about this file, there was an obvious question bouncing in my mind: Would it be possible to turn NPSVG8.dll into an updated SVG Viewer? That is, to integrate the DLL in order to produce a fixed version of ASV6 (which, while being superior to ASV3 in terms of features, is also more unstable and has a couple of nasty regressions). Crawling through the web brought up a link containing some leads, but in any case, the Adobe Reader license blocks it (in case someone is still wondering):

Plug-in Restrictions. You will not integrate or use Adobe Reader with any plug-in software not developed in accordance with the Adobe Integration Key License Agreement.

I wonder if Adobe would issue an integration agreement for doing that…?

A quick search through Adobe Reader 9 shows that the plug-in seems to have been removed for good. Chances are that functionality might have been reworked into Multimedia.api; also, some features were probably moved to the Adobe Mars (PDFXML.api) plug-in. Well, this turned out to be nice material to write about, anyway…

Notice 2009-11-30: This post wasn’t actually published when written: the post contents were mostly ready but, unfortunately, got lost in my “to do” stack (see the first blog entry for more on this).

BIOS screenshot of USB controller speed configuration

Today, while browsing through my system’s BIOS for some tweaks, I noticed a strange sentence in my peripheral configurations:

Configures the USB 2.0 controller in HiSpeed (480Mbps) or FullSpeed (12Mbps).

Full-speed at 12 Mbps and Hi-speed at 480 Mbps? Damn, is this a typo in the BIOS textual description or am I missing something? I crawled the Web and found out that it was I who was confused: in fact, Hi-speed USB is the fastest one.

I was aware about the speed differences, I just didn’t had noticed such a counter-intuitive marketing terminology for the two different versions. And yes, I’m convinced that I was the one who had “tweaked” the setting to Full-speed (option which was active when I noticed the weird sentence).

So that’s why my USB drives were so slow… And me blaming the drivers and hardware for the lame performance… Better double check yours too to see if no one did the same mistake as I did!

Finally, while investigating the difference between Full-Speed and Hi-Speed, just noticed the upcoming Super-speed which will take data transfer into light-speed (!). Not that my current data transfer requirements are as high, but I always like to watch things moving!…

Notice 2009-09-27: This post wasn’t actually published when written: the post contents were mostly ready but, unfortunately, got lost in my “to do” stack (see the first blog entry for more on this).