Tickled to Death

Dear Lazyweb,

I've been having a problem on my Ubuntu Gutsy systems (lock it up, peanut gallery). Basically, if trying to print a PDF that contains any images at all, either from evince or using pdf2ps, it takes forever. I'm talking on the order of 10 minutes per copy; even if it's multiple copies of a single page, one will come out around every 10 minutes. Granted, this is a parallel printer as opposed to USB, but even it shouldn't be so slow.

Now, I don't print a lot, but when I need to, it's definitely annoying. I've confirmed with friends that this happens on other Ubuntu Gutsy systems as well.

I did some basic testing, and I suspect that Ghostscript (gs) is, in the conversion process, making any images just too high of resolution in the PS file. Behold:
jtickle@jtickle-ess:~/Desktop$ pdf2ps python_flier.pdf python_flier.ps
jtickle@jtickle-ess:~/Desktop$ ls -lh |grep python
-rw-r--r--  1 jtickle jtickle 242K 2007-10-16 10:15 python_flier.pdf
-rw-r--r--  1 jtickle jtickle  15M 2008-02-14 10:02 python_flier.ps

Wow, a 242K PDF becomes a 15M PS? That can't be right!

I'm pretty sure both 'pdf2ps' and 'evince' use 'gs' to convert PDF to PS. A quick look over the man page for 'gs' reveals a resolution option. Let's try 72x72:

jtickle@jtickle-ess:~/Desktop$ pdf2ps -r72xz72 python_flier.pdf python_flier.ps
jtickle@jtickle-ess:~/Desktop$ ls -lh |grep python
-rw-r--r--  1 jtickle jtickle 242K 2007-10-16 10:15 python_flier.pdf
-rw-r--r--  1 jtickle jtickle 864K 2008-02-14 10:11 python_flier.ps

Still not optimal, but much better, and only takes ~1 minute to come out of the printer. On the other hand, the print looks TERRIBLE. At least when it takes 10 minutes, the print doesn't look bad.

There's a bunch of fun-looking stuff in /usr/share/ghostscript/8.61/ that I don't understand a word of but looks like it could have something to do with the problem.

Does anyone have any idea what sort of options should be passed to gs to not make a ridiculously huge PS file but also have it not look like butt? Or if different resources should be in /usr/share/ghostscript?

So every now and then, I hit up Digg for a few minutes worth of brain cell slaughter. That's truly all it is, because for the most part, it's silly pictures, dumb videos (except for the one where a guy makes his own vacuum tubes), and of course, top N lists, where N is {3, 5, 10, 20, 21, and pretty much the set of all natural numbers}. I don't have any dumb videos to show, and the picture isn't all that silly, but it does show the Handwriting widget embedded inside a Tomboy note. And as for the top 10 list...

10. I'd like to apologize to everyone that I haven't spoken to already involved with the Mono Project and the 2007 Google Summer of Code. I recently looked through the blog and realized that a WHOLE LOT of work was done *before* the Summer of Code even started. And then, the day it starts... nothing, until now. This certainly wasn't on purpose, and what it comes down to is that a lot of stuff came down on me at exactly the same time. I was able to get a little hacking done over the course of the summer, but not much.

