Skalierbare Web-Seiten unter Firefox 2

Mehrere unserer Webkunden haben explizit den Wunsch geäußert, das man Ihre Webseiten auch unter Firefox 2.0 skalierbar gestalten möge. Diesen Wunsch haben wir erfüllt. Es gibt aber einige Fallstricke, die wir hier kurz diskutieren wollen. Die Ausführungen sind vielleicht aber auch von generellem Interesse für diejenigen, die mit “em” als Größeneinheit statt “px” arbeiten.

Grundlagen
Die einheitliche (!) Skalierbarkeit aller Objekte einer Webseite im Firefox (vor Vers. 3.0) kann man durch zwei Dinge gewährleisten:

  1. Definition einer Standardschriftgröße im BODY-Tag nach dem Muster <body style=”font-family:…..; font-size:10px;”>
  2. Bemaßung aller Objektgrößen in den zugehörigen Style- oder Klassendefinitionen statt mit “px” mit “em”. Bsp.:
    <div style=”width:10.0em; height:20.0em;”>

Der Vorteil der Standardisierung auf die Schriftgröße 10px im Body-Tag ist eine vereinfachte Umrechnung:
Die “em”-Werte x 10 entsprechen in der nichtskalierten Seitenversion gerade dem herkömmliche Wert der Ausdehnung in Pixel.

Fallstrick 1: Sukzessive Mehrfachskalierung vermeiden!
Gibt man in einem Tag nicht nur die Geometriegrößen, sondern auch eine abweichende Fontgröße vor, z.B.
<div style=”position:absolute; width:6.0em; height:8.0em; font-size:1.2em; “>,
so wird das DIV keineswegs mit der Größe 60×80 dargestellt, sondern um einen Faktor 1.2 vergrößert. Es zählt immer die aktuelle Fontgröße, die für ein Tag gesetzt ist!

Gegenmittel: Um diesem Problem zu entgehen, kann man die Texte in <span>-Tags einbauen, für die man per CSS vorgefertigte Schriftgrößen definiert. Bsp:

<div style=”position:absolute; width:6.0em; height:8.0em; font-size:1.2em; “><span style=”font-size:12px;”>das ist der text im DIV<span></div>

Schwieriger ist das bei Formularelementen – hier muss man wirklich vorab Berechnungen zur resultierenden Größe anstellen. Formularelemente unterliegen aber ohnehin browserspezifischen Einschränkungen bzgl. der Darstellung. Ein Test in jedem Zielbrowser ist daher angebracht.

Fallstrick 2: Die minimale Schriftgröße im Browser
Hat der Anwender eine minimale Schriftgröße für seinen Browser eingestellt und unterschreitet (!) die im BODY definierte Standardschriftgröße die minimale Schriftgröße, so wird bei einer Seite, die konsequent mit “em”-Größeneinheiten designed wurde, die Geometrie insgesamt mit dem Faktor
“Minimale Schriftgröße des Browsers” / “Standardschriftgröße im BODY”
heraufskaliert.

Beachte: Selbst wenn die Schriftgröße im BODY nicht unter die minimale Schriftgröße des Firefox fällt, so kann doch für einzelne Tags eine andere kleinere Fontgröße definiert sein (s. Fallstrick 1). Für diese Tags wirkt sich dann die minimale Schriftgröße separat aus. Hat man das Vorgehen zu Fallstrick 1 nicht beachtet, so führt dies evtl. zu Schwierigkeiten bei der spezifischen Tagdarstellung oder gar der Seitendarstellung.

Fallstrick 3: Integrierte Flash-Movies
Typischerweise integriert man Flash-Movies W3C-konform mit SWFObjects (Version 1.5 oder 2.0) und verwendet ein zu Container-DIV. In der Version 2.0 wird der Container ersetzt, dessen Bemaßung wird aber übernommen). Hier ist es wichtig, dass der SWF-Film mit der Höhen- und Breiten-Angabe “100%” integriert wird. Dann werden die Maße des Containers beachtet – und wenn diese in “em”-Einheiten vorgegeben sind, so skaliert das SWF-Movie mit.

