Archive for the 'Webdesign' Category

Useful Shell Oneliners

Monday, November 12th, 2007

From time to time you come upon some useful oneliner in the shell. Either because you see it somewhere, see someone doing it, or because you need it and produce one yourself. And most of the time, it’s not enough to put into a shell-script, so you find yourself hunting for it in your .bash_history. Well, here are some:

Do something to a lot of files
for i in *; do command $i; done

You’ll need this a lot. Does not work with files containing spaces

Convert a load of images
for i in *.tif; do convert -quality 75 $i `basename $i .tif`.jpeg;

Make pdf out of a several images
convert -limit memory 32 -limit map 32 *.png target.pdf

You really want to set the limits, unless you have more RAM than the whole images converted to pbm.

With Graphicsmagick, you need to set a compression for jpg, otherwise the resulting PDF will be huge.

gm convert -compress JPEG *.jpg target.pdf

The resources you want to give those programs can be set using environment-variables:

export MAGICK_MEMORY_LIMIT="640mb"
export MAGICK_MAP_LIMIT="320mb"
export MAGICK_AREA_LIMIT="640mb"

Make pdf out of a lot of images
But the whole idea of using ImageMagick or GraphicsMagick to create pdf-files is very much flawed, since both first convert the jpeg-files into an raw, uncompressed intermediate format which tends to eat up all available memory, and then crash. And which is completely nonsensical too, since jpeg-files can be embedded into pdf as they are. Luckily, pdfjoin will help us, tough it accepts only files with the extension ‘.pdf’ as input as of yet:

mmv '*.jpg' '#1.pdf'; pdfjoin --outfile target.pdf *.pdf

Change resolution (DPI) of an image
convert -density 600 -units PixelsPerInch source.png target.png

split/crop pictures
convert -crop 1230x880 source.png target

Note that this does not really crop the image, but splits it into as many parts as necessary, using “target” as prefix, adding a number as suffix.

fix offset
convert +repage source.png target

Lately, “crop” seems to behave differently, it leaves all but the first part with an offset. This makes the picture disappear in gimp, and stretched if you make a pdf out of it. That’s why you may need to repage.

convert -rotate 90 source.png target

rotates 90 degrees clockwise.

Attach pictures to each other, one below the other
montage +frame +shadow +label -tile 1x2 -geometry "widthxheight+0+0" source1.png source2.png target.png

Important is that width and height are the dimensions of each of the sources. For putting them next to each other, just use 2×1 as tile.

Rename files according a textfile-list
for i in `cat list` ; do mv `echo $i | awk -F"-" '{print $1".ext"}'` $i.ext ; done

Delete empty directories
find . -type d -empty -depth -exec rmdir {} \;

Remove first page of a PDF
pdftk A=source.pdf cat A2-end output target.pdf

Yes, pdftks syntax is a bit alien.

Merge PDFs
pdftk sources*.pdf cat output target.pdf

Unpack lots of packed files into different directories
for i in *.rar; do mkdir `basename $i .rar`; mv $i `basename $i .rar`; cd `basename $i .rar`; rar x $i; cd ..; done

If you have a load of packed files, in this case rar, and you want to unpack each into a different subdirectory, according to the name of the rar-file.

Get rid of magnatune-advertisements in mp3s

for i in *.mp3; do mp3splt -s -p min=2 -d `basename $i .mp3` $i ; done

Merge AVI-movies
mencoder -forceidx -oac copy -ovc copy -o outputfile.avi parts*.avi

That’s the basic way. If you want to process a whole directory with avi-files whose filenames have a distinct part (like “cd≶num>” or “-Part≶num>” as in my example) you can do something this:

for i in *-Part1.avi; do mencoder -forceidx -ovc copy -oac copy -o `basename $i -Part1.avi`.avi `basename $i -Part1.avi`-Part*.avi; done

To be continued. You might also want to check out my Program-section for small useful scripts.

The Tao Of Webdesign

Saturday, January 14th, 2006

People still don’t get it. And I’m not talking about mere webdesigners, but also of producers of content management systems (weblogs and wikis as a subclass of this).

Even though there exist some really marvelous pages which you can use as inspiration for instance. Or And there are also pages which tell you exactly what you should do, and what not:

But what do I get? Fixed width pages which scroll sideways or put the content above each other, because some asshat thinks everyone has at least 800×600 and uses the browser in full screen mode. Well, hell, no. My Browser tries to have natural proportions of 1:√2 — same as A4.

This makes even with 1280×1024 just about a browsing-space of 700×1000. Less with my 1024×768 at home. I won’t even go into handhelds and cellphones. Of course my colleague with his 1920×1600 has the problem of pages sitting in the middle of his screen, because they only occupy 700 pixels width instead of his 900. So why the fuck are people still hardcoding it?

It Ain’t Easy

Saturday, January 14th, 2006

It ain’t easy to start blogging. Well, it would, if a blog would be all that you want. But if you want to incorporate it into an existing website, you’ll discover that the author of the thing has completely different ideas about the structure of the css-file.
Of course, your colors look terrible if the font used is smaller or bigger than intended. Also, everything seems to have some fixed width used, which really pisses me off.

