Some memories from Slovak Paradise

Although I didn't originaly intended to blog about my vacation at the begining of August in Slovak Pradise, today I decided some photos and memories might be worth sharing with the world ;-) So this post will be mostly images with short commentary...

Being Czech, going to Slovak Paradise means traveling about a half a day by car. And there are two important things when you travel - your friends and enough food :-D

Now, what would I expect from vacation? I like hiking - so mountains, forests, rocks, rivers - in short beautiful nature. And here's one of the shots from our first daylong trip:
We did a wrong estimate for the first day and so in the second part of the trip, we began to be pretty exhausted (and thirsty), but still we hoped to achieve what we wanted and progressed steadily up - until we lost the marks :-D Well, about a hour later, we met the marks again, but we accidentally avoided the destination of our trip - a huge rock on a top of a mountain. Since we had some time still, we decided to go up - which was a good choice. After some endless ascent, we finally reached the bottom of the rock:We decided to give it a try and after another five or ten minutes of climbing, we arrived at the top and had a short break.


The rock was freakingly high, as everything beyond its edge seemed terribly deep bellow us. On the photo it does not look that much terrifying though...
Because we exhausted ourselves on the first day, the second day we went on a rather refreshing sightseeing - to Spišský hrad (castle). It was pretty big I'd say and it was pretty interesting day.Our best trip was however another day. It was another daylong (bag-laden) trip to Údolí Suché Bělé (I'd translate it, unskillfully, to English as Dry White Valley). There were lots of waterfalls, ladders and chains so it was also fun. I think the photos speak for themselves...

However, as all nearly-horizontal ladders were made of wood, it was not uncommon to have been broken here and there...
And this is what happens when you let your guard down - your friends will take it as an opportunity to take a photo of your supposedly sleeping self :-D
Well and that's all for this post. I tried my hardest to select the best images from the set we brought back with us from there ;-)

Echo August 2008 News

New Icons

We've created/fixed some new icons, concretely:

• preferences-system-date


• preferences-system-firewall


• preferences-system-users


• printer

All of them are used in they System -> Administration menu and part of our work towards filling this menu with Echo icons (since most of applications in there don't have even new-gnome-styled icons).

"Huge" icons - 256x256

With the introduction of One Canvas Workflow (will be explained bellow) I decided I could try doing more detailed and realistic looking version of the printer icon:

Nicu was seemingly pleasured with the new introduced HW brand - Echo and noted that if such device indeed existed it would definitely worked with Fedora out of box.

I'd like to hear others opinion of using such style for these icons. The basic differences from other styles are semitransparent borders (usually with opacity set to 0.3) and more detail. Other than that it remains same as other sizes. If we agree on this style, I'll add it to Guidelines, together with source for the echo brand ;-)

One Canvas Work-flow

Together with creating the printer icon, I explored jimmac's idea of one canvas workflow. In my short experience it is superior work-flow to our current one and also makes automating many steps of icon creation easier. Most importantly it helps artist to focus more on the process of designing/drawing the icon rather than various "secretary" jobs around...

Together with the desire to automate as much of the secondary work as possible I needed to bring the work-flow to yet another level - so you need to add label to the 48x48 icon (which therefore needs to be
grouped) and set it to scalable. It is so that the script can recognize that it's the very icon intended to be installed into the scalable folders (and delete the rest).

Initial screen-cast showing this and subsequent commit of the icon to git is available at my fedorapeople page.

I'd like to make this work-flow the preferred one for echo-icon-theme creation so if no one steps in, I'll add it to Guidelines.

Current version of template which can be used as base in Inkscape to create icons using this work-flow is attached to a mail I sent to fedora-art-list.

Automating The Secondary Jobs

One Canvas work-flow makes one thing much easier - ability to create script which takes the source icon and add it to git repository. I called this script echo-add-icon and it's already available in echo git repository. It takes the source SVG, generates PNGs for all included sizes and SVG for the scalable "size" and put all, including source into their rightful places in the git repository. The original source is put into /sources/base/one-canvas/ to make it distinct from the legacy sources (i.e. one source SVG per one size). It currently pushes only to base folders, but can be easily extended to ask if we want to push to base or to extras.