Wir wünschen viel Spaß beim Ausprobieren!

Eine Seite, die nach diesen Prinzipien von uns entworfen wurde, ist z.B.
http://www.med-aktiv.de

Compiz-Fusion und ein “Kicker”-Problem

Gestern hat sich Deutschland beim “Kicken” gegen Kroatien blamiert. Ein Leiden – fast wie mit Windows – man sieht den Fehlern machtlos zu. Etwas anders bei “Kicker” und Compiz-Fusion unter KDE. Auch da gibt es Probleme im Zusammenspiel; man ist aber nicht zum tatenlosen Leiden verdammt.

Die nachfolgenden Ausführungen gelten für den Fall, dass man die Nvidia-Rendering-Funktionen zur Unterstützung des 3D-Desktops (genauer: des Composite-Managers) und nicht XGL/Compiz verwendet. Hat man den Desktop-Würfel z.B. mit 8 Seiten unter KDE konfiguriert, so gibt es zwei kleine Schwierigkeiten mit der Mini-Anzeige der 8 virtuellen Desktops des Würfels (8 sog. “Viewports”) in der Kicker-Leiste.

  • KDE und Kicker verstehen die neue Konfiguration nicht so, wie sie gemeint ist – nämlich so, dass die 8 Viewports des Würfels die vorherigen virtuellen KDE-Desktops (nehmen wir an, dass seien auch 8 Desktops gewesen) ersetzen sollen. Vielmehr erscheinen 8×8 =64 Minianzeigen von angeblich verfügbaren Desktops im Kicker-Bereich. (Dies ist bei Verwendung von XGL anstelle der Nvidia-Treiber-Funktionen nicht so! Es ist aber verständlich, dass KDE keine Integration für spezielle Funktionalitäten eines spezifischen Herstellers betreibt.)

    Man muss die Anzahl der anzuzeigenden virtuellen KDE-Desktops daher von Hand auf 1 reduzieren, damit nur die 8 Minianzeigen der “Viewports” des 3D-Desktops in der Kicker-Leiste übrigbleiben.

  • Viel ärgerlicher ist, dass alle auf irgendeinem der Viewports geöffneten Fenster in der Minianzeige der Desktops nur auf dem ersten Viewport-Minibildchen erscheinen. Denn Kicker kann das eigentlich besser; Kicker muss dazu aber die Information über die aktuelle Konfiguration neu verarbeite. Es hilft der kurze Wechsel zu einem Terminalfenster und die Eingabe von

    ….> killall kicker
    ….> kicker

    am Prompt. Bitte kein “kicker &” absetzen.

Danach verhält sich die Minianzeige der virtuellen Desktops in der KDE-Kicker-Leiste wie gewünscht und die Freude am 3D-Desktop – einer “Spielerei”, wie meine Frau nicht ganz zu Unrecht meint – ist noch größer.

kicker

Rosegarden – hast du Töne?

Rose_Haupt

Gestern habe ich darüber berichtet, wie man “JACK” zum Laufen bringt. Jack ist meist aber nur Mittel zum Zweck. In meinem Fall sollte eigentlich der Sequenzer “Rosegarden” ausprobiert werden. Ich war ja gestern ganz froh, als Rosegarden endlich lief, den Anschluss an Jack schaffte und keine Fehler mehr meldete. Dann habe ich aber (leider) auch noch den Versuch unternommen, Rosegarden und meiner Audigy-Soundkarte ein paar Midi-Töne zu entlocken. Das misslang im ersten Anlauf völlig – Rosegarden blieb stumm und gab trotz korrekt konfiguriertem Jack keine Midi-Töne von sich. Interessanterweise konnte der Datenstrom eines SW-Synthesizers, der mit JackEQ auf Rosegarden umgelenkt wurde, sehr wohl mit lautstarkem Resultat verarbeitet werden. Ursachen für mein Scheitern mit Midi waren einerseits meine Unerfahrenheit mit Audio-Devices, aber auch etwas missverständliche Einstellungsdialoge von Rosegarden.

