Xiph.org now has a Planet.
If you work for a government that owns any, or work with them, please submit a request for the source code under the GPL. If that doesn't work, try the AFPL (for older versions). Let us know how it goes?
Terminal titles and line wrap
On a couple of remote systems, I've been annoyed by line wrap problems in the terminal. As in command lines would wrap at a strange place, and then cursor movement is all messed up, and I'd have to count (not look) when editing a line.
Today I finally figured out what was going on: prompt version skew!
On those particular systems, I'd at some point set my prompt to put the hostname and cwd into title bar of the local terminal application. I was using an invocation like PS1='\u@\h:\w\$ \e]2;\u@\H \w\a'. To set the prompt to username@host:cwd$ on the command line, and something similar in the title.
But looking at the faq this morning, I noticed it lists \[ and \] as quoting non-printing characters. I thought hmm...and added them around the xterm escape sequence. Sure enough, the problems went away.
I swear this used to work, but apparently now the terminal somehow counts the non-printing characters when calculating line lengths, and the square bracket quoting makes it not do that. Some kind of hack for i18n?
Most recipes suggest \033]2;<title goes here>\007 for setting the title, but bash supports \e for the escape character and \a for the bell, which delimit the xterm controls. You can also use \$ for a prompt character that switches based on whether you're root. So a less noisy suggestion is something like:
if [ "$PS1" ]; then if [ "$BASH" ]; then PS1='\u@\h:\w\$ \[\e]2;\u@\H\a]' else if [ "`id -u`" -eq 0 ]; then PS1='# ' else PS1='$ ' fi fi fi
In other news, setting the "Delete key sends backspace" option on the MacOS X terminial no longer seems to be necessary for reasonable remote editing, which is nice because it makes backspace not work at all on local apps. fn-delete for delete-char-right (delete instead on backspace on US keyboards in linux) still doesn't work locally though.
Careful with that --aspect
I've talked to several people on IRC recently about getting the proper aspect ratio when encoding theora video, and wanted to summarize here.
The short answer is, when you're encoding from DV (or most other formats) with ffmpeg2theora don't use the --aspect switch. The program will calculate the correct aspect ratio based on the source and whatever target resolution you give it, either through a -p profile or explicit -x -y switches.
The --aspect switch is for overriding the default calcuation, usually because the input source video is incorrectly marked. But video aspect ratios are confusing, and it's easy to mess up. For example, if you take a DV source video and encode with -x 320 -y 240 --aspect 4:3, you will get a video that says its pixels are square, but in fact they are not, so playback will be distorted. Without the --aspect switch, ffmpeg2theora will mark the file with the correct (non-4:3) aspect ratio.
Huh? 320x240 is 4:3! Yes. DV, whose native resolution is 720x480 (NTSCish) or 720x576 (PALish) contains some overscan area, and so the full frame is not a 4:3 image. It roughly contains one, and the theory is the extra bits get masked off by the edges of your CRT. Computers have nice, square pixels, so everything is much easier, but digital video imports a lot of the complexity of the analog technology it developed from, and had to interoperate with.
Since the full DV frame isn't actually 4:3--or 16:9 if you're shooting in wide screen--you have to crop if you want to make an actual, standard ratio, square pixel file.
ffmpeg2theora -x 320 -y 240 --cropleft 8 --cropright 8 -o output.ogg input.dvwill give you square pixels with a 4:3 frame aspect ratio.
For 16:9, use something like:
ffmpeg2theora -x 640 -y 360 --cropleft 8 --cropright 8 -o widescreen.ogg widescreen.dv
The same thing goes for the --deinterlace flag. It forces using the deinterlace filter regardless of whether the input is marked as interlaced or not, and so can degrade quality on progressive material. DV is a very sane format and all of these things are reliably marked. In general, trust the defaults.
GPL Ghostscript 8.57
We've released Ghostscrpt 8.57. This one came much sooner than usual after the previous release, but still not as long as we wanted.
The good news is that having drawn a line under recent work, we're now merging the CUPS support and various distro patches from the ESP Ghostscript fork. Thanks to Till Kamppeter, who has been sorting the patches. This is the next step, after moving to a GPL development tree, toward shipping a single, up-to-date version of Ghostscript in linux distributions.
If you're interested in helping out, you can get the work-in-progress from
While in Montréal for LGM 2007 we went to see a screening of the new documentary film Helvetica, about the typeface. It was entertaining, and I learned a lot, so definitely check it out if you have a chance. The director said DVDs should be for sale in September.
There are a number of famous designers in the film. in the Q&A afterward, the director Gary Hustwit said it was surprisingly easy to get interviews, perhaps because no one has really made a documentary about type, or even much about graphic design before. It made me think more of us should be documenting the history of the open source community.
Also (unintentionally) amusing was the director's answer to the question "How do you feel about people file sharing your film?" He acknowledged that it would probably happen, but had to say (he works for a company that makes DVDs) that he's not ok with it. He then went on to say that he could see it being ok for music, because the experience of listening to music on your computer is about the same as listening to a CD, but he wants us to see the film on a big screen, with other people, like we were doing that night. To help frame this, he had also said earlier that the soundtrack of the film was essentially his ipod playlist from the time he conceived the documentary.
So, like the font, the documentary is non-free.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!