Well anyway, I seem to have managed, it blends reasonably well with the rest of the page, tough it still uses its own css, so you can’t change the css as in the rest of the pages.

Well anyway, one reson for this is that the “Bookmarks”-section was getting more and more outdated, since the automatic update from the Browser didn’t work since Communicator 4.7, and attempts to do it by WebDAV have proven futile (the pugin made firefox stall and crash). The second reason is of course that I like to rant. And what I’ve done in my “Essays” Section I can do in a blog now. So there.

Webdesign Issues

Thursday, November 11th, 2004

Problems and Workarounds concerning Webdesign


The Tao of Webdesign. Well, it’s there, its XHTML strict with
CSS. Sad that some browsers just can’t work with it or have
severe bugs. So I asked myself the question, what public do I have,
and which browsers do I have to support? Support, in a sense of
“it has to be reasonably useable an readable”. Specifically, one
Question was whether enough (more than 1 percent) of people will
be using very old (and broken) browsers like Netscape 4.x or MSIE 4.x

The Browsers

For determining the capabilites of browsers, it was necessary to decide
what browsers would have to be looked at. So I assembled some data
from October 2004 on swiss Webpages.

A statistic from a high-traffic sports-tournament page. This gives us a
hint on what the majority of unsuspecting users will use. Note that this,
as a sports-event, will necessarily not be a representative sample of the
whole population, as it is to expect that a whole lot of people are not
interested in sports at all, or not interested in that specific sport;
thus probably under-representing certain groups of people (thought to
be the technical and the scientific community, for instance).

MSIE 6.x	84.23%
MSIE 5.x	 8.25%
Mozilla		 5.37%
Opera 		 1.37%
Netscape 3/4	 0.31%
MSIE 4.x	 0.10%

And one from a medium-traffic tech-news site. The Site is moderately
technical and covers also socio-technical problems or politics related
to technology. The sample is thus heavily skewed towards technically
proficient people and early adopters. But having the early adopters
in there makes it very interesting as a foreshadow of future development.

Mozilla		39.67%
MSIE 6.x	30.41%
kHTML		 3.99%
Opera		 3.49%
MSIE 5.x	 2.01%

We thus conclude that Netscape 4.x and MSIE 4.x are practically dead,
and given the brokenness of those browsers, not worth the effort of
supporting at all.

As general trends we can thus conclude that MSIE 5.x will fall below
one percent in maybe a year or two, getting replaced by more modern
browsers. Support for MSIE 5.x should only be done if its a small
effort and does not interfere with other browsers. On a small rise
seem to be Opera and kHTML (the latter a library used by Konqueror
and Safari), definitly worth some support. The big hunk of people
right now is using MSIE 6.x, so that is the main target, along with
its contender Mozilla which might well surpass MSIE in the future.

Another point is the relative standard-adherence of the browsers.
While Mozilla, Opera and kHTML strife for maximal W3C-compliance
(and are sometimes very close to achieve it), this cannot be said
for MSIE. Since the future of MSIE is largely unknown (Microsoft
talk about a new version some time in 2007); the only sane choice
is to adhere to the standards as much as possible. Specifically
writing web-pages for MSIE 6.x seems short-sightened in this light.
Due to the large installed base however, MSIE 6.x justifies for
specific adjustments and bug-workarounds.


Given that there not only are standards, but those standards are
evolving and mostly implemented in the browsers, it makes sense to
adhere to the standards; and to adhere to the most strict version
of it (the transitional-versions are, well, for the transition of
pages from an earlier standard in order to simplify work). Well,
but there is not only one standard, but many.

There is, for instance,
the old HTML 4.0 which was surpassed by XHTML 1.0 (essentially this
would be HTML 5.0). And there is not only XHTML 1.0 but 1.1 and now
2.0. According to the recommendations of the W3C
XHTML 1.1 is a modularized version of XHTML 1.0; and XHTML 2.0 is
something completely new and incompatible to anything else. Given
that browsers don’t understand XHTML 2.0; I can’t discern the differences
between XHTML 1.1 and 1.0 and given that the W3C itself uses mostly
XHTML 1.0/strict, XHTML 1.1 and 2.0 can only be viewed as work-in-progress
or proof-of-concept which right now aren’t worth the trouble to implement.

When using XHTML 1.0/strict, we’re bound to only make layout-changes
through a Cascading Style Sheet (CSS). Now, there are different versions
of those as well. There’s level 1 and 2.1; and level 3 in development,
and not all browsers support all elements of level 2.1. Luckily all
relevant browsers support level 1. The choice making sense is to use
CSS level 1, with selected elements of level 2, and to ignore that some
features like :after and :before do not exist on MSIE 6.x; they aren’t
really of big importance, the layout will look a bit different, but so


This is a bit MSIE 6.x-heavy, but what do you expect? Pretty much
all of those are documented on
Position is Everything
. Of course I ran into several of them; one of
them seemingly not turning on a horizontal scrollbar while positioning some
text WAY to the right instead of just 350 pixels.

Peter Keel,