Rosegarden bietet im Bereich der Midi-Konfiguration einen Dialog an, mit dem das Midi-Gerät gewählt werden kann und mit dem auch die zugehörigen Bänke verwaltet werden. Dieser Dialog wird durch einen weiteren zum “Laden” einer Soundfont-Bank ergänzt. Hier begann meine Kette der Mißverständnisse: Der Rosegarden-Dialog zur Verwaltung der Midi-Geräte lädt nämlich keineswegs Soundfonts auf die Karte (s.u.).

Im Internet entdeckte ich übrigens, dass eine Reihe von Leuten ein ähnlich stummes Rosegarden vorgefunden hatten wie ich selbst. Die erhielten dann von bekümmerten Zeitgenossen viele Ratschläge, von denen die meisten aber am Kern des Problems vorbeigingen. U.a. fand ich die Anmerkung, dass ein SW-Syntheziser zwingend erforderlich sei. Das ist schlicht falsch. Die “Audigy 2”-Karte, die ich einsetze, ist ein vollwertiger Soundprozessor, der unter dem emu10k1-Modul und Alsa sehr wohl mit Midi-Vorgaben umgehen kann. Nachfolgende Ausführungen sollen helfen, meine elementaren Fehler zu vermeiden. Der Reihe nach:

Midi
Midi ist nach meinem Verständnis ein Protokoll, das einem Klang-Generator (z.B. einem Synthesizer oder einer Sounkarte) vorgibt, mit welcher zeitlichen Charakteristik, Lautstärke und in welcher Tonhöhe er Töne erzeugen soll. Die Vorgabe kann über Software, aber auch über Midi-fähige “eingabe”-Instrumente udn Tastaturen erfolgen. Die klangliche Färbung liegt dagegen beim Sounderzeuger/Schallumwandler. Im Fall einer modernen Soundkarte werden zur Vorgabe instrumentaler Klangfarben sog. Soundfonts auf die Karte “geladen”. Diese steuern den Syntheziser der Karte so, dass er eine Reihe von klanglichen Varianten nach einem bestimmten Nummernschema (Soundbänke und Kanäle) anbieten kann. Das Midi-Protokoll erlaubt dann z.B. einer Sequenzer-SW, diese “instrumentalen” Klangfarben des Midi-Geräts gezielt einzusetzen.

Soundfontdateien für die Audiokarte
Damit die Midi-Devices auf einer Soundkarte (meist gibt es hier mehrere) überhaupt Töne produzieren, wenn sie von einer Software über das Midi-Protokoll und den Soundkartentreiber angesprochen werden, muss also zuvor zwingend eine Soundfont-Datei (wie z.B. CT4MGM.SF2) auf die Soundkarte (in meinem Fall eine Audigy 2) geladen werden. Soundfontdateien gehorchen normierten Formaten. Man findet Soundfont-Dateien im Internet oder auch auf Treiber-CDs für die jeweilige Soundkarte.

Laden von Soundfontdateien auf die Audiokarte
Zum Laden von sog. “sf2”-Soundfontdateien auf eine Audigy gibt es unter Linux das Programm “/usr/bin/asfxload”. Es arbeitet selbstverständlich mit dem emu10k1-Treiber (und Alsa) zusammen. (Für oss heisst das Programm sfxload – Rosegarden und Jack erfordern aber Alsa). Zu den Optionen siehe die Man-Seiten.

Anstatt manuell mit asfxload zu arbeiten, kann man das Laden auch von Rosegarden vornehmen lassen – Rosegarden setzt dazu asfxload ein. Der entscheidende Dialog hierfür
findet sich unter “Einstellungen -> Rosegarden einrichten -> Midi” und nicht (!) unter “Studio -> Midi-Geräte verwalten”.

Rosegarden_1