It does not make branch specific changes (i.e. adding symlinks / adding to build system) but I hope to implement it as well in some future version of the script. It also does not push the changes back to fh.o only prints a message to the user that he should do so.

Another script is meant to simplify the git set up process. I called it echo-set-up and is also uploaded to git. It does all the steps needed for starting work with the repository.

Yet another script is make for updates (useful e.g. when we introduce new branch to echo git repo). It updates all branches, if some of the branches is missing, it correctly creates it. I called it echo-update and it's also available in echo git.

I also plan to add one another simple script, probably called echo-new-icon that would take latest version of the one-canvas template and create new icon (with given name) from it. Similar to what rpmdev-newspec do for spec files ;-)

I plan to package these scripts for fedora under the name echo-artist, therefore I added some necessary things like license (LGPLv2.1+) or credits (since the first script is based off jimmac's).

Echo for F10?

It has been briefly discussed on the fedora art list whether to include Echo in F10 as our default icon theme and whether submit it as a Feature. Many people seemed to agree that it would not hurt pinging fesco about it, but that the main decision would probably be done by Art and Desktop teams.

Further Plans

Apart from creating new icons and plans mentioned above, I also hope to update/extend various echo related how-to's to reflect the new methods of echo icon creation/addition.

Apart from that I'd like to make some "promo" page that would be intended for potential contributors and contained all info they need to know to get started and other similar info.

Request for Feedback

As usual, I am more than open for all kinds of feedback, especially about the huge size guidelines, the new scripts and one canvas work-flow. If you have ideas how to further improve some of the above mentioned things, or just comments to what I said, would like to start contributing to Echo, ... feel free to reply either here, in comments, drop a mail in fedora-art-list, or, if you wish, drop a private e-mail to me (you can use e.g. the fedora address: mso AT fedora project DOT org [note: the address is "obfuscated" as a spam prevention and there are not any spaces in the original]) :)

Echo, Nodoka, One Canvas, Ruby and New Fedora Certs

It's been some time since my last post, so several things pilled up since then I'd like to talk about. So first about Echo, One Canvas and Ruby.

We ought to keep up with latest technology and make the process of creating new Echo icons as easy/effective as possible. As already mentioned in the fedora-art-list there is a new workflow of creating the icons - One Canvas Workflow. As the name suggests, it means that you create all the icon sizes from 16x16 to 256x256 in one file. It has the obvious advantage of possibility of all the icons sharing the same gradients, direct comparison, ... The question is, how to make all the required PNGs from the one canvas SVG. Jimmac has an answer.

Basically the workflow means that you use some inkscape features like layer functionality (you can display/hide layer editor via ctrl+shift+L) or object labeling. First you need to have two layers - one supporting for the script that will generate the PNGs later, and one with the actual artwork. The supportive one needs to be named 'plate', the artwork one 'artwork' (required by the script). On the plate you draw squares with the desired icon sizes (from 16x16 to 256x256) and distribute them in the canvas so that 22x22 and 24x24 are used for the same image and the others are separate. In the artwork layer you just draw the icons over the prepared squares in the plate layer. It's good thing to lock the plate layer to avoid accidental drawing to it.

Finaly group the separate icons into separate groups (one group for one icon) and because we need to know where the icon gets installed to, add Description = (substitute with e.g. devices for printer icon) to Document Metadata.

