« Previous Entries

The Archives

• GPF, Internet, Software, Technology

  Generating XML Sitemaps for MediaWiki

  August 22nd, 2008 (5 days, 12 hours ago) by Jeff | Permalink | Dump Core

  Not long ago, I took advantage of a nifty WordPress plugin to enable XML sitemaps for the blog. For those who’ve never heard of XML sitemaps (I hadn’t for quite a while), they are little XML files in a specific format that give search engines like Google hints on how to index your site. They don’t necessarily improve your search rankings per se, but they help the search engine better decide what to index, when it was last updated, relative priorities of different pages, etc. You then throw a special line into your robots.txt file or directly submit the file to the search engine to let it know the file is available. Once the engine knows about it, it will check it periodically to optimize how the site is indexed.

  The plugin, of course, makes this ridiculously easy for WordPress. However, GPF gets orders of magnitude higher traffic than the blog does, so finding a way to generate sitemaps there would be ideal. I toyed with the idea for a while until I finally sat down, examined the sitemap specification, and figured out how to roll my own code. It now successfully runs via cron each morning and gives a pretty thorough census of what’s available on the GPF server. The problem is that the GPF site is divided into several parts that are largely autonomous and self-contained:

  • The archive, of course, is the main bread and butter.  This is what people come to see, so it is vitally important to get everything represented, especially since the archive is entirely dynamic PHP. I count the main index page as part of the archive, as it displays the latest strip.
  • The forum is self-contained because it uses a third-party application: phpBB. I decided long ago to discourage spamming by blocking search engines from indexing the forum, relying on the forum’s internal search capabilities for users who want to find things. Since search engines were being blocked anyway, I decided the forum didn’t need a sitemap; that would just be a waste of processing time.
  • The wiki, however, is slowly becoming a vital part of the site. It replaces the old cast pages and adds tons more GPF metadata in a convenient, easily searchable form. I wanted to make sure that got included too.  The GPF Wiki runs MediaWiki, the same software that powers Wikipedia.  As far as I know, MediaWiki does not include any internal mechanism for generating XML sitemaps nor are there any extensions to do so.  (I could easily be wrong, however; I’ll admit my research on this was extremely limited.)
  • Then there’s everything else. The GPF site beyond the two pre-packaged items above is completely custom-built PHP, so there’s no one to blame for that mess but myself.

  Ignoring the forum, that left me three major sub-projects for creating sitemaps. It’s easy enough to segregate these into separate files and tie them together using a “sitemap index” file, so that wasn’t a problem.  The archive would just be a formatted dump of the archive database, deriving approximate update times from the posting date. The bulk of the rest of the site could be done by stepping through the file structure of the site and taking note of every HTML or PHP file and its last modification time (conveniently ignoring certain files and directories that don’t need to be counted, like access-restricted Premium pages). And that leaves the wiki.

  I managed to come up with a decent wiki sitemap routine that I thought I’d share, just in case someone else might be interested. Of course, it’s not likely to be useful for massive wikis like Wikipedia—sitemaps are restricted to 10MB in size and 50,000 URLs—but something small like the GPF Wiki would be easy to submit and index. It was built using MediaWiki 1.12.0; I am uncertain what database changes may be needed for older or newer versions. Here’s my current process:

  I only want to index relevant pages, including category pages. The relevant database table for this is “page”. (How… convenient). Unfortunately, this table also contains things like redirects and images. Each image has its own “page” assigned to it; try clicking on an image in Wikipedia or in the GPF Wiki to see what I mean. The time stamp of the latest revision, however, is stored in the “revision” table, joined to the page table by the latest revision ID number. So a good starting bit of SQL would be:

  select p.page_title, r.rev_timestamp from page p, revision r where p.page_latest = r.rev_id and p.page_is_redirect = 0 and p.page_title not like '%.gif' and p.page_title not like '%.png' and p.page_title not like '%.jpg';

  Unfortunately, this also returns a few meta pages like the sidebar and editing pages. Before selecting, I define a look-up hash of titles I want to avoid and as I loop through the results I just skip those.

  The title, of course, is both the displayed title and the input portion of the URL that uniquely identifies the page. Thus, knowing the base URL (http://www.gpf-comics.com/wiki/) I can easily reconstruct the public URL of any article from the title. As with Wikipedia links, spaces have already been converted to underscores, but the rest of the string needs to be be URL encoded. This is easy enough, so we can quickly build the full URL as required by the XML schema.

  The time stamp is a little bit tougher. MediaWiki stores time stamps as a 14-digit number in YYYYMMDDHHMMSS format, always in UTC time. In Perl (in which almost all my crons are coded) this is easy enough to break apart and turn into a UNIX time stamp. I then output the date in W3C ISO 8601 format as required by the schema. A sample of a resulting entry would be:

  <url>
     <loc>http://www.gpf-comics.com/wiki/Nick</loc>
     <lastmod>2008-08-22T06:00:07Z</lastmod>
     <changefreq>monthly</changefreq>
     <priority>0.3</priority>
  </url>

  Change frequency and priority are purely guesses and fudges for mine. According to the sitemap specification, priorities are purely relative to other parts of the site. I rated the wiki pages as relatively low since the wiki at GPF is considered a “supporting” page and subordinate to things like the archive. As for change frequency, the sitemap specification includes a number of predefined choices (hourly, daily, weekly, monthly, etc.). Monthly was a purely off-the-cuff guess; some pages may update more or less frequently, but monthly would be a good average. It is entirely possible to rate select pages as higher priority or frequency than others, but I decided to take the easy route and rate everything the same. To apply different values, you just need to pay special attention to the title and assign a non-default value when that title crops up.

  Well, I hope someone out there might find this helpful. I’m not sure if it really helps anyone find anything at GPF, but it was a fun little exercise nonetheless.

• GPF, Miscellaneous

  Busy, busy, busy…

  June 30th, 2008 (1 month, 4 weeks ago) by Jeff | Permalink | Dump Core

  Sorry for the silence for the past… good golly… has it really been almost three months? Yeep.

  Life’s been a little bit hectic on the GPF Farm. The good news is that GPF has been doing the best it’s done in years, and that alone has kept me hopping so much I haven’t had time to do much else. The bad news is that we’ve also had a lot of personal things going on to keep those few fleeting moments of free time from becoming truly free: several illnesses have swept through the house, hitting each of us individually in turn; we’ve had to fire a nanny and introduce Ben to the immunity-boosting powers of day care (see the previous item); and things have really picked up at work, where I’m currently multitasking on at least four projects. The post title says it all.

  I did have a nice little anecdote started for you about the real life events that inspired the recent “iDilemma” stroy in GPF. Unfortunately, I got heavily distracted (see the previous paragraph) and never got around to finishing it. You can get the gist of the backstory in the “RIP PDA” thread on the GPF Forum. GPF Premium subscribers will likely have this condensed and repackaged into the Author’s Notes accompanying the story once I finally get around to it.

  I do have a few things I’ve been meaning to blog about, so hopefully I’ll be able to get to those very soon. Again, sorry for the silence.

• GPF, Internet, Software, Technology

  Praise for XCache

  March 18th, 2008 (5 months, 1 week ago) by Jeff | Permalink | Dump Core

  The new GPF site has been running live for half a month now, and I’m proud to say things have been running incredibly smoothly. That is, at least, from my perspective; I haven’t seen any major glitches, and aside from a few typos in the comic (which are obviously independent of the site code), nobody has written me about any problems. This is especially heartening because the new site was pretty much entirely coded by hand by me, sans a few bits and pieces. (I can’t take credit for the OS, the web server software, the database engine, or the forum. But everything else… yep, that was me.)

  There were a lot of motivations for writing my own archiving system, but the primary one was efficiency. While I considered trying something off-the-shelf, so to speak, like ComicPress or Drupal, I really wanted something that would be blazingly fast yet still dynamically generated to let me do things like GPF Premium on the server side, primarily for security reasons. (Server-side processing means no messy JavaScript is required by the users, thus exposing them to less risks, while Premium content doesn’t even get sent to the browser at all if Premium isn’t enabled.) So the GPF site is optimized out the wahzoo, with certain high-volume pages built once by nightly crons while others that require more interactivity reduce database queries to simple selects as much as possible. I’m never one to brag and toot my own horn, but I’m actually pretty proud of the new site and how responsive it is.

  Of course, I can’t really take all the credit. I do have to give some serious props to XCache.

  For those unfamiliar with PHP, it is one of many server-side, interpreted scripting languages commonly used for dynamic Web site development. The caveat, however, to any interpreted language is that on each request the source script must be read, parsed, compiled, and executed before anything is set back to the end user’s browser. This is one reason why dynamic sites are and will always be slower than serving purely static HTML files. Static HTML just needs to be read and regurgitated; anything that requires the Web server to actually think takes more time. Add to that the fact that there could be hundreds or even thousands of requests all competing at once for content and it’s a miracle anything get served at all.

  XCache is one of several opcode caching extensions for PHP. Essentially, when the first request for a script is made, the script is parsed and compiled as usual. However, XCache stores the compiled code so subsequent requests can skip the parsing and compilation steps and go directly to executing the code. This significantly increases the speed of execution by eliminating one of the costliest parts of the process (except perhaps database connections). In addition, XCache also includes the ability to cache variables and objects, so commonly repeated and expensive variable generation–such as the cryptographic hashes I use for salting cookie hashes or database look-ups for common elements like the Premium subscription levels–can be stored in the cache rather rebuilt on each request.

  I was first introduced to XCache by the XCache for WordPress plugin, which was probably mentioned in one of the development feeds built into the WordPress dashboard. I’ve been running this combination here on the blog for a little while with moderate success; I’m still trying to find a good balance of configuration settings to get the best results, but I’ve been happy with the results so far. Without putting much thought into it, I went ahead and installed XCache on the GPF server, hoping that it would help even if I never got a chance to optimize it. Fortunately, it has helped, and now that I’ve optimized the settings it’s exceeded most of my expectations. I’m not sure if there’s something about my code that caches better than WordPress, but GPF has done much better with XCache than the blog has.

  Admittedly, I haven’t compared it to any other opcode cachers, nor have I benchmarked it against any of the competition. That said, however, I heartily recommend it to anybody running PHP applications. To get the greatest benefit, you may need to modify some code (or install a plugin if you’re using a prepackaged application) to take advantage of the variable/object caching. But even without modification the opcode caching alone makes for a vast improvement.

• Internet, Miscellaneous, Technology

  Down time

  February 29th, 2008 (6 months ago) by Jeff | Permalink | 1 Core Dump

  Not sure if anyone noticed, but both the blog and the new GPF beta test site were down last night. Our hosting service, Slicehost, informed us that a breaker blew in their data center and they were forced to bring a number of machines down to protect them. In addition, the blog server (which also hosts a number other private sites I run) stopped responding, so they had to reboot it again.

  Unfortunately, while Slicehost was very informative and sent me several e-mails to keep me apprised of the situation, the sites continued to be down until early this morning. That’s when I discovered that for some bizarre reason the MySQL and Apache services were not configured to start at boot time. This is baffling, in my opinion, as I thought this was automatic with Fedora. You install the application package and, if it’s a service like this, it also installs the appropriate links in the init directories to make sure the services start on boot. Not so, apparently. I’m not sure if this is Fedora’s fault, Slicehost’s, or mine, to be honest, but it should be fixed now.

  There’s one part of me thinks that this outage is an ominous sign on the eve of my leaving Keenspot. Then again, it also helped me catch a critical flaw that would have been extremely annoying if it happened a week later, after the move when thousands of readers would be hitting the new site. So I don’t know whether to be paranoid or relieved. (O_O)

• GPF, Internet, Technology, Webcomics

  But we were there first. OK, maybe second.

  February 25th, 2008 (6 months ago) by Jeff | Permalink | Dump Core

  Anyone interested in the history of webcomics should check out this week’s episode of the This Week in Tech (TWiT) podcast. Especially since it has nothing to do with webcomics.

  Here’s my line of reasoning: In this episode, Leo Laporte and his unusual round of suspects are joined by Jonathan Coulton, geek musician extraordinaire. Aside from discussing a few topics of current note (like the death of HD DVD), they discuss a recent concert by Coulton where Leo and company joined him to play Rock Band before a nerd-filled audience. They go on to talk about the “new” Internet phenomena of niche entertainment targeting–skipping the big, mass-market blitzkrieg typically used by music, TV, and movie studios and canvasing thousands or millions of potential customers, to instead go directly to your core fans, the few dedicated people who are the ones that will really appreciate what you do. Coulton talks of making a living catering to a small handful of hard-core fans and how this is much more fulfilling that the big media alternative, where both the artist and the audience are faceless statistics on the bottom line of a balance sheet. And they discuss this with such freshness and enthusiasm, as if this is were the next new thing, some epiphany that no one has yet uncovered.

  What I find so funny about it is… those of us in webcomics have already been doing this… for years.

  I’ve noticed this a lot over the past near-decade of GPF’s existence. Blogs, podcasts, and other forms of grass-roots media have all cropped up during that time, putting publishing power in the hands of the masses, becoming “innovative” and “groundbreaking” in bringing content production to the people. But a fair number of “new” trends (and problems) associated with these technologies are things I remember seeing crop up among webcartoonists several years before. Long before the term “blog” was coined, I remember chatting with other cartoonists on mailing lists and news groups, swapping ideas about search engine optimization (before that term was coined as well), getting and retaining readers, how to monetize your site, etc. It’s entertaining now to watch many tech headlines to see “fresh” ideas crop up that I’ve personally tried–and abandoned–a couple years before. It’s like the wheel reinventing itself every couple of years, only with different colors and/or materials.

  Of course, I would never be so conceited to believe webcomics “did it first.” Webcomics themselves borrow heavily from the underground comics movement of the 1950s, 60s, and 70s, where small independent publishers ducked under government sensors to push out innovated and controversial content directly to the people who wanted them. What changed between then and now is that the interconnectivity of the Internet moved this from basements and back rooms to hidden mailing lists and chat rooms, eventually making its way to the mainstream, all while expanding the sphere of availability from isolated pockets of common interest to global reach. It would also be naive to believe this flow of “innovation” is one-way; RSS and other syndication technologies took off first in the blogosphere, and was only later ret-conned and shoe-horned into webcomic automation systems as a handy update notification system.

  Perhaps one of the reasons bloggers and podcasters didn’t learn any lessons from webcartoonists is the difference between skill level–real or perceived, take your pick–required for entry. Cartooning obviously requires some level of artistic talent as cartooning, in all of its myriad of forms, is a form of art. It’s often a commercial art, intended more to generate revenue than anything else, but an art nonetheless, conveying ideas and emotions graphically. And while a well-crafted blog certainly requires a talent for writing, that is often easier to come by than the ability to both write and draw. Thus the critical mass of webcartoonists is much smaller than that of bloggers and podcasters, making it less noticeable to the mainstream. That’s also why “break-out” blogs now seem to be a dime a dozen, but it’s still major news when an online comic gets noticed by big media and gets optioned for TV/movie deals. Everyone knows about blogs and maybe even reads a few, but there are other comics on the “intraweb” besides Dilbert?

  I’m not sure if there’s anything useful to these observations, other than the fact that they amuse me occasionally and it gives me something to post about. I’m not sure if anyone else has made these kinds of observations or, for that matter, anybody else cares. But I’ve often wondered if those underground cartoonists of yesteryear thought to same way about us webcartoonists as I have about bloggers. I’d like to think so, just because it creates a nice symmetry. I can’t wait for bloggers to sit around in the old bloggers’ home, thinking such thoughts about whatever comes next. “Those kids with their holocasts… if they had learned the lessons we did about AI search, they’d be raking the quatloos by now….”

• GPF, Internet, Security, Technology

  Cookie cunundrum

  February 6th, 2008 (6 months, 3 weeks ago) by Jeff | Permalink | 15 Core Dumps

  By now, I’m assuming most of you have read Mondays GPF News item. (If you haven’t, shame on you.) GPF is leaving Keenspot, and I’m neck-deep in unit testing the new site with hopes of releasing it to beta testers soon. If you’re interested in beta testing, you can volunteer in this thread on the old forum.

  However, I’ve hit upon one little programming snag, so I thought I’d put out an appeal for help. I thought the blog would be more appropriate venue for this than the forum; that assumption could be wrong, but I’ll go with it anyway. For those of you with some Web-based programming knowledge, especially in the areas of PHP and cookies, please put on your thinking caps.

  As part of the new site, I’m implementing my own version of Keenspot’s PREMIUM service, reusing the old relabeling of GPF Premium. Keenspot PREMIUM is going away (for several reasons I won’t go into here), but as the service’s biggest proponent and largest beneficiary, I’d hate to lose that functionality. So the new site will launch with its own independent Premium functionality including all the old service’s features (optional ad-free surfing, weekly archives, High-Def archives, tons of exclusives like Jeff’s Sketchbook, etc.) plus a few new features that I’ve been wanting to implement but haven’t had the time or technological hoop-jumping expertise to work on at Keen.

  For security reasons, I want to secure Premium sign-ups and account management via secure HTTP (HTTPS). The benefits should be obvious. By encrypting account creation & management pages, you eliminate sniffing attacks and protect user privacy. While these pages may still be susceptible to other forms of attacks (and I’ve coded them to be as resilient as I know how), encrypting the traffic end-to-end can go a long way to cutting off those vectors of attack.

  However, I seem to have hit a brick wall when it comes to setting the Premium authentication cookie. Like Keenspot’s implementation, the subscriber’s browser will be “enabled” by “branding” it with a cookie, which will be read and authenticated each time the page is loaded. If valid, Premium features for that page will be turned on; if invalid, the page will default to a non-enabled state, which could be a simple as showing all ads or as complex as denying access to the content within. Unlike Keenspot’s implementation, which was JavaScript based, mine is scripted server-side in PHP, meaning it should be more accessible to a wider range of browsers and in theory more secure (no Premium content is sent at all if Premium is not enabled, rather than letting the client browser decide). My implementation has been thoroughly tested and appears to work pretty much flawlessly… with one hitch.

  The problem occurs when I set the cookie over the encrypted HTTPS connection, then try to read it over unencrypted HTTP. I appears that none of my test browsers send the cookie back when the encryption state changes. The reverse is the same; if I change the URL and set the cookie over HTTP, then try to access a page via HTTPS, the encrypted page can’t see the cookie either. It works like an either-or situation, when what I really want is both. If I set a cookie over HTTPS, I want to see it in both HTTP and HTTPS mode.

  PHP’s primary cookie interface is the setcookie() method (for setting) and the $_COOKIE array (for reading). setcookie() includes a boolean parameter for secure cookies, i.e. cookies that will only be sent via HTTPS. What’s annoying is that even when I set this flag to false to force it to be insecure, the scripts continue to exhibit the same behavior: cookies set via HTTP can only be read via HTTP and vice versa. I’ve also tried setting the same cookie both ways–first in one protocol, then the other, without erasing the first cookie–but that didn’t seem to work. The second cookie overwrites the first one, effectively turning it off.

  I had heard that IE 6 exhibited this behavior as a bug. However, I tried the exact same tests in Firefox 2.0.0.11, Opera 9.24, and Safari 3.0.4 (all on Windows) as well as IE 7, and all reacted the same way. Cookies set over HTTP could not be read over HTTPS and vice versa. It’s a bit frustrating. Obviously, I don’t want my Premium folks to be forced to use the new site in encrypted mode all the time, as this would slow down all the pages and put a significant extra load on the server as the number of subscribers increases. But I want to protect my users’ privacy and settings (and one of my important revenue streams) by encrypting their account access.

  So I guess I’m looking for answers to two questions:

  1. Is this some new standard of behavior that I’m missing? I was operating under the assumption that secure cookies (those set with the boolean secure flag) were restricted to HTTPS, but otherwise all other cookies should be sent regardless of whether it was encrypted or not. When I use the awesome Firefox Web Developer plugin, it tells me that the cookie should be there regardless of the encrypted state. Yet it still doesn’t get sent. But am I asking too much? Am I not understanding the specifications, or has something changed that I wasn’t aware of? Can I not have my cake and eat it too?
  2. 1. If I’m right and this should be working, what am I doing wrong? Is there a feature of PHP I should be use other than setcookie() to do this? Is it a bug, either in PHP or the browsers?
     2. If I’m wrong and this behavior is expected, is there a workaround I can use to let the same Premium features work over both HTTP and HTTPS? Or should I just give up on the encrypted account management and assume my stuff isn’t worth stealing enough to bother?

  Any responses via e-mail or (preferred) comments below will be appreciated.

  Update March 5, 2008: Thanks to the input of many commentors below, it looks like I’ve got a solution. The problem, as usual, was somewhere between the chair and the keyboard and the faulty component has been sufficiently flogged with a wet noodle. Immense thanks to everyone who provided feedback and suggestions.

• GPF, Webcomics

  First all-digital GPF strip is in the queue

  January 22nd, 2008 (7 months, 1 week ago) by Jeff | Permalink | Dump Core

  As previously forecast, the first all-digital GPF strip is now officially in the queue. Since yesterday was a holiday, I was able to sit down and spend some time scripting and planning for Year Nine of the comic (after finally packing up and moving all our Christmas decorations into the attic). I then got my first chance to sit down with Hermes and work from a raw script to build a finished GPF strip, from start to finish, without the single use of pen and paper. Mind you, I’ve done a few strips that were up to 95%+ digital, reusing old art or having tons of digital effects. But even on those the panel boxes were drawn by hand or the original art lifted from other strips were drawn on paper first. This was the first time I “penciled” and “inked” everything in the computer without touching a single sheet of Bristol board.

  It was… a learning experience.

  I used my old process as a template and modified steps as I went along. I had created some panel templates a while back using Inkscape and imported that into Paint Shop Pro, splitting them into their own layer. I then created background, sketch, and ink raster layers (when imported there was no background, so I had to add one), then added a vector layer for the text. Just like working with my old process, I put in the text first; only this time, the typed text went directly into the panels as the finished product rather than measuring out space to add it in later. I sketched my rough lines in the sketch layer, which gave me the added benefit of being able to remove the sketch lines at will by turning the layer on and off. I found out my sketching technique doesn’t translate cleanly to digital work. I pick my pencil up quite often and quickly set it back down and sometimes this move is so quick the stylus doesn’t register it at first, resulting in missed lines. (I noticed this before with my Wacom but it wasn’t as obvious when I didn’t use it as often for sketching.)

  Once penciled, I moved to a different layer and put in the inks. I haven’t been able to get pressure sensitivity to work with Hermes; I know it does work, as there’s a pre-installed app that supports it, but I haven’t gotten it to work in PSP yet. However, since I’ve always drawn with technical pens in the past, I’m used to working with lines of set sizes, fudging occasionally when I really need to taper something. (Bill Holbrook of Kevin & Kell does the same thing.) So I used varying sizes for my paint brush, mimicking the approximate sizes of each technical pen I used to use. It took a few tries at first to get what I wanted, but it worked out fairly well. I decided to do my character flat colors in the ink layer as well so they would sit above the background gradients, which was an added step I never had to worry about before.

  I tried to do vector word balloons for the dialog, but I’ve never been happy with the predefined “callout” objects PSP came with. So I drew those by hand as well, making them not a far departure from the way I used to draw. Of course, one advantage I have now is that I can flip and rotate Hermes around as I draw, making straight lines easier to freehand. That’s not something to do with Bristol board taped to a big, bulky art desk.

  All in all, it turned out pretty well. I’m satisfied with the results. Not impressed, but satisfied. Admittedly, the first story of the new “year” is a pretty simple one artistically, which was a conscious decision. I knew I’d being trying out new things so I wanted to make things relatively easy on myself. This should give me time to find a new groove before the second story, which will be a bit more ambitious. (The only hint you’ll get for now: the honeymoon.)  I imagine things will get easier as I get used to my new process. The big advantage, of course, was that I wasn’t hidden away in the basement away from my family, so I was instantly accessible if my wife or son needed me. I do think it took me less time as well, but I didn’t bother timing myself to make sure.

  So when do you get to see the final result? March 10th. Which makes this a good time to transition to the next topic of this post….

  March 10 will mark the beginning of the next GPF “year”, Year Nine. Year Nine was supposed to start in November 2006, but because of the many delays that plagued me after Ben was born, I’m seriously behind. That can’t be helped, of course, so I’m just going to continue on as best I can. Year Nine will be abbreviated, running from March 2008 through October, with Year Ten starting on the day after GPF’s tenth anniversary, November 3rd. I’ll then try to return to the old November through October “year” schedule I maintained from the beginning, for as long as I can keep the strip running.

  The best news: I’m going to try my best to move GPF back to a three-day-per-week schedule starting with Year Nine. So on March 10, expect to continue coming back Mondays, Wednesdays, and Fridays, but look for fresh strips throughout the week. By setting this as the start of the new “year”, I’m now back at my ideal eight to seven week optimal buffer; if I can produce three strips per week with this streamlined process, I should be set to keep this buffer. It will mean some modifications to my storytelling process, meaning I’ll be aiming for smaller, funnier stories and fewer “mega arcs”. (Pauses for cheers from some of the audience to die down.) However, look for things to become a bit more serial as I try to work larger-running plot threads into concurrent smaller stories.

  Note, of course, that this announcement comes here and not in the official News. Ergo, it’s not officially official yet, so you can officially take it with an official grain of salt. This is a goal and not a policy yet, so don’t look for it to be set in stone (or at least Jell-O) until you see it announced there.

  As I’ve hinted here and in the GPF News, there are a lot of changes in store for GPF this year. These are but a few of them. Look for several huge announcements (and I do mean huge) to be coming out in the next month or so. If you are not currently subscribed to the RSS feeds here and on the GPF site, now might be a good time so you won’t miss anything. Keenspot PREMIUM folks should pay special attention, as you will be the most directly affected. (If you’ve been ignoring the dusty old Rumor Mill page, now might be a good time to checking it periodically.)

• GPF, Hardware, Technology, Webcomics

  Introducing Hermes

  January 2nd, 2008 (7 months, 4 weeks ago) by Jeff | Permalink | 4 Core Dumps

  

  Sorry for the quality of the picture. This was taken with my cell phone’s camera, which isn’t the best in quality but all I had available at the time. (I also should have cleaned the screen before taking this. Oopsie.)

  As mentioned in Monday’s GPF News post, I’m looking at a number of ways to take GPF completely digital as a way to speed up my process while not taking time away from my family. The history and reasoning behind this transition is pretty well outlined in the News post, so I won’t replicate it here; make sure you read that post to get the gory details. However, I haven’t really discussed the primary tool to implement those changes, which I felt would be more appropriate to talk about here than in the “official” GPF News.

  I’d like you to meet Hermes. Hermes, say hello to the nice people. Hermes is a Lenovo ThinkPad X61 Tablet PC. (For those old timers who may be confused by seeing the name “Lenovo” attached to IBM’s old flagship ThinkPad notebook PC brand, IBM spun off its PC business in 2005 to Chinese company Lenovo, who had already done most of the manufacturing for IBM’s PCs for several years.)

  As mentioned in the above linked News post and in the publicly accessible Behind-the-Scenes page, GPF has been a half-analog, half-digital process since pretty much the beginning. What I’ve apparently failed to mention in (or perhaps it would be better to say that I’ve failed to update) either the public Behind-the-Scenes page or its expanded Keenspot PREMIUM-exclusive counterpart is that I’ve been using a Wacom Intuos3 tablet for several years now. Wacom is probably the best known manufacturer of digital tablets which are used by digital artists, 3D modelers, and CAD architects the world over. Digital tablets are much more intuitive for artists to work with than most other pointing devices (mice, pointing sticks, trackballs, etc.), usually giving you a pen or stylus to manipulate the cursor on the screen. I’ve spoken to many digital artists over the years who swear by their Wacoms who eventually convinced me to splurge and give it a try. The Intuos is their mid-range line for advanced amateurs and frugal professionals; many of the artists at my day job use Intuoses (Intui?). My Intuos has gone a long way in improving the GPF development process, and it’s only with great reluctance that I fall back to the mouse or other pointing device for really high-precision details.

  That said, the combination of a tablet and a laptop is a bit… cumbersome. Usually when I do the digital half of a strip, I’m sitting on the couch in the living room with Apollo, our previous “alpha” ThinkPad, in my lap and the Intuos hovering in my hand above the keyboard. This works well enough as long as I don’t need to type anything, but leads to some awkward flipping of the tablet up and down when I have to change certain settings or use a different pointing device. It also leads to some uncomfortable right hand positions as I try to balance the tablet above the keyboard without accidentally hitting keys. But perhaps the most fundamental problem is the disconnect between what the hand does and where the eyes are looking. Many of us have been trained for years to move a mouse with one hand while looking at the moving cursor on the screen. This becomes a little more awkward for an artist who is used to looking at the art beneath the pencil/pen/brush in their fingers. I minimize this somewhat by having the tablet so close to the LCD of the laptop, but it’s still not as intuitive as I would like. If only I could actually draw on the screen….

  Wacom has a line of LCD displays with tablet capabilities called the Cintiq. I’ve wistfully mused about one for some time, but didn’t really covet one until I played with on at SIGGRAPH 2007. The large, crisp, bright display combined with the ability to draw directly on the screen was intoxicating, and I had to admit that I began to rationalize the high price tag just to get my hands on one. After all, I haven’t been to a con in a couple years now, so the GPF checking account has reached all-time highs with much more coming in than going out. But the Cintiq would be wholly impractical in my situation, where my digital art is technically a secondary source of income and the return on investment would be minimal. It would also be impractical from a physical standpoint; having seen one now in person, it’s completely unrealistic to sit on the couch with my son playing in the floor while having this massive 20″+, 16+ lb glowing brick in my lap. I’d have to move the digital work to a dedicated location, further isolating me from my family while working on the strip. If only I could have the draw-on-screen power of the Cintiq in a portable form….

  It was about then that my wife called my attention to the latest employee purchase options at her work. Whereas I was laid off from IBM back in 2003, she’s still an IBMer and still has access to their employee purchase program. Since Lenovo now produces IBM’s old line of PCs, the two companies undoubtedly have a deal that allows the old IBM employee purchase program to access Lenovo machines at significant discount. And sure enough, Lenovo has recently added a line of Tablet PCs to the ThinkPad brand.

  The Tablet PC is an interesting concept, but one I wasn’t very enamored with when I first heard of it. The concept is to apply the idea of a “notebook” further to the “notebook PC” by introducing the ability to write directly onto the computer’s screen. Handwriting recognition software would translate the user’s hand written notes into traditional computer text, making note taking more intuitive for less tech-savvy individuals. The concept, however, has been pretty slow to take off. In some places, the PDA (admittedly a dying breed of technology) continues to be more portable and better at converting handwriting to text. In others, the laptop is so deeply entrenched that the target users have already made the move to typing over writing and returning to a stylus would be a step backward. (How many words per minute can you type versus write by hand?) But there are two places where Tablet PCs have really taken off: replacing the traditional clipboard charts in hospitals and… digital artists on the go.

  Let me start off by saying that I’m really impressed by this little guy. The transition from using a mouse to using the Intuos was rough at first, despite the fact that the tablet is more intuitive to an artist. You get used to doing things a certain way and relearning things always introduces a few speed bumps. The transition from the Wacom to the ThinkPad, however, was a lot smoother and I barely noticed the difference in speed. In fact, text entry has been the biggest speed bump so far. Using the on-screen keyboard is a bit clunky and is probably the biggest bottleneck in terms of physical speed. However, since Hermes has more memory and a faster processor than Apollo, any slowdowns from removing the keyboard from the equation are probably negated by the beefier hardware. I did have one problem with losing the touch strips on the Intuos which are usually mapped for zooming; I never realized just how much I used those until I lost them. However, I was able to remap a couple hardware buttons on Hermes’ screen to emulate the mouse wheel (which also does zoom in Paint Shop Pro), eliminating this problem.

  The real Achilles heel in this transition, however, is my software. I’m still using my old decrepit copy of Paint Shop Pro 7 that I’ve been using for years now. I’ve been disappointed in both the increasing price of the software and the constant upheaval Jasc (the original developer) caused with each revision of in the interface, so I never bothered to upgrade. Then Jasc was bought out by Corel, and constant complains from our Corel Draw users here at work have convinced me to steer clear of upgrading my beloved PSP from here on out. I’m still too cheap to justify the ridiculous price tag for Adobe Photoshop, which I’m unwilling to switch to anyhow because I don’t really want to relearn a whole new interface. (I always felt that PSP’s interface, at least in versions 4 through 7, was much simpler and easier to use.) And while my long term goal has been to switch to completely free alternatives like the GIMP and/or Inkscape, that’s yet another completely different way of doing things that I’d have to unlearn and relearn, and the reason I’ve never made that transition is that my time is better spent now making comics than learning new software.

  Mind you, overall PSP has worked extremely well with the tablet. It’s not an OS/application problem, as Hermes runs Windows XP, just like Apollo did. The problem comes in with one tiny yet critical aspect of the PSP interface and the apparent lack of precision in the tablet stylus. There’s one control on the PSP palette toolbar that controls switching between flat colors, gradients, and patterned fills. The only way to switch between options is to left-click a little black arrow in the tool, which brings up a tiny context menu with the options. Once you’ve chosen a general option, you can left- or right-click the rest of the control to bring up the option dialog (to switch from, say, linear to circular gradients). The problem is, I can’t for the life of me get the stylus to register a click on this tiny little arrow. I’ve literally tried repeatedly to get this click to work to no avail. There is no keyboard shortcut for this action, which in a way makes sense given the nature of the tool, but is completely frustrating because I could easily remap a hardware button to do this if such a shortcut existed. So for now my only option is to stop what I’m doing, flip the screen back around to traditional laptop orientation, use the TrackPoint to click the arrow and choose what option I want, flip the screen back around to tablet mode, and usually rotate the screen around again so it’s back to the orientation I originally wanted. This is brings my process to screeching halt, completely interrupting my work flow and is annoyingly disruptive. The problem might be easily solved by switching to a different image editing program, but that’s an issue I’ve already addressed.

  All that said, I’m really loving this new little toy. It has done incredibly well so far, even though all I’ve done is use it in my traditional analog/digital production flow. The real challenge will be when I start making all-digital strips, which I plan to do with the next story, i.e. once To Thine Own Self… is completed.

• GPF, Webcomics

  I have some of the coolest fans…

  November 19th, 2007 (9 months, 1 week ago) by Jeff | Permalink | 1 Core Dump

  

  The above picture was sent to me by GPF readers Jeremy and Teresa the other day. Accompanying the pic, Jeremy wrote:

  BTW, I don’t know if I sent this to you last summer, but I meant to. My wife and I had a Nick & Ki figure made for our wedding “cake topper” in July, 2006. We had Nick’s hair done blonde to match mine, and I thought it looked great.

  And it does. Another fine example of Lanin Thomasma’s excellent handiwork. If you haven’t seen his awesome GPF sculptures, then you need to go give them a look. Lanin has crafted a good dozen (or more) GPF and non-GPF maquettes for me personally, some of which have accompanied me to shows & cons. I don’t really want to turn this post into an advertisement, but these sculptures are so incredible it’s hard not to.

  As for the statue in question, Nick looks a little odd to me as a blond, but it definitely fits with the rest of their wedding photos. (Jeremy was gracious enough to share them with me.) I hope you two have an awesome future together. I certainly hope nobody at your wedding was kidnapped by any “evil twins” from alternate universes….

  (Random trivia: The “cake topper” for our wedding was Mickey & Minnie Mouse, since we were going to Disney World for our honeymoon. While Nick & Ki existed at that point and I knew they were eventually destined to be married, nobody outside of a circle of close friends and family had read the GPF scripts yet and I certainly didn’t know of anyone that could make custom maquettes for us. Oh, well….)

• GPF, Webcomics

  GPF’s ninth anniversary

  November 2nd, 2007 (9 months, 4 weeks ago) by Jeff | Permalink | Dump Core

  Woo.

  You know, I could wax all philosophical, get nostalgic and misty-eyed, ramble on and on about how things have changed between 1998 and now, but… I’d rather not. If you care, celebrate in whatever means you are so accustomed, although I request that if you do so in the name of GPF that you do so in a socially responsible manner. (Don’t want anyone going to jail for some drunken GPF-inspired murder spree.)

  I guess I could mention, in the light of other comics celebrating a decade of existence recently, that GPF was actually created in 1997 and I spent over a year developing and honing it before it came online. So in a sense, GPF is also a decade old, although not officially until November 2, 2008. Somehow, I doubt anyone would really count that.

  Woo.

« Previous Entries

About

Jeffrey T. Darlington is the creator of the popular online comic strip General Protection Fault. He is also the creator of a number of other inconsequential things, but seeing as they are inconsequential, he didn't think you should be bothered by mentioning them. More...

Search

Capitalism

Recent

• Generating XML Sitemaps for MediaWiki
• Wii Fit kicks my tushy
• Look, Ma! I’m on Security Now!
• Maybe I should have persued a career in radio…
• ICANN get behind “gpf.comics”…

Tag Cloud

'N'Toonz .NET anniversary Apache authentication Baby Stuff comments cookie diaper DoubleClick e-mail fans fractal GMail GPF Mandelbrot Madness maquettes meta Microsoft mod_rewrite PayPal PHP Pobox.Com podcast poopy schedule sculptures Security Security Now Software spam Steve Gibson Technology Thunderbird To Thine Own Self TWiT virtualization virtual machine Vista VMware Webcomics Wii Windows WinHasher WordPress