Laden von Soundfontdateien zur Rosegarden-Konfiguration
Damit Rosegarden sinnvoll zum “Komponieren” von Musiksequenzen verwendet werden kann, muss auch Rosegarden über das Midi-Device und sein Angebot Bescheid wissen. Hierzu können bestimmten Midi-Devices einerseits echte HW-Devices zugeordnet werden. Andererseits soll Rosegarden auch über die Soundbänke informiert werden. Letzteres entspricht dem “Laden” (Auswerten) der Soundfont-Dateien in Rosegarden und die Zuordnung zu den Midi-Devices für die diversen Dialoge und Oberflächen von Rosegarden. Die entsprechenden Konfigurationseinstellungen nimmt man nun unter “Studio -> Midi-Geräte verwalten” vor.

Rose_Midi_1

Rose_Midi_2

Hier lädt man dann das gleiche File, dass man zuvor an die Soundkarte übermittelt hat, erneut – nur diesmal für Rosegarden. Rosegarden bietet danach in seinen Dialogen die richtigen, d.h. die zum geladenen Soundfont passenden Kanäle und Instrumente an.

Endlich – Töne
Nun steht dem Komponieren mit den sehr eingänglichen Dialogen nichts mehr im Wege. man legt ein Segment an und bearbeitet dieses dann z.B. im Matrixeditor. Auf dem dortigen Keyboard kann man die ersten Töne hören (hoffentlich). Welchen Kanal (sprich Instrument) man der aktuellen Sequenz zuordnen will regelt man am besten mit einer Reihe von anderen Einstellungen hier. Danach heiß es nur noch Zeitintervalle mit Noten zu füllen …..

Rose_matrix

Im Hauptfenster kann man übrigens das hörbare Instrument im nachhinein noch abändern.

Stabilität?
Aus meiner Sicht ist Rosegarden im Zusammenspiel mit Jack und anderen Musik-Komponenten noch nicht 100%-ig stabil. Es kam beim Spielen manchmal zu Jack-Fehlern und nachfolgenden Problemen mit Rosegarden. Im schlimmsten Fall war sogar ein Neustarten des kompletten Audiosystems vonnöten. Ich bin im Moment nicht sicher, welche der vielen Komponenten (emu10k1, Jack und seine vielen Komponenten, andere Jack-fähige Audioprogramme oder eben Rosegarden) die Schuld an den Problemen trägen.
Aber im Allgemeinen kann man sich mit Rosegarden und schönen wie schrägen Eigenkompositionen sehr gut die Zeit vertreiben. Ein im Ansatz sehr nettes Programm – auch für Laien, wenn man es richtig einrichtet.

Links
http://rosegarden.sourceforge.net/tutorial/en/chapter-1.html
http://de.wikipedia.org/wiki/Musical_Instrument_Digital_Interface

Jack unter Opensuse 10.3

Ich bin kein Linux-Audiofreak und habe von Audioservern, Jack und Konsorten keine Ahnung. Normalerweise reicht es mir, wenn an meinem Arbeitsplatz “amarok” (ein tolles Programm!) im Zusammenspiel mit Alsa oder Oss meine Musikdateien in Töne verwandelt. Ich habe eine Audigy 2 Soundcard unter Linux; an der hängt ein 7.1 Lautsprechersystem (Upmix von 5.1 oder 6.1 Sound auf 7.1) und damit bin ich vollkommen zufrieden.

Heute allerdings musste ich Rosegarden für einen potentiellen Kunden für Tests unter Opensuse 10.3 installieren. Rosegarden benötigt den Jack – Echtzeit- Audioserver. Also habe ich Jack und einige zugehörige Tools wir JackEQ aus den SuSE-Repositories installiert. Dann wollte ich Jack einfach mal ausprobieren.

Erste Hürde: Wie startet man Jack?
Der naive Versuch, dies über die Auswahl “Jack Echtzeit-Audioserver” in der Soundsystem-Konfiguration im KDE-Kontrollzentrum zu machen, scheiterte. Der Soundserver wird zwar wieder gestartet, doch jede danach von einem normalen User gestartete Jack-Applikation meldet, dass Jack nicht läuft. Der Verdacht, dass Jack beim gewählten Vorgehen gar nicht gestartet, sondern eher vorausgesetzt wird, bestätigte sich nach einem Blick in die Prozesstabelle. Von “jack”-Prozessen keine Spur. Ein wenig Forschen im Internet führt einen dann zum manuellen Start mittels