Now that would be enough to generate all the PNGs, as is done in Jimmac's ruby script. But in Echo Icon Theme we also distribute Scalable images (SVGs). So I needed to extend the script to generate the desired SVG as well. First it needs to somehow identify what will be erased from the source SVGs and where the rest will be moved to. I decided that best way is to use inkscape's labeling functions. So select the icon artwork intended for the SVG (usually the 48x48 one), it needs to be one group, select obejct properties [ctrl+shift+o] and set Label to scalable. Do the same for the rectangle bellow in the plate layer (that's needed to reposition the icon).

Now, to the script. First I decided we need only the one icon variant, so I dropped the code iterating through all icons. Next I needed to somehow edit the SVG to remove all unnecessary objects change the canvas size and correctly place the scalable icon on it. Since I had never done anything in ruby up until yesterday it proved a rather long job, but finally, after about 4 hours of experimenting, reading REXML docs and googling, I've managed to put together working script. I am not sure though if it's written correctly, since I don't know how memory is allocated/freed in ruby, know practicaly nothing about ruby syntax, ... Anyway here's the code:

#!/usr/bin/env ruby

require "rexml/document"
require "ftools"
include REXML
INKSCAPE = '/usr/bin/inkscape'
SRC = "./svg"

def renderit(file)
svg = Document.new(File.new("#{SRC}/#{file}", 'r'))
context = svg.root.elements['//dc:description'].text
svg.root.each_element("//g[@inkscape:label='plate']/rect") do |icon|
dir = "#{icon.attributes['width']}x#{icon.attributes['height']}/#{context}"
cmd = "#{INKSCAPE} -i #{icon.attributes['id']} -e #{dir}/#{file.gsub(/\.svg$/,'.png')} #{SRC}/#{file} > /dev/null 2>&1"
File.makedirs(dir) unless File.exists?(dir)
system(cmd)
print "."
#puts cmd
end
end

def expungeit(file)
svg = Document.new(File.new("#{SRC}/#{file}"), 'r')
context = svg.root.elements['//dc:description'].text
plate = svg.root.elements["//g[@inkscape:label='plate']/rect[@inkscape:label='scalable']"]
x = plate.attributes['x']
y = plate.attributes['y']
artwork = svg.root.elements["//g[@inkscape:label='artwork']/g[@inkscape:label='scalable']"]
translate = "translate(-#{x},-#{y})"
artwork.add_attribute(Attribute.new('transform', translate))
canvas = svg.root.elements["/svg"]
canvas.add_attribute(Attribute.new('width', '48'))
canvas.add_attribute(Attribute.new('height', '48'))
plate = svg.root.elements["//g[@inkscape:label='plate']"]
plate.elements.delete_all('')
svg.root.each_element("//g[@inkscape:label='artwork']/*") do |icon|
label = icon.attributes['inkscape:label']
if (label != 'scalable')
icon.parent.delete_element(icon)
end
end
dir = "Scalable/#{context}"
File.makedirs(dir) unless File.exists?(dir)
f = File.open("Scalable/#{context}/#{file}","w")
svg.write(f, -1, false)
f.close
cmd = "#{INKSCAPE} --vacuum-defs -l Scalable/#{context}/#{file} -f Scalable/#{context}/#{file}"
system(cmd)
end


file = "#{ARGV[0]}.svg"
if (File.exists?("#{SRC}/#{file}"))
renderit(file)
puts "\nRendered PNGs from #{SRC}/#{file}"
expungeit(file)
puts "\nCreated scalable SVG icon from #{SRC}/#{file}"
else
puts "[E] No such file (#{file})"
end


And here's the image (google accepts only PNG, but SVG is available on my fedorapeople page):


Next thing I have in mind are Nodoka improvements. I've done some further coding and improved the button rendering and added styled entry rendering. Even those two are still not complete, let alone the rest, but the progress is here. See in the following images.






And finally some words about new fedora cerificates. I had some problems with it like not being able to log into koji web interface or not being able to upload new sources for RPMs. It turned out that my user certificate was generated too early, still in the time when the problems with infrastructure were ongoing (kudos to infra guys for fixing it). So after the reason was discovered I am finally able to do all my work I do in Fedora.

That also means I updated subttitleeditor. Please test and report if it works for you. The update for F8 is here
https://admin.fedoraproject.org/updates/subtitleeditor-0.22.3-1.fc8

and for F9 here
https://admin.fedoraproject.org/updates/subtitleeditor-0.22.3-1.fc9

oggvideotools - Thanks for That Package!

In my previous post I outlined some ways that could lead to good screen-cast. One of the biggest issues I have had have been that the gtk-recordMyDesktop output contained skeleton track which rendered that file nearly uneditable. I tried various magic with mencoder to be finally able to extract the theora video into something other, something that can be processed by mkvmerge. It could not be however played by totem. And the same was with the result mkv.

But not anymore. Recently, when checking mail, I noticed in fedora-extras-commits list interesting package - oggvideotools. And now, at the end of my wits, I remembered it, looked into the archives to find that it's actually a new package and have been built on Tuesday. So I downloaded the package from koji (I didn't checked whether it's already in repos), installed it and looked on the content. One of the binaries caught my attention: oggSplit. I wondered how it's used, but as traditional -help or --help or man didn't worked and the program homepage showed only what it does but not how it does, I tried feeding it one of the ogv files.

The result is rather pleasing. It generated two ogg files, one named theora-[some-probably-hex-number].ogg and named unknown-[another-number].ogg. And voila, the theora-*.ogg one works, mkvmerge with it works, ... COOOOL. The unknown-*.ogg probably contains the skeleton track and I'll delete it right away. It's also probably result of this oggSplit output:
unknown type ID 325334135

So, I can safely say that I can do a high-quality screen-cast in matroska file with theora video, now :-)

