Wiki­pe­dia bie­tet die Mög­lich­keit ein­zelne Arti­kel („Sei­ten“) in einem Buch zu sam­meln. Das so gene­rierte Buch kann man in Kapi­tel unter­tei­len (lei­der nur in einer Kapi­te­l­ebene). So habe ich mich heute dran­ge­macht und ein Wiki­pe­dia­buch mit The­men für alle die sich für das Thema oder den Beruf des Medi­en­ge­stal­ters inter­es­sie­ren,  zu erstel­len. Das Buch kann man bei Wiki­pe­dia als PDF her­un­ter­la­den und ich habe dar­aus mit dem kos­ten­lo­sen Dienst der Web­seite www.youblisher.com ein PDF zum Onlin­ele­sen und –blät­tern gemacht (die­ses ent­hält aber lei­der keine funk­tio­nie­ren­den Links mehr). Zwar ist das durch Wiki­pe­dia gene­rierte Lay­out nicht per­fekt (Sei­ten­num­mern immer oben rechts, keine Sil­ben­tren­nung > unschö­ner Block­satz, etc.) aber es ist schon beein­dru­ckend wie man „auto­ma­tisch“ ein sol­ches Doku­ment erstel­len kann.

Selbst­ver­ständ­lich bin ich nicht Autor des Buches, die Rechte ent­spre­chen der Lizen­sie­rung der Wiki­pe­dia. Die immer aktu­elle Ver­sion des Buches fin­det sich auf der Wiki­pe­dia­seite Medi­en­ge­stal­ter­buch.

Was es heut­zu­tage alles gibt: Da hat man schnel­ler ein 200seitiges Buch erstellt — als gele­sen. Bin gespannt, was sich in „mei­nem“ Buch alles Inter­es­san­tes findet.

Und es geht doch!

(wei­ter­le­sen…)

Pub — ohne soft­ware

Micro­soft Publis­her ist eine Soft­ware, wel­che die meis­ten Gra­fi­ker und Dru­cker am liebs­ten abschaf­fen möch­ten. Nicht etwa, weil sie so gut ist, son­dern weil die Daten, die damit erzeugt wer­den nicht zu gebrau­chen sind¹.

Doch was macht man nun als „Ver­ar­bei­ter“ mit pub-Datein von Kun­den? Ent­we­der man bit­tet den Kun­den irgend­wie eine PDF-Datei zu erstel­len (was mit­un­ter dazu führt, dass man erklä­ren muss, wie das geht) oder man macht diese Pub-Datei sicht­bar, indem man selbst ein PDF dar­aus gene­riert. Doch sicher­lich bin ich nicht der ein­zige „Druck­vor­stuf­ler“, der sich wei­gert sowas wie den Micro­soft Publis­her auf sei­nem Com­pu­ter zu instal­lie­ren. Erfreu­li­cher­weise ist das aber auch nicht mög­lich, denn es gibt eine Web­seite, die Datein in pdf kon­ver­tiert — und auch Publisher-Dokumente annimmt, zumin­dest wenn diese nicht grö­ßer sind als 6 MB.

(wei­ter­le­sen…)

Die­ser Arti­kel beschreibt, wie man sei­nen eige­nen Web­ser­ver (auf dem eige­nen PC) von über­all aus dem Inter­net unter einem ein­heit­li­chen Domain­na­men erreich­bar macht. (Dyna­mi­sche Name­ser­ver­dienste konfigurieren)

(wei­ter­le­sen…)

Dass gute Web­sei­ten nicht mal so schnell gemacht sind und deren Ent­wick­lung und Kon­zep­tion wohl über­legt sein müs­sen stimmt — im Prin­zip. Es gilt aber auch abzu­wä­gen, wel­che Ziele am wich­tigs­ten sind. Beschließt man am 3.2.2010, dass man eine Web­seite zur Ver­mark­tung von Fest­pla­ka­ten an Schau­stel­ler und Ver­an­stal­ter von Volks­fes­ten etc. ver­öf­fent­li­chen möchte — und möchte man auch die Suchmaschinen-Nutzer errei­chen, die in den nächs­ten Tagen für Früh­jahrs­volks­feste Pla­kate ein­kau­fen, dann heißt es ganz schnell sein und bloß kei­nen Tag verlieren.