jackd -v -d alsa -d hw:0

Das ging dann auch problemlos. Später – nach dem Überwinden einer weiteren Hürde – fand ich dann das schöne Tool “Qjackctl”, das das Starten und Überwachen des Audio-Servers QT-basiert über eine gelungene graphische Oberfläche ermöglicht.

qjackctl_2

Ein Test des Soundservers ist möglich, indem man z.B. “amarok” startet und unter den Einstellungen für die Audio-Ausgabe “Jack” wählt. Das funktionierte auch schön, bis ich nach einer Weile kurzzeitige Aussetzer bemerkte, wenn man andere ressourcenlastige Applikationen mit hoher Priorität startete. (Dies resultiert in etwas kryptischen xrun-Meldungen). Ich spielte danach an Pufferparametern, Periodenparametern und Prioritätsparametern im Jack-Aufruf herum ( z.B. : -P 0 -p 512 -n 2 ). Nur mit begrenztem Erfolg. Es gab dennoch immer mal wieder einen kleinen Aussetzer. Für die Analyse hatte ich bisher keine Zeit. Da ich aber was von Echtzeit gelesen hatte, wollte ich nun Jack mit Echtzeit-Priorität starten.

Zweite Hürde: Jack mit Echtzeitpriorität?
Der (gem. man-Doku) erforderliche Aufruf

jackd -v -R -d alsa -d hw:0

scheitert mit einer Meldung des Systems, dass man dazu keine Berechtigungen hat. Gut so! Warum sollte ein beliebiger User das auch dürfen; das wäre ein immenses Sicherheitsrisiko. Jack als root zu starten ist aus dem gleichen Grund unsinnig. Das bringt einen auf den Gedanken, dass man wohl in den PAM-Dateien einen Einstellung vornehmen muss. Tatsächlich sind Einträge in der Datei /etc/security/limits.conf gefragt. Will man etwa genau einem User namens “ralph” die notwendigen Rechte geben, so sind folgende Einträge angebracht :

ralf – rtprio 99
ralf – memlock unlimited
ralf – nice -19

(Für Gruppen greife man statt “ralph” zu “@gruppenname”. )

Der User Ralf darf dann tatsächlich nach einem neuen Login jackd -R ausführen. Und nun läuft der Sound auch völlig ruckelfrei und problemlos in fast jeder Belastungslage des Systems.

Dritte Hürde: JackEQ läuft nicht ohne vorgegebenen Suchpfad
Im nächsten Schritt möchte man gerne JackEQ und andere Programme aus dem Jack-Umfeld starten. Das misslingt zumindest im Fall von JackEQ jedoch. Startet man vom Terminal aus, so erhält man die Meldung, dass die Library dj_eq_1901.so nicht gefunden wird. Nach einer kurzen Recherche findet man, dass man das Paket xxxx installieren muss. Leider reicht das auch nicht, denn JackEQ vermutet die Bibliotheken zumindest auf einem 64Bit-
System im falschen Verzeichnis. Eine Suche im Internet ergibt dann, dass man unter Opensuse tunlichst

export LADSPA_PATH=”/usr/lib64/ladspa”

in eine der profile-Dateien für den Start der Shell einfügen sollte. Danach werden die Bibliotheken auch gefunden und JackEQ verrichtet seinen Dienst zusammen mit Jack.

Fazit
Jack in Ehren – aber an der Installationsfreundlichkeit lässt sich noch Einiges verbessern.

Tja, und was war eigentlich der Anlass für das Ganze? Ach ja, Rosegarden. Ein Test zeigt, dass auch dieses Programm läuft – zumindest im Prinzip. Auch hier meldet das Programm nämlich das Fehlen diverser benötigter Zusatzprogramme, die sich jedoch nachinstallieren lassen. Zu Rosegarden mehr an anderer Stelle.

Links
http://lau.linuxaudio.org/jack/
http://jackaudio.org/faq

Heiße Tage, sensors und KPowersave

Temp