Making Good Screen-casts - How To?

I am gradually making some screen-casts for echo tutorials and I wonder what is the best way to make them. There is a lot of options and one needs to choose... What I've done so far is available on my Fedora People page.

First thing to choose is the application that will do the actual screencast. From rough investigation I discovered these three that are available in fedora/livna:

• instanbul - easy to use, however almost non-existant configuration, output compressed terribly much, which makes the video small but ugly
• xvidcap - configuration options are pretty good, you can customize the output as much as you want, however tend to freeze during captioning, also does not support encoding to theora
• gtk-recordMyDesktop - seems to support output only to ogv/theora/vorbis, not very well handled area selection, adds skeleton track to the output, usage not very intuitive

So after some thinking I dismissed instanbul, as the output does not have the desired quality (and I cannot do anything about that) and xvidcap due to frequent freezes (before that I managed to record one 3 min long screencast though). That leaves gtk-recordMyDesktop.

Next, we need to decide about the content - will we add commentary? If yes, will it be spoken or via subtitles? Subtitles are very good for translating, you just use the original one and use e.g. subtitleeditor (in fedora repos) to make a translation without changing the subtitles timing/styling. Also it's good for deaf people. On the other hand, you need to show the subtitles somewhere, which might render the part of screen on which they are shown unreadable. You can minimize the costs by using styled subs (e.g. ASS/SSA) to position the subtitles, but you'll then need special programs that can handle the styling (e.g. mplayer with -ass option).

Audio has the drawback that it can be hard to understand, for the person doing the screencast harder to create (not all of us are good English speakers), also it's harder to make a translation. So I guess subtitles are overally a better choice.

Now what format choose for video? If I had a choice, I'd go with MPEG-4/AVC (H264) which is excelent format with probably the best quality to compression ratio (and is pretty much used for most of HDTV content). It has however a drawback of being patent encumbered which renders it not an option for videos targeted on all Fedora users (even though you can play it in Fedora if you install additional codec packages from livna, but that's not an official Fedora repository). Software patents also put out of the game most of the other codecs, which leaves Theora. It has pretty good quality to compression ratio and is already the output of the gtk-recordMyDesktop, so if you are content with the compression, you don't need to recompress/re-encode the video.

Lastly we need to choose a container format. In opensource world the best choices are probably OGG/OGM/MKV (listed in no order). I don't know if OGG can handle subtitle tracks and OGM seems to be rather hack of OGG to better support videos. It's not much widely used either. On the contrary Matroska Video (mkv) is designed to be portable, fast, open, ... It can contain almost anything which renders it almost ideal container for shipping videos (it can contain multiple video, audio, subtitle tracks, fonts, various other files..., and yet it's generally very fast). It also comes with handy tools that makes adding new subtitle or audio track to existing video a piece of cake [mkvmerge(-gui)].

So what's my choice? It's obvious from the previous text:

• gtk-recordMyDesktop
• Theora
• ASS/SSA subtitles
• Matroska Video (mkv)
  
• (optionally Vorbis audio)

What do you think? Do I have even better choices?