I cannot say enough about Spiro in the Inkscape development releases. If you are a die hard Inkscaper then this is a must try. You’ll never want to use standard bezier paths and tweak them ever again. Drawing paths with this new functionality is so much fun, especially now that we can use a shape copied to the clipboard as a brush. Thinking what I’m thinking? Many many possibilities indeed. 
10-15 minute doodle:
Episode 065 is up. In this one I create some LCD digits from scratch and demonstrate the use of grids and grid snapping along the way.
I really thought this one would be short. But somehow it managed to get to the 17 or 18 minute mark. These things always end up being longer than they feel when you record them. How did I ever do one in under 10 minutes?? 
Alright…this is going to be a little rough and not quite as thorough as I would like but I wanted to document it now while it was fresh in my mind. After visiting this site and this site I was able to cobble some steps together to build a debian package of a recent Inkscape development release for Ubuntu Hardy. This may not work for everyone but it worked for me and I was able to use the deb package on a newly installed version of Ubuntu Hardy to make sure it worked.
Here are the steps that I took:
1.) Install the necessary packages to build Inkscape (some tools may not be needed)
sudo apt-get install autotools-dev fakeroot dh-make build-essential autoconf automake intltool libglib2.0-dev libpng12-dev libgc-dev libfreetype6-dev liblcms1-dev libgtkmm-2.4-dev libxslt1-dev libboost-dev libpopt-dev libgsl0ldbl libgsl0-dev libgsl0-dbg libgnome-vfsmm-2.6-dev libssl-dev libmagick++9-dev libwpg-dev
2.) Download a recent devel tarball from Inkscape Subversion Snapshots
save inkscape-XXXXX.tar.bz2 to /home/user dir.
3.) Untar inkscape-XXXXX.tar.bz2 to /home/user. This will make a new dir called inkscape-XXXX
4.) Make the debian control files:
dh_make --createorig
Pick Single for single binary
Fill in any extra information like maintainer and version
5.) Run the following:
dpkg-buildpackage -rfakeroot
If everything goes as planned and after a long wait you should get:
inkscape_XXXXXX-1_i386.deb in your /home/user dir.
I haven’t yet figured out how to install this package or prepare it to run along side the stable 0.46 release. If anyone knows how then please give me a jingle.
Here’s my deb package of Inkscape 0.46+devel revision 19107, July 2, 2008:
Use it at your own risk and don’t bitch at me if it doesn’t work. You can always uninstall it and go back to the stable release. I am really looking forward to Inkscape 0.47. They are woring on some really neat features like Spiro, Live Path Effects and Filter Effects. Check it out.
By the way, this was my first deb package. I didn’t adhere to the Debian package standards.
Some time ago I blogged about compiling Inkscape on Windows. Guess what? I couldn’t do it. :( I tried over and over again on several occasions and I just couldn’t get it to compile. I gave up on it and just resorted to the compiled version that was already compiled for us and ready to download.
I was still interesting in the black art of compiling Inkscape though. This time I turned to my trusty Ubuntu Hardy desktop at home. I got all of the dependencies installed (I think…can never be too sure) and away I went. Unfortunately it errored out during the make command. I tried only a couple of times after that and still nothing. I failed again.
This morning when I got into work I felt that itch to try and compile Inkscape again. Until I can compile it successfully it’s going to keep bothering me. So I VNC’ed into my Ubuntu Hardy file server (it’s just light duty server…nothing I couldn’t fix if I broke it) and installed all of the dependencies. I pretty much followed the Inkscape/Ubuntu Hardy compiling instructions from the Inkscape wiki ,only changing a few things. This time I was successful. Hooray! 
The only problem that I had was that I could not build a deb package with checkinstall command. I did a standard make install instead and sent it to a different directory so that I could use both the stable build and the SVN build (19107).
My only question is if it’s possible to copy or transfer my the install (compiled package) to another Ubuntu Hardy PC…like to my home desktop. Had I been able to make the deb package then this would have been awesome but I wasn’t able to. I would love to give this to other Ubuntu Hardy users who are interested in taking a look at the new features. Unfortunately, I’m a packaging noob.
I finally got around to downloading the avi file for Episode 064 and took a look (wanted compare the intro smoothness with ep063) and immediately noticed that I encoded it to the incorrect resolution.
Clearly I am an idiot. But don’t tell anyone.
It is encoded to 912×864 instead of 912×684 which it was recorded at. Consequently, it is vertically stretched. ie. circles look like vertical ellipses.
Properly encoded avi file will replace the retarded one later tonight.
I should have known things went a little too smoothly.
I blame Richard.. er.. wait a second…
Episode 064 is now up. This screencast demonstrates the use of Inkscape’s Object->Clip->Set function for some creative bitmap masking. This idea came from David Hernandez who emailed us about the idea. Thanks David!
The intro to this one is kinda mellow. The leaf image I use in the intro comes (I think) from a wallpaper set released with one of the first KDE4 betas. After post-processing of the videos I’m also not sure whether those leaves are maple leaves or not. My bad, with it being Canada Day tomorrow.. and me being Canadian. I should know these things. If there are any arborists out there that can set the record straight, feel free.
Also, in keeping with heathenx’s mini.. er.. micro fumble towards the end of his last screencast, I had a hell of a time moving the rotation point at about the 11 minute mark. Tried 5 or 6 times, and finally it took. Any screencaster worth his salt would have scrapped it, but hey, here at Screencasters we fly by the seat of our pants. - like you couldn’t tell.
Mr. Don Waters threatened me if I didn’t get another screencast out soon, so here it is, Episode 063. Happy, Don?
I gathered up a few tips from a very sharp individual called Rob Antonishen for this tutorial. I think Rob was a little more thorough (Wait! I know he was) in his tutorial than I was in mine. I moved pretty quickly just so that I could finish the screencast and get back to being a father to my needy kids. Oh well. You are pretty forgiving when it comes to my screencasts anyway…right?
Speaking of forgiving…I duffed it pretty badly in this episode without getting a mulligan. Find the 12:20 mark in the video. It’s amusing. That’s when my kids walked in on me while I was recording and I lost my train of thought for a moment (Thankfully I wasn’t recording in the nude this time). It’s a real Porky Pig moment where I couldn’t spit out what I wanted to say so I said something else (and didn’t make sense after I said it.) Oh boy. I didn’t have the passion to re-record it either so you get what you get I guess. I asked myself what Richard would do in a case like this and what advice he would give me. Ah, he would tell me to go for it and post it anyway…mistakes and all…so I did. I blame Richard and you should too.
Try to enjoy it.
Mr. Jon Cruz, one of the brilliant minds developing for Inkscape has fixed a problem that has hounded Richard and I from the beginning of the Screencasters…limited window sizes for smaller resolutions.
Currently, there is a verticle limit in which Inkscape can be scaled to. This varies depending on operating system and/or Linux desktop manager. The Screencasters would love to go back to 800×600 video but it has been hard for us to do that because we have to record at a larger Inkscape window size and then scale down during our encoding process reducing the quality of the video. To help with this we had to increase our Inkscape window size to 912×684 and then try to encode at that same size. This has made our file sizes a little larger but we feel we have little choice in the matter.
Anyway, Jon has fixed this problem and it will most likely hit a future Inkscape release. Have a read over on his blog to get a fuller understanding.
Awesome work, Jon! I’m very excited about this.
Alright. We have brought the voting to a close. Only 60+ people cared to vote. That’s a small turnout, although, that isn’t a bad thing. It just tells us that most people didn’t care what format we put our videos in and maybe chose not to vote…or maybe we only have 60+ viewers. Or maybe they were in prison and didn’t have access to a computer. Or maybe they were on safari and were running from the lions after their vehicle broke down. Or maybe Scut Farkus and Grover Dill had captured them on the way home from school. Or maybe…ah…nevermind. Whatever the reason I think Richard and I gathered enough information to make a decision.
It looked like this thing was going to swing MP4 at the start of the poll but enough of you were concerned about that container due to it’s larger file size and perhaps because that format was harder for some of you to re-encode into something else. Typically, MP4’s are smaller than comparable AVI’s but since we could not encode them the same way as our AVI files, due to iTunes/Quicktime compatibility, we had to throw out the b-frames which increased the size of the file.
I think Richard and I leaned on MP4’s for several reasons which we think are still valid. We may want to revisit this issue again in the future when some things mature a little more. I think if we can tackle file size and actually get them lower next time then maybe it will give everyone more of an incentive to switch to this format. As far as re-encoding MP4’s into something else, Richard and I aren’t masters but we know our way around encoding video (thanks to our friends in the community) and we can always lend a hand if that’s what some of you need.
In the meantime we are back to making AVI’s with H.264 video and MP3 audio for download and FLV’s for streaming. That’s what you have asked for and that’s what we’ll continue to deliver. Thank-you for helping us with our experiment. We appreciated your feedback. The links on our last blog post will remain so that the curious can experiment. However, we will be changing episode 062 from MP4 to AVI on our episode page. Everything will be back to normal soon.
In the words of Officer Barbrady, “Move along people, there’s nothing to see here.”
Richard and I have been mulling over the use of MP4’s for the last couple of weeks now. More so than we have in the past. We think now that we can finally do this but only if our current viewers are ok with it. We have all gotten used to the present AVI/FLV format that we have had for the last 61 episodes and we don’t want to ruin anything by changing.
Several of our viewers inquired about adding Screencasters’ videos to the iTunes store some time ago. We looked into it at the time and found that our present AVI (h.264.mp3) files were not compatible with iTunes. We looked at the requirements and found that our videos needed to be in MP4 (h.264/aac) instead. We felt that we could not quite achieve this since it wasn’t an efficient process for us. In addition, the flash plug-in and the flash player that we had was unable to support MP4 streaming video fully. What Richard and I were truly interested in was using the same MP4 for download and streaming so that we did not have to encode and upload multiple MP4’s. We would then eliminate the the separate AVI and FLV files that we were encoding. It would be nice to consolidate and use only one file as a general purpose file. We could encode with fewer steps, meaning that it wouldn’t take us as long to make the final video and we would only have to upload a single video to our server. Moreover, the larger MP4 file size still would be smaller than the combined file sizes of the AVI and FLV, meaning less room on our server as well. Although, you must be warned that the MP4 file will be 30-40% larger than the AVI equivalent. This is due to the limitation that iTunes/Quicktime has with b-frame video files. It is our understanding that we have to remove all b-frames from the MP4’s in order to reach full compatibility. Adding b-frames to our AVI’s was something that we did to keep the file size lower. So for you folks on slower Internet connections, it will take a little longer to download the MP4, whether it be the download or streaming file. Of course we’re no iTunes/Quicktime experts. So if we can make improvements with our file sizes in the future then we will absolutely do it. We like as small file sizes as we can get them. Plus, if some of you are experts in this area then we will listen to any advice that you can offer us.
All of this sounds good and makes sense to us but there are some things that Richard and I are worried about. You! We need your feedback. We still intend to offer a download file for off line viewing and a streaming file for on line viewing (even though technically there is no difference between the two in terms of the actual file). That will remain the same. The only difference is that the file format will change. During our testing, we found that this wasn’t an issue on our Linux and Windows computers. We can watch MP4’s with VLC, Mplayer, and Quicktime/iTunes among many other players that we have. We would be changing from the MP3 to the AAC audio codec though since that is needed for iTunes/Quicktime compatibility. I think we would prefer working with MP3’s but I’m sure we’ll get used to AAC over time.
Also, we verified that our new MP4’s will play on a MAC. Thanks to Richard’s good pal, Earl Moore (dedicated Mac user). Furthermore, I fired up iTunes on my Windows machine, verified iTunes playback, and then let iTunes convert our MP4 at 912×684 resolution to iPod format and synced that to my iPod. It played and sounded great. Although, the screen size is small so we do not recommend that method for watching our videos…but what the hell, right? We’re not going to tell you what you can or cannot do with your devices. If that sort of thing is what you want to do then do it and be happy about it.
We would also be including meta tags in the MP4’s. It isn’t necessary (we don’t think) but it looks nicer in iTunes and with then you’ll be able to sort our videos a little better. So for you iTunes and iPod users please let us know how our MP4 works on your computer.
As far as Miro is concerned, we haven’t forgotten about that. We’re pretty sure nothing will change there. I subscribe to Meet the Gimp with Miro and Rolf’s files are already in the MP4 iTunes compatible format so I’m using that as my gauge. If it works for him then it should work for us (crossing fingers), right?. We’re hoping that no disruptions will be had.
Unfortunately, Richard and I have decided not to re-encode videos already in the AVI format. We think it’s way too much work for us and that’s why MP4’s are only for going forward. However, we may decide to encode the last few episodes just to get a few more videos on the iTunes store. You viewers can re-encode our AVI’s anyway that you wish if needed. We’re somewhat sorry about that but what can you expect from us? We’re not Revision3…that’s for sure.
So that’s it folks. Please tell us what you think. We would like to get a response from you. Please remember, iTunes is just another way to grab our videos. Nothing in terms of distribution on our website will change. RSS will still be the same. If you use iTunes (or Miro) then fine but it isn’t necessary. We are just giving our viewers and future viewers another option. Richard and I are not iTunes users so we are not doing this for ourselves. We’re doing this for you. There is a poll at the bottom of this post. Please fill it in and submit it to make your voices heard.
Our latest episode, ep062, has already been encoded into the MP4 format. We will use this as our prototype for testing. Please view this video the way that you have always viewed our videos, either by downloading the file or watching it on line. Hopefully, everything will work the same as did before.
Good luck and may the force be with you.
Download: ep062.mp4 (Filesize: 146MB)
Streaming: ep062.mp4 (Identical file as above)