9. I now work full time for Appalachian State University, home of the 3-time NCAA FCS National Champion Mountaineers. But my job has absolutely nothing to do with football (their website isn't even hosted on campus). I am now the Operations and Systems Analyst for Electronic Student Services, and take care of servers that host around 60% of campus web traffic and our student medical records, in addition to taking care of our home-grown Housing Management and Extra-Curricular Transcript softwares. We also develop and maintain the phpWebSite Content Management System, which is Free software. Check it out. The only reason I'm still on WordPress is that I haven't gotten around to writing the WP->phpWS importer yet.

8. Having a full-time position has taught me one thing: Despite loving what I do, when I get home from work, I'm usually quite ready to go out and do something else. Hence, the apparent death of Virtual Paper. It's really not a bad gig, though. I get to work on Free software all day, and all of our office machines in the department and the most of the servers themselves are Linux. As a professional sysadmin who does unfortunately have to deal with one Windows server... seriously, don't use Windows as a server. On the desktop... eh... but as a server, what a load of crap. PS, the views expressed in this blog do not necessarily reflect the views held by Appalachian State University or its employees, or the State of North Carolina.

7. I don't have a degree, but am still working on a BS in CS. Staff get a free class per semester (and one summer class), and so long as the supervisor approves (he does), we can take that time out of work without making it up. Pretty sweet gig. Was going to graduate this December, but it looks like another 3-4 years. Honestly, the one class per semester works a lot better for me anyway.

6. My new boss apparently reads my blog, or rather, read it through once and bugged me about why the hell I hadn't touched it in months. He's pretty much the most amazing boss anyone could have, and if I hadn't already known him and that I would have enjoyed being his peon, I don't think I would have taken the job. Also, he has little control over what I get paid, so this is all genuine.

5. The idea for Virtual Paper came to me after the 2006 Boston GNOME Summit. There, I met Boyd Timothy and a few other Tomboy hackers. I also hadn't owned a Tablet PC for very long at that time, and was enjoying getting to know about all the cool stuff it could do. I had a thought... what if you could draw a quick sketch or diagram right inline with your note about something?

4. At the 2007 Boston GNOME Summit, I met up with Boyd again. I pretty much spent the whole time trying to get what I had done on Virtual Paper embedded into a Tomboy note. Boyd helped significantly, and we were able to solve some more general problems in Tomboy with embedding images and widgets in the notes' TextView widget. I was all excited for a few days even after I got back in town, and then work took over my life again.

3. I think I'm finally starting to find a sort of balance and get used to the new lifestyle. Also, I've had an urge building up inside me as well as encouragement from friends to finish what I started. Not that software is ever finished, mind you, but at least work on it and be proud of it.

2. Virtual Paper is now in GNOME SVN as part of the Tomboy project, the Sketching Add-in. You will notice a severe regression in features; they're all still there, but they're not exposed in the UI yet. Any ideas? Also, at the moment, sketches do not save or reload as you close and open notes, thereby making them pretty useless. I need to talk to Boyd tomorrow about where they should be saved. But anyway, look at the pretty screenshot:

Also, you can check it out for yourself:

svn co http://svn.gnome.org/svn/tomboy/trunk tomboy

Sketching is not enabled by default; you will need to tell configure that you want it:

./autogen.sh --prefix=/usr --enable-sketching=yes


Update 2007-01-21: Forgot to mention; to add the widget into a note, from within any open note, click the Tools button and mash 'Add a sketch'. There is a default sized hard-coded, and you can't change that yet without recompiling. Perhaps I should add this to configure:

./configure --enable-sketching=yes --sketch-height=100 --sketch-width=100

Ok, seriously, just kidding there. We'll figure something out; like I said, it's pretty rough at the moment.

1. YOU can now benefit from it and contribute to it! The code is out there and public and readily accessible (see above). When I work on it, I'm working on it out of Tomboy's checkout, so any changes I make should make it in pretty quickly. Bugs should be filed against Tomboy in GNOME Bugzilla. I do still plan to release a standalone version, but for now I'm focusing on making the Tomboy addin useful, since I feel that it will benefit more people more quickly than focusing on a separate application.

Carelessness can kill efficiency. I mentioned in my last post that a Undo or Redo operation, after you get more than a few strokes on the page, takes quite a long time, upwards of a second or so. I immediately knew what the problem was: when I implemented Undo and Redo, they turned out to be so ridiculously simple that when they just worked I said "beer time" and that was that. They needed some more work, though.

Whenever Virtual Paper has to redraw the entire screen, it has to cycle through all of the strokes that have been drawn, and then re-draw them in order, including (now) any gradients^[1] involved. Here's the old, simple Undo code, and I won't post Redo since it's in SVN and is the same thing with a -- instead of a ++:

public void Undo()
{
    if(CanUndo) {
        undo++;
        QueueDraw();
    }
}

QueueDraw causes the entire canvas to be redrawn. This is inefficient because you don't need to draw the whole thing. The first problem I had to solve, and I haven't yet blogged on the intricacies of this problem that became very complex, was the fact that drawing the entire canvas each time a new stroke was drawn just took way too long after more than a very few strokes. Anyway, because that had already been solved, fixing Undo's inefficiency was still very simple:

public void Undo()
{
    if(CanUndo) {
        undo++;
 
        Stroke undoneStroke = strokes[strokes.Count - undo];
        QueuePaddedDrawArea(undoneStroke);
    }
}

A few more lines of code, and now you can write on that paper all day, click "undo," and it immediately deletes the last continuous stroke that you drew. Redo is almost identical in terms of code and performance improvement.

Other New Things

QueuePaddedDrawArea: There used to be some tiny glitches when drawing a stroke that were eluding me. It didn't always happen, but sometimes there would be a pixel or so missing out of the side of a stroke, and any total redraw would fix them, so I figured it had to do with clipping. Because there is a default line width of 3 pixels and because the boundaries of the stroke passed to Undo and Redo are in the middle of that 3px line, clicking Undo and *not* redrawing the whole window caused certain edges to remain, at least until the entire thing was redrawn. QueuePaddedDrawArea adds a padding of the current line width to the requested QueueDrawArea operation, which simultaneously solved the undo problem and the weird little glitches.

Paper Styles: are what I'm currently working on. It's turning out to take longer than expected, since I hard-coded a lot of reliance on the one style of notebook paper. Abstracting the background drawing out is looking to be time-consuming, but overall better for the quality of the code anyway. More on this as it's available.

Summer of Code: It officially started last week, so you should start to see more updates than usual on Virtual Paper. If you don't, please give me a swift kick in my ass to get me back on it so's I can get my much-needed dollars.

Subversion: Virtual Paper is being temporarily moved out of Ticklish SVN, partly so it can live with the other Mono SoC projects, and partly so I don't have to bother with WebDAV, which unfortunately doesn't play so nicely with Lighttpd. Anyway, if you want to get a more-or-less up-to-date copy of Virtual Paper, it is available from the mono-soc-207 project on Google Code. Here's a direct checout command you can use:

svn checkout http://mono-soc-2007.googlecode.com/svn/trunk/jeff/ virtual-paper-soc

Toshiba Tablet in Playboy June 2007: I indeed get it for the pretty girls, but also enjoy the articles, plus they give a great deal to college kids in hopes of getting us hooked for life. Anyway, on page 44 of this month's issue, they mention the Toshiba Portege R400, which is way nicer than my Portege M200. Somehow, in the description, they missed over the fact that the amazing Virtual Paper is being developed on a much older model of this fine hybrid tablet. I shall have to write them a letter.

[1]: That reminds me, I sort of hacked around my gradient problem. I was talking to Brad on IRC about it, just fleshing the problem out to another person and lamenting on how there doesn't seem to be a solution, when suddenly it hit me. I already have to apply a different color to each stroke section anyway to get the current non-gradient transition between colors. I also know that if you apply a linear gradient to a single line in Cairo, it works like you'd expect. So, for each line segment of a stroke, it takes the starting color and the ending color and makes a new gradient on that line. I haven't done any specific performance testing, but a quick bit of writing didn't feel any slower, and that's what's important. Also, Aaron is amazing at finding ways to break your software, and he only found a few small issues last time I saw him, none of which had to do with the new gradient code. So, that problem is more or less solved, although I feel like Cairo should have a better internal way to take care of that.

[1]: http://abock.org/2007/05/23/surfing-the-tubes/

So, this is annoying. Ever since I figured out how to get extended data from a stylus (pressure, tilt, etc) and actually implemented it, Virtual Paper has crashed due to an IndexOutOfRangeException if I try to use the actual mouse on it. At first I thought this had something to do with a button press event happening when using the mouse and not happening when using the stylus, or something. Whatever it was, I was more excited about getting pressure data than fixing this little bug, which seemed straightforward at the time.

This morning I decided to solve the problem real quick before heading over to my part time job at the university. As I should have expected, the problem has turned out to not be "real quick" at all. Now that I've gotten around to disabling that damned javascript rich text editor thing on WordPress, I can post some appropriately formatted code. This code is what decides to do with motion notification. If the motion comes from an InputSource.Pen, it makes a black Cairo.Color using the Pressure axis for an alpha channel. If it's not from a pen but is from a Button1, then we just put down 1.0 for the alpha, which is totally opaque. And finally, if it's either an InputSource.Eraser or from Button3, we make a big ol' mark that's the color of the current paper.

if(ev.Device.Source == InputSource.Pen) {
    strokeContinue(axes[0], axes[1], new Cairo.Color(0.0,0.0,0.0,axes[2]));
} else if(mask == ModifierType.Button1Mask) {
    strokeContinue(axes[0], axes[1], new Cairo.Color(0.0,0.0,0.0,1.0));
} else if(ev.Device.Source == InputSource.Eraser ||
          mask == ModifierType.Button3Mask) {
    strokeContinue(axes[0], axes[1], paperColor);
} else {
    // Unknown Button
}

Turns out, the problem is on line two above. If you click on the Handwriting widget with the regular mouse, ev.Device.Source is, in fact, InputSource.Pen! WTF? What's causing the IndexOutOfRangeException is the fact that the regular mouse does not have an axis[2], even though it is an InputSource.Pen.

Here's my new-and-improved device configuration code that picks which devices I want to hear from, with a Console.WriteLine added to help me get to the bottom of this:

foreach(Device d in GdkWindow.Display.ListDevices()) {
    Console.WriteLine("Device: {0}tSource: {1}t" +
            "Axes: {2}", d.Name, d.Source, d.NumAxes);
    if(((d.Source == InputSource.Pen ||
         d.Source == InputSource.Eraser) &&
        d.NumAxes > 2) ||
       d.Source == InputSource.Mouse) {
        d.SetMode(InputMode.Screen);
    }
}

And here is the output:

Device: eraser          Source: Eraser  Axes: 6
Device: stylus          Source: Pen     Axes: 6
Device: cursor          Source: Cursor  Axes: 6
Device: Synaptics       Source: Pen     Axes: 2
Device: Core Pointer    Source: Mouse   Axes: 2

I added some spaces in there to make it look nicer. As you can see: Synaptics, my touchpad device, shows up as a Pen. So, the other changes in the above configuration code are there to make sure any Pen or Eraser has more than two axes, and accept a mouse regardless.

Now drawing with the mouse doesn't crash it... it just doesn't work!! Yep, the Core Pointer now refuses to send a Motion Notify event. I tried hooking up a USB mouse and found an even more puzzling bug; it doesn't show up at all. It doesn't add anything to the above list of devices (didn't figure it would), and more bizaarely, it does not send any motion notify or button events to the widget, even if all the conditionals are removed and every device is configured as screen relative. Am I looking in the wrong place here? I think this issue requires a better understanding of X, which I do not have much of. Any input would be appreciated.

For now, this code in the motion notify handler does a good enough job, but it still doesn't solve the problem of an external mouse, and it feels kind of hackish:

if(ev.Device.Source == InputSource.Pen) {
    if(ev.Device.NumAxes > 2) {
        strokeContinue(axes[0], axes[1], new Cairo.Color(0.0,0.0,0.0,axes[2]));
    } else {
        strokeContinue(axes[0], axes[1], new Cairo.Color(0.0,0.0,0.0,1.0));
    }
} else if(ev.Device.Source == InputSource.Eraser ||
          mask == ModifierType.Button3Mask) {
    strokeContinue(axes[0], axes[1], paperColor);
} else {
    // Unknown Button
}

My last post was written rather hastily, and the Lazy Web indeed noticed some silly mistakes; for one thing, the || operator makes 'if' statements much smaller, and the code that configures your GdkWindow.Devices should be handled on Realize, not on Configure.

I was also rather ambiguous as to what I meant about applying a gradient to a stroke (as opposed to a fill). Yes, it is possible, and quite straightforward:

Code for that is available here.

Cairo gives you a radial gradient and a linear gradient for free. The gradient, however, is applied to the image as a whole. What I want to be able to do is draw a stroke and have the gradient be applied along the path of the stroke itself, rather than what you see in the above screenshot. So, if I set a black color stop at 0.0 and a red color stop at 1.0 (as I did above), I would want the black to start at the top-left corner of the square, and change to red along the path itself, ending as red back where it started in the top-left. If I fill that square using the same linear gradient, you can see what is actually happening:

Anyway, just because I wanted to see pressure-sensitive results in Virtual Paper, I reworked the stroke drawing code to stroke for each line segment with the color (pressure) of that line segment. It actually looks really nice, and doesn't slow down like I was afraid it would:

This screenshot shows why I'd like to be able to apply a gradient to a stroke. Fortunately, it also shows that the results without a gradient are still pretty spectacular:

Since it looks decent without gradients and the performance doesn't take any noticeable hit with extra calls to Stroke() (and am I insane for thinking there would be a noticeable hit?), this one will be on the back burner for a little while.  It'll become important again for things like SVG export, since you want to actually have a scalable vector graphic and not a bunch of line segments that don't flow with each other.

That was easy enough, just not very well documented. You have to, for your Gdk.Window, tell it what devices to listen from. By default you get the CorePointer, you have to do more work if you want Pen and Eraser. Also, this is how you specify Screen-relative or Window-relative.

For those not familiar with Wacom devices: if you are working in a program such as The GIMP, what you probably want is the ability to use the full range of your wacom device as a canvas, instead of being limited to the area where your drawing window would be. So, you set the device to be window-relative instead of screen relative, and bam. That's not useful for a TabletPC where you're literally drawing with your display in the background, so we'll assume screen-relative for Virtual Paper.

Here's the code that makes it work, and it's executed upon Configure event. DEAR LAZYWEB: is there a better place I should put this code instead of the confgure event? It has to happen *after* the window is shown, but I don't think it needs to happen more than once.