(wei­ter­le­sen…)

Das Plu­gin Google Ana­lytics 3 codes for Word­Press war bei mei­ner Wordpress-Installation (Ver. 2.9.2) dafür ver­ant­wort­lich, dass keine Bilder/Videos/Audio/Dateien mit dem Rich Text Edi­tor mehr über „Hochladen/Einfügen“ über­tra­gen wer­den konn­ten. Mit akti­vier­tem Plu­gin erschien im neuen Fens­ter der Text: „Bist du sicher, dass du das tun möch­test? Bitte noch mal ver­su­chen“ anstelle dem erwar­te­ten Upload-Dialog.

Nach der Deak­ti­vie­rung des Moduls funk­tio­niert der Datei­upload wie­der einwandfrei.

Mein häus­li­cher Linux-Server (Ubuntu LTS) führt ein beschau­li­ches Dasein: mysql, Apa­che, Samba,  Mail­ser­ver — aber so gut wie keine Nut­zer. Ver­wal­tet habe ich ihn bis­her über eine SSH oder eben direkt an der Kon­sole. Schon lange hatte ich vor per VNC den XFCE4-Desktop auch aus der Ferne bedien­bar zu machen. Heute machte ich mich mal an die Arbeit und nach­dem es nun halb­wegs läuft doku­men­tiere ich die Ergeb­nisse — nütz­lich für mich selbst — und viel­leicht auch für andere.

(wei­ter­le­sen…)

Dem Markt­füh­rer und Platz­hirsch Adobe sagte man ja schon län­ger nach, dass dort Inkom­pa­ti­bi­li­tä­ten zu Vor­gän­ger­ver­sio­nen nicht als Pro­blem, son­dern als Lösung des Pro­blems betrach­tet wer­den, des Pro­blems näm­lich, wie Adobe seine Kun­den dazu brin­gen kann immer auf die neu­este Ver­sion upzugraden.

(wei­ter­le­sen…)

Was ist anders im Web — als beim Druck?

Die Vor­her­seh­bar­keit des Dar­stel­lungs­er­geb­nis­ses von Web­sei­ten hängt von zahl­rei­chen Fak­to­ren ab und ist lei­der nur bedingt vor­her­seh­bar. Darin unter­schei­den sich Online-Publikationen ganz erheb­lich von Druck­sa­chen. In der Druck­vor­stufe wur­den Stan­dard­for­mate und spe­zi­elle Work­flows ent­wi­ckelt, um keine bösen Über­ra­schun­gen in der Pro­duk­tion zu erle­ben (siehe PDF/X1a, PDF/X3 etc.). Hält sich der Gra­fi­ker bzw. Druck­da­ten­er­stel­ler an den ver­ein­bar­ten Stan­dard, ver­wen­det er nor­mierte, pro­fi­lierte Farban­ga­ben und berück­sich­tigt die Papier­ei­gen­schaf­ten, kann er sich ziem­lich sicher sein, am Ende auch das gewünschte Ergeb­nis auf Papier in Hän­den hal­ten zu kön­nen. Und — ist die Druck­sa­che erst mal pro­du­ziert — wird auch wirk­lich jeder Betrach­ter das glei­che Dru­ck­er­geb­nis in Hän­den hal­ten können.

Im Onlin­ebe­reich ver­hält es sich (lei­der) völ­lig anders.

(wei­ter­le­sen…)

Heut­zu­tage sind wir am PC stän­dig mit Schrif­ten kon­fron­tiert. Die meis­ten von uns, ohne dass sie sich jemals näher mit Typo­gra­fie oder der Her­stel­lung von Com­pu­ter­schrif­ten beschäf­tigt haben. Doch in Com­pu­ter­schrif­ten steckt eine Menge Arbeit, sie sind Pro­dukte, die ver­kauft und lizen­siert wer­den. Man kann/darf also nicht ein­fach eine Schrift die man von irgend­je­mand bekom­men hat ver­wen­den, ohne deren Lizen­sie­rung zu beachten.

