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.psWow, 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.psStill 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?
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=100Ok, 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.