An so warmen Tagen wie heute, in denen sich das Thermometer im Arbeitsraum sich in die Nähe von 30° bewegt, kommt ab und zu Sorge über den Temperaturzustand und das Wohlbefinden der Desktop-Systeme auf. Manch einer, der vom Board-Hersteller seiner Wahl unter MS-Windows mit hübscher Zusatzsoftware verwöhnt wurde, mag sich dann fragen, wie er unter Linux an entsprechende Informationen gelangt. Unter einer aktuellen SuSE-Distribution ist das i.d.R. kein Problem dank umfänglicher Libraries und Module zur Unterstützung einer Vielfalt von Sensoren. Unter anderen Distributionen muss man sich ggf. ein kleines Startskript zum Laden der Module selbst schreiben.

Ksysguard, sensors-detect und sensors
Auf unseren Rechnern befinden sich in der Regel Asus-Boards. Nach dem Einrichten der jeweiligen Linux-Systeme (Opensuse) lassen wir immer auch das nette Tool “/usr/sbin/sensors-detect” laufen und nehmen zu den identifizierten Sensoren der Boards und des Prozessors die entsprechenden Konfigurationseinträge in der Datei /etc/modprobe.conf vor. Unter SuSE versehen wir zusätzlich die Datei “/etc/sysconfig/lmsensors” mit Einträgen wie von “sensors-detect” vorgeschlagen. Übrigens: Ein zusätzlicher Blick in die Datei “/etc/sensors.conf” ist in jedem Fall interessant und lehrreich.

Ein kleines Startscript startet dann unter Suse die Sensor-spezifischen Module während des Hochfahrens der Systeme. Ein ähnliches Skript kann man auch zum manuellen Start der Sensor-Module verwenden. Bei einem unserer Rechner sieht der zentrale Teil des Skripts etwa wie folgt aus:

modprobe i2c-nforce2
modprobe eeprom
modprobe it87
modprobe k8temp
# sleep 2 # optional
/usr/bin/sensors -s

Danach bleibt eigentlich nur noch übrig, unter der KDE-Applikation “ksysguard” ein sog. “Arbeitsblatt” für die Temperatur und Lüfterdaten anzulegen und die Updatefrequenz vorzugeben. (Die verschiedenen verfügbaren Sensoren werden im linken Bereich des “ksysguard”-Fensters angezeigt.)
Unter KDE lasse ich mich dann nicht nur über die aktuellen internen Temperaturen des lokalen Rechners (s. Bild), sondern auch über den Zustand anderer Linux-Desktop-PCs informieren (per ssh -X Verbindung). Traut man den graphischen Bildern nicht oder braucht man Werte genauer, so hilft der Aufruf von “/usr/bin/sensors” im Terminal oder an der Konsole.

KPowersave
Hat man erst einmal vernünftige Informationen über die Temperaturen des Prozessors und des Chipsatzes am Display, so lohnt es sich, verschiedene Einflussfaktoren auf die Temperatur zu studieren. U.a. kann man ein wenig mit KPowersave herumzuspielen. Viele AMD- und Intel-Prozessoren können über entsprechende Schema-Einstellungen unter KPowersave auch dynamisch getaktet werden. Voraussetzung ist i.d.R., dass eine entsprechende Option im BIOS geschaltet ist (z.B. “AMD Cool and Quiet”). Meiner Erfahrung nach bringt das Umstellen des CPU-Frequenzschemas auf “dynamic” u.U. bis zu 8 ° Celsius Temperaturabsenkung im zeitlichen Mittel. Das ist an sehr heißen Tagen eine beträchtliche Reserve und man vermeidet unter normalen Lastanforderungen permanent hoch drehende CPU-Lüfter.

KPower_CPU

Zusätzlicher Seitenlüfter im Gehäuse bei Heatpipes auf dem Mainboard
Gerade bei Mainboards mit einer Heatpipe zur Kühlung des Chipsatzes lohnt sich evtl. auch der Einbau eines kleinen (leisen) Lüfters in die seitliche Gehäusewand, der vertikal kühle Luft von außen auf die Kühlbleche der Pipes lenkt. Dieser zusätzliche Lüfter brachte bei mir eine erhebliche Temperaturabsenkungen des Boards.