In der Pra­xis stellt sich für den Gestal­ter die Frage — wie komme ich zu geeig­ne­ten, hoch­wer­ti­gen und güns­ti­gen Schrif­ten? Natür­lich kann man Schrif­ten ein­fach bei den Pro­fis von Adobe, Lino­type, Fonts.com, myfonts.com, ITC etc. kau­fen — übri­gens eine sehr gute Idee, wenn aus­rei­chend Bud­get zur Ver­fü­gung steht, denn dort gibt es nur hoch­wer­tige Schriften.

Doch für Gele­gen­heits– und Hob­by­ge­stal­ter aber auch für begin­nende Medi­en­ge­stal­ter mit klei­nem Bud­get sind kos­ten­güns­tige Alter­na­ti­ven wich­tig, die wir in die­sem Arti­kel auf­zei­gen möchten.

(wei­ter­le­sen…)

…was behan­delt man in so knap­per Zeit mit Linux-Anfängern? Am 19.2.2009 führte ich für die LUSC e.V. einen Work­shop zur Linux-Kommandozeile an der VHS durch. Viel­leicht nützt diese Agenda Leu­ten, die eine ähnli­che Auf­gabe vor sich haben. (wei­ter­le­sen…)

Wer kennt sie nicht die Feh­ler­mel­dun­gen, mit denen uns unsere Soft­ware mit­teilt, dass etwas nicht funk­tio­niert. Feh­ler gibt es nicht erst seit es Com­pu­ter gibt. Aber seit­dem gibt es sie die schö­nen Feh­ler­mel­dun­gen, die unse­ren All­tag etwas Abwechs­lung besche­ren. Meine liebs­ten Feh­ler­mel­dun­gen sammle ich hier. (wei­ter­le­sen…)

Wer als Datei­ser­ver für Windows-Benutzer einen Samba-Server benutzt, der muss auch auf den heiß­ge­lieb­ten Papier­korb nicht ver­zich­ten. In unse­rer Agen­tur ist der Papier­korb so kon­fi­gu­riert, dass die gelösch­ten Dateien bestimm­ter Netz­werk­frei­ga­ben in einem Ord­ner mit Namen .Papier­korb lan­den und zwar in dem Unter­ord­ner des Nut­zers, der die Datei gelöscht hat. Ein wei­te­rer Vor­teil die­ser Kon­zep­tion ist, dass man den Papier­korb auto­ma­tisch per cron­job löschen kann. In unse­rem Fall wer­den Dateien im Papier­korb, die älter sind als 14 Tage, gelöscht — sozu­sa­gen ein Papier­korb in dem immer nur die alten Doku­mente aus­ge­leert werden.

Der Papier­korb ersetzt natür­lich KEINE Daten­si­che­rung, ist aber hilf­reich wenn ver­se­hent­lich durch Benut­zer Dateien oder Ord­ner gelöscht werden.

Wie gehts? (wei­ter­le­sen…)

Hat­ten Sie auch schon mal das Gefühl — „Oh Gott, was habe ich gemacht… könnte ich doch nur die Zeit ein biss­chen zurück­dre­hen und das Gesche­hene unge­sche­hen machen?“

So ähnlich muss es wohl auch Mar­kus Thöné von der Firma Quo­tec gegan­gen sein, der am 18.07.2008 eine E-Mail an alle seine 817 Wer­be­agen­tur­kon­takte schickte. Quo­tec ist Anbie­ter einer Bran­chen­soft­ware für Wer­be­agen­tu­ren und die E-Mailadressen sind wohl das Ergeb­nis jah­re­lan­ger Akquise der Firma Quo­tec gewe­sen. Bedau­er­li­cher­weise machte Herr Thöné den Feh­ler die E-Mail nicht an sich selbst zu adres­sie­ren und eben 817 bcc („blind car­bon copy“)-Empfänger hin­zu­zu­fü­gen, son­dern er hat die E-Mail AN 817 Emp­fän­ger gesen­det — was bewirkt, dass alle Emp­fän­ger die gesam­mel­ten E-Mailadressen aller ihrer Kol­le­gen erhiel­ten, die ein offen­sicht­lich flei­ßi­ger Ver­triebs­mit­ar­bei­ter gesam­melt hat.

(wei­ter­le­sen…)