Feeds:
Innlegg
Kommentarar

Archive for the ‘data’ Category

Farvel til Google Reader

Google Reader-logoEit par kveldar før Google Reader legg inn årane, har eg så vidt byrja å finne ut av kvar eg skal gjere av meg, med alle atterhald om at eg ombestemmer meg. Eg tippar at eg ikkje er den einaste som har venta på både finessar hjå alternativa og på kvar Reeder, gReader Pro og artsfrendar skulle ta vegen.

For frå 1. juli av er det altså slutt hjå Google. Og ettersom også eg har gjort meg avhengig av å kunne synkronisere mellom fleire apparat (du verda, det gjekk fort å ta dette for gjeve), er det vel på tide no å byrje å tenkje på å hive seg rundt.

Betalingstenestene Feedbin og NewsBlur har mange snakka om. Men etter at gratistenesta Feedly (registreringsfri Google-kopla konto med heilautomagikk) annonserte at dei skal få OPML-støtte snart, er heller ikkje dei så avskrekkande lenger. Reeder har snakka om ditt og dutt og meir til men ikkje om datt, og siste nytt derifrå er at den nye Mac-versjonen rett og slett ikkje finst enno. Dermed er det tydelegvis ReadKit som seglar opp som lokal lesar i alle fall i starten, for ReadKit stør allereie no både ditt og datt men ikkje dutt, men derimot også dått, altså Feed Wrangler. Og medan gReader stør ditt men ikkje datt eller dutt, stør Press både ditt, datt og dått men ikkje dutt.

Ein siste tryggingskopi av RSS-lenkjene vart henta ut via Google Takeout i går kveld. At RSS er ein bra ting, har mange andre skrive utførlege utgreiingar om desse månadene. Og at verda går vidare utan Google Reader.

No prøver eg ut Feedbin, etter å leikt litt med Feedly fyrst. Brukargrensesnittet til Feedbin i nettlesaren er så bra at eg gløymer at eg ikkje er i ReadKit eller Reeder. Arkivet strekkjer seg til dels fleire år tilbake. Favorittane mine frå Google Reader kunne importerast frå starred.json i Takeout-tryggingskopien. Einskildstraumar kan merkjast for å gå automatisk via Readability. Og så finst det sikkert slikt eg kjem til å sakne etter kvart. Den tid, den sorg.

Read Full Post »

Ein uventa telefon frå tidsmaskina

Telefonen kom ikkje frå framtida, men nesten. For det var ein hyggjeleg mann hjå Apple i California som ringde, han sat og samla inn teknisk informasjon i samband med ein bøgg som plagar mange av oss.

TimeMachineGraphicBackupsystemet Time Machine (her: på OS X 10.8.2) plagar nemleg mange av oss med at alt går veldig sakte på visse nyare versjonar av operativsystemet. Til dømes kan det gå slik at under tryggingskopiering vert 37 MB kopiert over til backupdisk, så stoppar overføringane medan Time Machine tygg på noko mystisk noko, og det stoppar opp slik i kanskje ein time, før dei resterande 1,5 GB fyk over på få sekund. Sjølv å tryggingskopiere berre ein handfull mega kan ta ulideleg mykje tid.

La meg presisere at det også er mange som ikkje har dette problemet. Men nokre av oss er altså mellom dei uheldige. I mitt tilfelle tydde eg til denne terminalkommandoen (med eit veldig vidt terminalvindauge) for å sjå på kva Time Machine jobba med:

sudo fs_usage -w | grep backupd

Det eg fann der, var at jau, undervegs i kopieringa finn plutseleg Time Machine ut at no skal vi tyggje på alle småfilene i tidlegare backup av /.DocumentRevisions-V100, og kvar einaste ei av desse småfilene skal vi tyggje på i femten sekund kvar, eller kor lenge det no var. For meg fungerte det å stappe denne mappa inn i eksklusjonslista til Time Machine, den fyrste tryggingskopieringa etterpå gjekk sakte, resten gjekk kjapt. Straks eg fjerna mappa frå eksklusjonslista igjen, kom problemet tilbake frå andre tryggingskopiering av, men straks eg ekskluderte mappa på nytt, vart eg kvitt problemet frå andre kopiering av som sist. Slik er det begge Macane eg disponerer. Begge bruker backupdisk på kabel (USB, FireWire) som er stappa rett inn i Macen.

Den nemnde mappa er staden der databasen for dokumentversjonar i OS X 10.7 og 10.8 ligg (her om dei aktuelle forbetringane i OS X 10.8 Mountain Lion), så dersom ein er oppteken av å sikre dokumentversjonar, er det jo litt dumt. Men slikt er trass alt ikkje det aller viktigaste på disken min. Det viktige er dei ferdige dokumenta, ikkje at eg endra eit komma onsdag kl. 17:43 førre veke.

På brukarforumet til Apple finst det ein lang tråd om problemet, det kan sjå ut til at ulike brukarar opplever det på ulike måtar, og at det ikkje finst éi løysing som fungerer for alle. Nokre av dei som har skrive på forumet, fortel at dei har vorte oppringde av Apple-ingeniørar, og no var det altså min tur. Han fekk nokre utfyllande detaljar om korleis eg har kopla saman Mac og backupdisk, om korleis eg omgår problemet og kan framprovosere det igjen, og så fekk han ei stadfesting på nokre andre ting eg hadde skrive. Og berre for å seie det: Nei, han bad ikkje om kredittkortnummer eller noko anna muffens. 🙂

Mannen takka for svara mine, og eg takka for at han hadde spurt. Noko av det litt spesielle er at vi brukarane på denne måten får eit innblikk i at Apple, som til vanleg er veldig stille av seg, faktisk prioriterer å jobbe med ei spesifikk sak. Derfor vart dette ein telefon frå tidsmaskina i dobbel tyding. Men det gjev også eit nærare og meir menneskeleg forhold til varemerket når brukarane vert direkte konsulterte av dei som utviklar produktet. Og at det i tillegg har sin eigen vesle reklameeffekt av typen «øyh, dei tek oss på alvor», er sjølvsagt ikkje noka ulempe.

Read Full Post »

Vi kan vel alle trå i baret av og til. Denne gongen er det Oslo tingrett som har vore uheldig. Før jul sende dei ut e-post til meddommarane sine, med 1294 synlege e-postadresser berre i den sendinga som eg fekk sjå, og bartrakkinga stoppa ikkje der. Men før eg fortel om det, skal eg fortelje litt bakgrunn.

Eg har ei e-post-adresse som nesten ingen veit om. Opp gjennom åra er det mange som har slurva med kva dei har skrive til venstre for krullalfaen når dei sender e-post, og nokre av dei som slurvar, sender dermed e-post til meg i staden for til den som skal ha e-posten. I innboksen min har det landa både forsikringspapir, kundebrev, private nakenbilete (ikkje spam), hotellreservasjonar og skumlare saker. Eg skreiv ein bloggpost om det for nokre år sidan.

Forvarsel frå Fylkesnemndene

No er det altså Oslo tingrett sin tur. Men allereie i starten på desember kom det eit forvarsel, då eg mottok ein e-post med tittel «Oslo1- forespørsel om verv som alminnelig medlem i fylkesnemnda». Sendar var Fylkesnemndene for barnevern og sosiale saker, som skreiv: «Denne forespørselen sendes ut til et tilfeldig utvalg personer plukket fra domstolenes lister over meddommere for samme utvalgsperiode.»

Sidan eg bur i Trondheim og dessutan aldri har brukt denne adressa, forstod eg det måtte vere ei klassisk feilsending, så eg sa ifrå om dette, men fekk aldri noko svar. Det var likevel klart at no hadde adressa mi hamna i eitt eller anna register.

Oslo tingrett

Så kom fredag 21. desember: Velkommen som meddommer i Oslo tingrett! Det var tre spesielle forhold med denne e-posten frå Oslo tingrett. Det eine var sjølvsagt at mi adresse stod på mottakarlista. Her har anten meddommaren eller tingretten begått ein tastefeil, og eg hadde altså allereie sagt ifrå til Fylkesnemndene, men kjelda til adressene inneheld framleis den same feilen.

Men det andre spesielle med denne e-posten var at adressa stod synleg i mottakarfeltet (To-feltet). Heile 1294 adresser stod synlege der, medrekna nokre adresser som er på formatet telefonnummer@netcom.no og liknande. Nok ein gong er det altså nokon som ikkje har fått god nok opplæring i bruk av To- og Bcc-felt, og denne gongen resulterte det i at 1294 meddommarar, herunder også minst éin som ikkje er meddommar, fekk offentleggjort og distribuert e-postadressene sine. Vel å merkje omfatta desse 1294 alfabetisk sorterte adressene i denne e-posten berre fire og ein halv bokstav i alfabetet, så berre tingretten veit vel kor mange adresser dei faktisk har offentleggjort.

Eg veit ikkje om det er teieplikt eller andre plikter involverte her, det må nesten andre uttale seg om, som veit kva slags vilkår adressene har vorte innsamla på. Men om ikkje anna, så er vi no ein heil bøling med personar som har vorte ekstra utsette for spam, virus og andre masseutsendingar.

Og kven veit kva som kjem til å lande i innboksen min frå Oslo tingrett i framtida? For den tredje saka som var noko spesiell med denne e-posten, var at det også var umogeleg å seie ifrå til sendaren om adressefeilen. Oslo tingrett hadde nemleg sendt frå ei noreply-adresse. Då kunne dei like gjerne ha ringt til meg med einvegstelefon der dei kunne snakke men eg ikkje kunne svare.

Tilbakekalling og orsaking

Kort tid etterpå kom det ny e-post frå Oslo tingrett. Eg skal sitere han fullt ut, for han var rimeleg kort:

No reply, Oslo tingrett ønsker å kalle tilbake meldingen Velkommen som meddommer i Oslo tingrett – vennligst ikke svar på denne mailen..

Nei, å svare på mailen ville jo vere vanskeleg, for det var framleis noreply-adressa som var sendar. Men eg forstår kvifor dei ikkje ville at nokon skulle svare. Svaret kunne jo fort ha gått ut til alle dei 1294 adressene som framleis låg synlege i To-feltet. Det er sjølvsagt prisverdig at dei ville tilbakekalle meldinga, men dei må tidleg ha oppdaga problemet med dette, for etter endå éin og ein halv time kom denne:

Kjære meddommer i Oslo tingrett

Vi har tidligere i dag sendt ut en epost til dere, med invitasjon til informasjonsmøter på nyåret. Beklageligvis var epostadressene til andre meddommere i samme forsendelse også synlige. Da vi ble oppmerksomme på denne arbeidsulykken, forsøkte vi å tilbakekalle epostene. Dette var heller ikke et vellykket tiltak. Vi ber så mye om unnskyldning for dette, og forsikrer om at det ikke skal skje igjen. Enkelte har også hatt problemer med å lese eposten fra oss, på grunn av formateringen av teksten. Vi håper denne eposten med ren tekst er lesbar for alle.

No var forresten alle mottakarane skjulte.

Facebook

Det kan vere fort gjort å tabbe seg ut på e-post. Alle har vi vel sendt noko i feil retning ein og annan gong. Eg har også gjort liknande ting som denne masseutsendinga, ein gong på 90-talet då eg skulle sende ein e-post til ein heil haug med folk på arbeidsplassen, og kom i skade for å setje desse adressene nettopp i To-feltet, sjølv om eg hadde sikta meg inn mot Bcc-feltet, som eg elles var flink til å bruke.

Eg er sikker på at det sit ein fyrst sveitt og i ettertid ikkje heilt lite flau person i administrasjonen på Oslo tingrett, som no har lært om Bcc på den ubehagelege måten. Men dette er neppe den same personen som har vedteke at alt skulle sendast frå noreply-adresse. Og på grunn av den noreply-adressa er det framleis ingen i Oslo tingrett som veit at dei har registrert feil e-postadresse på ein av meddommarane sine.

Så kva gjer då ein ny meddommar som lurer på kva det går ut på å vere meddommar, når ingen kan skrive e-post til tingretten og spørje om det? Det har Oslo tingrett faktisk tenkt på. I e-posten fortel dei at meddommarane kan oppsøkje Facebook-sida www.facebook.com/meddommerioslo, stille spørsmål der, «og få svar samme dag».

Sidan eg ikkje er på Facebook, er det sikkert like greitt at eg ikkje er meddommar.

Facebook-skjermbilete

Oslo tingrett på Facebook: «Skulle noen oppleve at epostadressene kommer på avveie, så vil vi også veldig gjerne få beskjed om det.»

Read Full Post »

Stillbilete frå HD-video

I ein tidlegare bloggpost såg eg m.a. på korleis ein kan lage fotografi av videoopptak. Dette var gamlesorten av videoopptak, rett nok digitalt, altså, men med standardoppløysning.

Seinare har eg fått prøve meg på HD-opptak, nærare sagt AVCHD med video i H.264. Der er prosessen enklare.

På minnekortet til videokameraet navigerte eg meg ned i AVCHD-mappa og heilt ned til STREAM. Der fann eg videofiler med suffikset .MTS, som kan lesast av VLC. Den fila eg ville hente ut eit bilete frå, heitte 00070.MTS. Det er eit opptak frå ein gong vi flaug over Duisburg, og for ordens skuld skal eg nemne at dette korkje var under avgang eller landing, at skiltet med «Fest setebeltet» ikkje lyste, og at videokameraet korkje hadde radiosendar eller radiomottakar.

I Video-menyen til VLC finst det noko som heiter «Skjermbilete» (hurtigtast ⌥⌘S), som lagrar eit bilete av noverande videobilete. Biletet landar som standard i Bilder-mappa på Macen. Så enkelt kan det gjerast, altså. Ja, hugs berre at dersom opptaket er interlaca, så kan det vere lurt å deinterlace det (skru på «linjedobling» og vel metode, t.d. «discard», men helst ikkje «blend») før du lagrar stillbiletet. I VLC-innstillingane kan ein velje kva slags format biletet skal lagrast som, og ein kan velje ei anna mappe å lagre det i.

Den versjonen av videoklippet som eg har lasta opp til bloggen, er av lågare kvalitet og har dårlegare oppløysning enn originalen, og er også litt blassare i fargane enn originalen pga. rekomprimering i Handbrake. Eg har også dempa lyden med 21 dB.

Den mindre enkle måten

Eg gjorde det nok litt mindre enkelt enn VLC, fordi eg ville ha betre kontroll med kvaliteten på det biletet eg eksporterte. Eg skal nemne nokre detaljar rundt dette lenger nede i bloggposten, men her er min framgangsmåte:

Fyrst av alt brukte eg remux til å konvertere .mts-fila til ei MPEG4-fil utan å kode H.264-videoen på nytt (skifta berre konteiner, altså). Dette gjorde det enklare å handtere opptaket til annan slags bruk, ikkje berre i det vidare arbeidet med å lage stillbilete, men t.d. også då eg ville lage ein videoversjon til bloggen. I remux kan lyden i tillegg kodast om frå AC3 til AAC dersom det trengst. (I skrivande stund trengst det ved eksport til .mp4 for at QuickTime Player eller MPEG Streamclip skal takle fila, men ikkje ved eksport til .m4v.)

Deretter var eg ein tur (kall det omveg) innom QuickTime Player 7 Pro for å plukke ut nøyaktig det eg ville ha stillbilete av. Eg kopierte ut desse snuttane og lagra dei i ei sams .mov-fil, berre for å ha alt på éin plass. Dette er ein omveg som ein altså ikkje treng å ta.

Så opna eg denne mov-fila (eg kunne altså ha brukt den nemnde MPEG4-fila direkte) i MPEG Streamclip. Det var her eg skulle gjennomføre sjølve stillbilete-eksporten. Frå filmenyen valde eg «Export Frame». Der inni igjen kunne eg leike meg med interlaca og deinterlaca eksport. Det viste seg i mitt tilfelle at det gjekk fint å eksportere bileta interlaca utan at det vart artefaktar av det, uvisst kvifor, for opptaket var då visseleg interlaca.

MPEG Streamclip kan eksportere til ulike proporsjonar. Brukarrettleiinga (versjon 1.9.3b8) seier at ein skal velje «Pixel Aspect: Computer Graphics» dersom ein har tenkt å bruke biletet til foto, og «Pixel Aspect: Industry Standard» for bruk i video. Desse vala er tilgjengelege når «Frame Size» er sett til t.d. 16:9. Når eg vel «Frame Size: Unscaled», får eg det same resultatet som 16:9 og «Industry Standard». Skilnaden mellom alt dette er at uskalert/industristandard viser heile biletet, medan datagrafikk gjer alt ørlite breiare, slik at nokre få biletpunkt på kvar side hamnar utanfor biletet i eksporten. Videokameraet vårt er slik at det også tek vanlege fotografi undervegs, og når eg samanliknar, ser eg at fotografia liknar mest på det som brukarrettleiinga seier eg ikkje skal velje: uskalert/industristandard. Utsnittet vert same kva ørlite ulikt mellom videoeksport og fotografi, ser eg (fotografiet ser ut til å zoome ørlite inn), men proporsjonane ser ut til å vere dei same som foto dersom eg vel uskalert/industristandard, medan «Computer Graphics» gjev litt andre proporsjonar. Skilnaden er neppe merkbar om ein ikkje veit kva ein ser etter.

Er det nokon som veit kva som er greia her? Eg trudde at 16:9 i HD-video faktisk var 16:9, til og med med kvadratiske biletpunkt, slik at det ikkje skulle vere nokon skilnad mellom video og fotografi.

I MPEG Streamclip kan ein også velje gamma ved eksport: 1,8 eller 2,2. Når ein vel 1,8, liknar det mest på videobiletet (slik det ser ut i QuickTime Player 7 og X). Når ein vel 2,2, vert dei mørke partia litt mørkare (det vert skarpare kontrastar), og dette liknar mest på fotografia frå videokameraet. Eg ser litt an kva eg vil velje her. I praksis har eg eksportert dei fleste bileta med gamma 1,8 fordi dei elles ville ha vorte for mørke (typisk fordi det er videoopptak frå litt dårleg opplyste rom), men biletet nedst i denne bloggposten vart eksportert med gamma 2,2 fordi 1,8 vart for blast.

Det eine eller det andre, men i alle fall noko

Medan VLC kan eksportere som png og jpeg, kan MPEG Streamclip også eksportere som tiff, og ikkje minst kan ein justere kvaliteten på jpeg-eksporten. Ein jpeg-eksport frå VLC laga ei fil på 61 kB, medan MPEG Streamclip med beste kvalitet laga ei fil på 1,4 MB, begge med storleik 1920 × 1080.

Å lagre eit videobilete i VLC gjev det same utsnittet og dei same proporsjonane som uskalert/industristandard i MPEG Streamclip, og lysforholda vert som ved gamma 1,8 frå MPEG Streamclip.

Fotolabbar vil vel helst ha jpeg, men det går sjølvsagt også an å eksportere til tiff eller png for å kunne redigere ukomprimert t.d. i Photoshop før ein til slutt lagrar som jpeg der. Ved eksport frå VLC er png å tilrå, med konvertering i eit anna program som t.d. Photoshop, fordi jpeg-eksporten frå VLC er altfor kraftig komprimert for fotoalbum.

Fargeprofil og meir til

Det eksporterte jpeg-stillbiletet frå MPEG Streamclip eller frå VLC har ikkje fargeprofil. Men fargeprofil må ein ha, ikkje sant. Fargeprofilen er opplysningar i biletfila om korleis fargekodinga der skal tolkast. GraphicConverter kan setje inn fargeprofil utan å komprimere biletet på nytt. Gjer slik (engelske menyval i parentes, steg 6 er råka av ein bøgg i versjon 8.3, feilmelding er send – oppdatering 1.11.2012: feilen vert retta i neste versjon):

  1. Fil > Bla gjennom… (File > Browse…)
  2. Naviger til mappa der biletfila ligg, klikk «Åpne» (Open).
  3. Bileta i mappa har no dukka opp i eit vindauge i GraphicConverter. Marker biletet eller bileta som du vil gje fargeprofil.
  4. Under «Aksjo» («Action», tannhjulet) i verktylina: gå til Misc > Sett inn profil… (Misc > Insert Profile…)
  5. Naviger til mappa der fargeprofilane ligg. GraphicConverter har nokre profilar i Dokumenter > GraphicConverter > Profiles. Photoshop har òg fargeprofilar å leike med. Ulike fargeprofilar gjer at biletet ser forskjellig ut, men typisk vil du truleg leggje inn sRGB-profilen.
  6. Nytt høvet til å leggje inn EXIF-data med dato og klokkeslett for når biletet vart teke: Aksjon > Metadata > Sett EXIF dato… (Action > Metadata > Set EXIF Date…). Dette er den same slags tidsstempling som skjer automatisk i fotoapparatet ditt, og der har du sjølvsagt alltid korrekt klokke og korrekt dato, ikkje sant? Ikkje sant??
  7. Og til slutt, kvitt deg med miniatyrbilete og slikt dilldall: Aksjon > Misc > Fjern ressursgaffel (Action > Misc > Remove Resource Fork). Dette påverkar ikkje datadelen av biletfila (sjølve biletet), og er altså heilt ufarleg.

(Ein treng ikkje kalibrert skjerm for å setje inn fargeprofil, men det er ikkje noka ulempe med kalibrert skjerm dersom ein har tenkt å justere fargane og sånt, om ein så berre har brukt Systemvalg > Skjermer > Farger > Kalibrer… nokre gonger til ein har vorte van med å navigere der og har funne noko som ser bra ut.)

Heilt til slutt fyrte eg opp PhotoLinker og geotagga biletet.

Heilt heilt til slutt gjorde eg biletet mindre og fjerna fargeprofil og geotagging igjen før opplasting til bloggen, og då ser det slik ut:

stillbilete

Read Full Post »

Frå Safari til Google Reader

Summary in English at the bottom of the blogpost. The script extracts RSS feeds from the Safari bookmarks export (limited to feeds in the Bookmarks Bar and subfolders) and saves them in an opml file.

* * * * * * *

Eg har Safari som nettlesar i det daglege, og i Safari har eg også ein del RSS-bokmerke. Men når eg er på reisefot med iPad, bruker eg ein app som kommuniserer med Google Reader, det var visst litt praktisk. Eg kunne sjølvsagt konstant ha brukt berre Google Reader når eg sit ved datamaskina, men slik har det no ikkje vorte. Mellom anna fordi Google Reader ikkje tillèt mappe i mappe, og det er også meir tungvint å redigere bokmerka der. Men kven veit korleis eg les RSS i framtida.

I alle fall, til poenget: Eg var for lat til å leggje alle RSS-lenkjene mine frå Safari manuelt inn i Google Reader. I staden laga eg eit skript som trekkjer ut RSS-bokmerke frå bokmerkeeksporten i Safari 5.1 for Mac, og lagrar dei i ei opml-fil, som så kan importerast i Google Reader eller andre RSS-lesarar.

Fyrst, ha i bakhovudet at Safari viser talet på ulesne RSS-artiklar i ein parentes, men at dette gjeld berre for RSS-bokmerke som ligg i bokmerkelina. RSS-lenkjer som ligg i bokmerkemenyen, oppdaterer seg ikkje. Derfor hentar skriptet ut RSS-lenkjer berre frå bokmerkelina med undermapper.

Skjermbilete: Safari med RSS-bokmerke

Då eg tok skjermbiletet, hadde eg 220 + 3 ulesne artiklar. Som vi ser på biletet, er bokmerka mine til dels – men ikkje fullstendig – sorterte i mapper.

Det vi kan kalle 1. nivå, er sjølve bokmerkelina, som i seg sjølv er ei mappe (det ser du om du ser etter i bokmerkemenyen). Alt innhald som ligg direkte på bokmerkelina, er på 2. nivå. Der på 2. nivå ligg det eitt RSS-bokmerke i min Safari, det heiter «feed», og har 3 ulesne artiklar på biletet. Her på 2. nivå ligg også mappa «Nyhende» med 220 ulesne artiklar. Inne i den mappa har vi både lenkjer (den eine har 1 ulesen artikkel) og nye mapper. La oss kalle dette 3. nivå. Og den eine mappa på 3. nivå inneheld mapper på 4. nivå, desse mappene har namn etter årstal, og inni der finst fleire bokmerke igjen.

Det er heilt i orden å behalde denne strukturen i opml-fila, og vanlege RSS-lesarar taklar det. Heilt mot slutten av skriptet kan ein velje korleis ein vil gjere dette, om ein vil behalde heile mappestrukturen eller ikkje. Som standard er det stilt inn til ikkje å behalde heile strukturen, dette til ære for Google Reader.

For Google Reader liker altså ikkje mapper inne i mapper. Så sjølv om bokmerka overlever, må skriptet gjere noko med mappestrukturen som dei ligg i. Skriptet tek då vare berre på mappenamna på nivå 3. Dette tyder at når opml-fila vert importert i Google Reader, så er alt innhaldet frå mappene «2006», «2008», «2009», «2010» og «2011» samla i den mappa som desse årstala var grupperte under i Safari, men sjølve årstalssorteringa er borte. Bokmerka som ligg direkte på bokmerkelina (altså «feed») og bokmerke som ligg rett under «Nyhende», vil lande utanfor mappestrukturen i Google Reader.

Men skriptet kan altså også redigerast slik at fullstendig mappestruktur vert teken vare på. Det er berre å la vere å køyre tekststrengene gjennom «mappeslettingsubrutine». For å slette mapper på andre måtar er det elles denne subrutinen som må redigerast.

Og her er skriptet

(This is the Norwegian version. See below for the English version.)

#!/bin/sh
# Jardar Eggesbø Abrahamsen 19.8.2011, 15.10.2011, 1.3.2012
# https://jardar.wordpress.com/2012/03/10/fra-safari-til-google-reader/
# Skriptet tek føre seg av bokmerkeeksport frå Safari 5.1,
# og plukkar ut rss-lenkjene frå bokmerkelina og undermappene, ikkje 
# frå andre stader, og lagar ei opml-fil.
#
# LISENS
# Du har lov til å modifisere skriptet. Du har lov til å distribuere 
# modifikasjonen din, så sant han inneheld informasjon om kven som laga 
# det opphavlege skriptet, og så sant du ikkje krev betalt for det. Om 
# du ynskjer å distribuere skriptet eller ein modifisert versjon av det 
# under andre vilkår, eller inkorporere det i andre produkt, må du be 
# meg om løyve.
# Kontakt: abjaeg krullalfa gmail punktum com (eg les ikkje denne adressa kvar dag)

if [ "$1" = "" ] ; then
  echo
  echo "   safariopml filnamn.html"
  echo "   Det vil verte laga ei fil som heiter filnamn.opml"
  echo
  exit
fi

filnamn="$1"
nytt_filnamn=`echo "$filnamn" | sed 's/\.html$/.opml/'`

# Sile bort andre linkar enn feed-URL-ar, og ta vare på overliggjande mapper,
# fjerne hermeteikn frå mappenamn, skifte ut mappenamna med opml-taggar.
bokmerka=`cat "$filnamn" \
| grep -v 'HREF="[^f][^e][^e][^d]' \
| sed 's/<DT>//' \
| awk '/<H3 FOLDED>/ { gsub ("\"", "") ; print } ; !/<H3 FOLDED>/ { print }' \
| grep -e '^	*<H3 FOLDED' -e '^	*<A HREF' -e '</DL><p>' \
| sed 's/<H3 FOLDED>/<outline text="/
       s/<\/H3>/">/
       s/<\/DL><p>/<\/outline>/

# sed: gjere URL og linknamn om til to felt med TAB mellom
# awk: fjerne eventuelle hermeteikn i linknamna (Google Reader liker dei ikkje)
# sed: få på plass resten av taggane
       s/<A HREF="[^>]*>/&	/
       s/">	/	/
       s/<A HREF="//' \
| awk '/	feed:/ { gsub ("\"", "") ; print } ; !/	feed:/ { print }' \
| sed 's/	feed:/	<outline type="rss" text="" xmlUrl="feed:/
       s/<outline type="rss"[^	]*/&" title="/
       s/title="	/title="/
       s/<\/A>$/" \/>/'`

# ta vare berre på bokmerkeline-delen av bokmerka
hit=`echo "$bokmerka" \
| grep -n . \
| grep "^[0-9]*:	<outline" \
| head -2 | tail -1 \
| sed 's/:.*//'`
hit=$(($hit-1))

bokmerka=`echo "$bokmerka" | head -"$hit"`

# Fjerne tome mapper:
# Opnar med å slå saman liner.
# Så kjem sjølve fjerninga, og denne kjem så lenge der er noko å fjerne.
# Fjerninga må skje rekursivt pga mapper i mapper.

bokmerka=`echo "$bokmerka" \
| tr -d '\n'`
testdingseboms=`echo "$bokmerka" | grep "	*<outline text=\"[^\"][^>]*>	*<\/outline>"`
while [ "$testdingseboms" != "" ] ; do
  bokmerka=`echo "$bokmerka" \
            | sed 's/	*<outline text=\"[^\"][^>]*>	*<\/outline>//g'`
  testdingseboms=`echo "$bokmerka" | grep "	*<outline text=\"[^\"][^>]*>	*<\/outline>"`
done
# Det som vert fjerna, er <outline text="mappenamn"> og </outline>.
# Sjølve lenkjene er <outline type="rss"...

# Vi deler opp til liner igjen etter avslutta tagg, og fiksar &:
bokmerka=`echo "$bokmerka" \
| tr '>' '\n' \
| grep -v '^$' \
| sed 's/$/>/
       s/&/\&amp;/g'`

#####
# Google Reader taklar ikkje mappe i mappe.
# Denne subrutinen må køyrast dersom opml-fila skal inn i Google Reader.
#####
mappeslettingsubrutine()
{
# Slette mappeetikett på 1. nivå (1 TAB, "Bokmerkelinje") og på 2. nivå 
# (2 TAB, menyar/mapper i bokmerkelina).
# Merk at på dette stadiet er det berre mapper som har sekvensen "<outline text"
# Og berre mapper har ein eigen avsluttande tagg.
sed -E 's/^		?<outline text.*//
        s/^		?<\/outline>//

# slette mappeetikettar på 4. nivå og oppover (4 TAB og meir), tek 
# altså vare berre på hovudmappene i menyane
       s/^					*<outline text.*//
       s/^					*<\/outline>//' \
| grep -v "^$"
}

sistefiks()
{
# Ein siste fiks som gjer title- og text-attributtane identiske,
# slik det er i opml-eksportane frå Google Reader,
# og fordi eg las det her: http://www.therssweblog.com/?guid=20051003145153
sed 's/text="" //
     s/text="/title="/
     s/title="[^"]*"/& text="&"/
     s/"title=//
     s/""/"/'
}

{
cat << EOF
<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
	<head>
		<title>Safari OPML Export</title>
	</head>
	<body>
EOF

# For Google Reader, slett dei fleste mappenivåa:
echo "$bokmerka" | mappeslettingsubrutine | sistefiks

# Alternativt: ta vare på alle mappenivåa:
# echo "$bokmerka" | sistefiks

cat << EOF
	</body>
</opml>
EOF
} > "$nytt_filnamn"
  1. Eksporter bokmerka frå Safari (Arkiv > Eksporter bokmerker…), slik at du har fila «Safari-bokmerker.html».
  2. Kopier skriptet frå boksen over, lim det inn i eit tekstdokument som du lagrar som rein tekst og med filnamnet safariopml der du vil, typisk i ~/bin om det finst.
  3. I Terminal: chmod +x safariopml
  4. Rediger skriptet dersom det trengst. Som standard fjernar det mesteparten av mappestrukturen til ære for Google Reader, som nemnt over, men dette kan ein endre. Sjå kommentarar mot slutten av skriptet og ved «mappeslettingsubrutine».
  5. Køyr det slik: safariopml Safari-bokmerker.html
  6. No har du ei fil «Safari-bokmerker.opml» som kan importerast i ein RSS-lesar.

Eg reknar med at dei som har lese så langt som dette, også veit korleis dei skal chmod-e (punkt 3) og forhalde seg til skriptet elles, t.d. modifisere det etter eigne behov, så eg skriv ikkje noka meir utførleg rettleiing. Ekte datafolk vil same kva sjå at dette er eit amatørskript frå ein som har lært slikt på eiga hand, og som også har arbeidt med det i fleire omgangar.

Summary in English

  1. In Safari, export the bookmarks (File > Export Bookmarks…) to the file “Safari Bookmarks.html”.
  2. Copy the script from the box below, paste it in a text document that you save as plain text and with the name safariopml wherever you want, typically in ~/bin if it exists.
  3. In Terminal: chmod +x safariopml
  4. Edit the script as you need. By default it will remove the folder structure apart from any folders at the top level inside a folder that is found in the Bookmarks Bar. For reference, this means that although the RSS feeds are kept, the folders «2006», «2008» etc. in the screendump above will be removed, and all their contents will be found in a flat structure in the folder where all those subfolders were previously grouped. This is the default behaviour because Google Reader does not permit nested folders. The behaviour can be altered to keep the full folder structure, see comments near the bottom of the script and at the «folderdeletionsubroutine». Edit that subroutine to delete folders in other ways than described here.
  5. Run the script like this: safariopml Safari\ Bookmarks.html
  6. You now have a file “Safari Bookmarks.opml” that can be imported into an RSS reader.

The script has been tested with exports from Safari 5.1 for Mac. It extracts only RSS feeds found in the Bookmarks Bar and any subfolders of it. I’m just an amateur, so don’t expect to find a very sophisticated piece of code.

#!/bin/sh
# Jardar Eggesbø Abrahamsen 2011-08-19, 2011-10-15, 2012-03-01
# https://jardar.wordpress.com/2012/03/10/fra-safari-til-google-reader/
# The script uses a bookmarks file from Safari 5.1, extracts the rss 
# feeds from the Bookmarks Bar and its subfolders, and makes an opml file.
#
# LICENSE
# You are allowed to modify the script. You are allowed to distribute 
# your modification, provided that the modified version contains 
# information about the original author, and provided that you do not 
# make charges for it. If you wish to distribute the script or a 
# modified version of it under other conditions, or incorporate it into 
# other products, you must ask permission from the original author.
# Contact: abjaeg at gmail dot com (I don't read this address every day)

if [ "$1" = "" ] ; then
  echo
  echo "   safariopml filename.html"
  echo "   A file called filname.opml will be created."
  echo
  exit
fi

filename="$1"
new_filename=`echo "$filename" | sed 's/\.html$/.opml/'`

# Remove any other URLs than RSS feeds, keep the folder structure,
# remove quotes from foldernames, turn folder names into opml tags
bookmarks=`cat "$filename" \
| grep -v 'HREF="[^f][^e][^e][^d]' \
| sed 's/<DT>//' \
| awk '/<H3 FOLDED>/ { gsub ("\"", "") ; print } ; !/<H3 FOLDED>/ { print }' \
| grep -e '^	*<H3 FOLDED' -e '^	*<A HREF' -e '</DL><p>' \
| sed 's/<H3 FOLDED>/<outline text="/
       s/<\/H3>/">/
       s/<\/DL><p>/<\/outline>/

# sed: convert URL and linkname to 2 fields separated by TAB
# awk: remove quotes from linknames
# sed: the rest of the tags
       s/<A HREF="[^>]*>/&	/
       s/">	/	/
       s/<A HREF="//' \
| awk '/	feed:/ { gsub ("\"", "") ; print } ; !/	feed:/ { print }' \
| sed 's/	feed:/	<outline type="rss" text="" xmlUrl="feed:/
       s/<outline type="rss"[^	]*/&" title="/
       s/title="	/title="/
       s/<\/A>$/" \/>/'`

# keep only bookmarks that are found in the bookmarks bar
hitherto=`echo "$bookmarks" \
| grep -n . \
| grep "^[0-9]*:	<outline" \
| head -2 | tail -1 \
| sed 's/:.*//'`
hitherto=$(($hitherto-1))

bookmarks=`echo "$bookmarks" | head -"$hitherto"`

# Remove empty folders:
# 1) Merge lines.
# 2) Remove folders as long as there is something to remove.
#    The removal is recursive due to nested folders.

bookmarks=`echo "$bookmarks" \
| tr -d '\n'`
testthingy=`echo "$bookmarks" | grep "	*<outline text=\"[^\"][^>]*>	*<\/outline>"`
while [ "$testthingy" != "" ] ; do
  bookmarks=`echo "$bookmarks" \
            | sed 's/	*<outline text=\"[^\"][^>]*>	*<\/outline>//g'`
  testthingy=`echo "$bookmarks" | grep "	*<outline text=\"[^\"][^>]*>	*<\/outline>"`
done
# What is removed is <outline text="foldername"> and </outline>.
# The links themselves are <outline type="rss"...

# Reinsert newlines right after closed tags, and fix &:
bookmarks=`echo "$bookmarks" \
| tr '>' '\n' \
| grep -v '^$' \
| sed 's/$/>/
       s/&/\&amp;/g'`

#####
# Google Reader does not like nested folders.
# This subroutine must be run if the opml file is meant for Google Reader.
#####
folderdeletionsubroutine()
{
# Remove folder from level 1 (1 TAB, "Bookmarks bar") and level 2 (2 
# TAB, folders in the bookmarks bar).
# Note that at this stage the sequence "<outline text" uniquely identifies folders.
# And only folders have a separate closing tag.
sed -E 's/^		?<outline text.*//
        s/^		?<\/outline>//

# Remove folders from level 4+ (4+ TAB). In other words, keep only the names
# of the folders that are on the top level inside any folder placed in
# the bookmarks bar.
       s/^					*<outline text.*//
       s/^					*<\/outline>//' \
| grep -v "^$"
}

lastfixsubroutine()
{
# A last fix so the title and text attributes are identical,
# just like in the opml exports from Google Reader,
# and because I read it here: http://www.therssweblog.com/?guid=20051003145153
sed 's/text="" //
     s/text="/title="/
     s/title="[^"]*"/& text="&"/
     s/"title=//
     s/""/"/'
}

{
cat << EOF
<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
	<head>
		<title>Safari OPML Export</title>
	</head>
	<body>
EOF

# For Google Reader, delete most folder levels:
echo "$bookmarks" | folderdeletionsubroutine | lastfixsubroutine

# Alternatively, keep all folder levels:
# echo "$bookmarks" | lastfixsubroutine

cat << EOF
	</body>
</opml>
EOF
} > "$new_filename"

Read Full Post »

Vi leiger av og til film på CanalDigital GO, men så fungerte det plutseleg ikkje meir. Silverlight var installert, vi prøvde ulike nettlesarar, men ingenting fungerte. Trailerane fekk vi sjå, men ikkje den filmen vi hadde betalt for. Då stod det berre og spann på «Opening».

skjermbilete: opening

Så vi sende feilmelding om det, og prøvde i staden den tilsvarande tenesta hjå Telenor (Comoyo), men det fungerte ikkje der heller. Ikkje før Judith kom på at vi hadde jo begge fått oss ny Mac i det siste. Min gamle krasja plutseleg nokre månader i forvegen, og det var ikkje harddisken som gjekk, nei. Jøye meg for eit krasj det var. Sidan då hadde vi sett film på Judiths Mac, fordi eg ikkje hadde skaffa meg VGA- eller HDMI-overgang til min nye enno. Men så hadde ho nyleg fått seg ny Mac òg.

Så vi prøvde gamlemaskina hennar, som altså ikkje hadde krasja, men berre var sliten. Og sanneleg, då fekk vi sjå film.

Dette var eit mysterium. Canal Digital og Telenor hadde den same avspelingsløysinga, så det var vel ikkje så veldig overraskande at problemet var det same hjå begge to. Feilmelding vart send av garde også til selskap nr. 2: Alle innstillingar var identiske på den gamle og dei to nye maskinene som vi prøvde no, både på systemnivå og i nettlesarane. Det var også den same versjonen av både operativsystem, av nettlesar og av Silverlight. Og svaret (som kom frå Comoyo) då vi fortalde alt dette? Nei, at dette hadde dei aldri høyrt om før, så «da må du nesten sjekke innstillingene til mac og nettleser».

Vi forstod at vi måtte finne ut av dette på eiga hand.

Som sagt, så gjort. Og dette var det vi kom fram til:

Når ein kjøper ny Mac som skal erstatte den gamle, så pluggar ein den gamle (eller harddisken til den gamle, eller ein tryggingskopi av den gamle) inn i den nye under installeringa, og vips, så er alt overført, med innstillingar og programvare og alle dokument og heile greiene.

Og det var jo slik vi hadde gjort det. Eg hadde eit krasja hovudkort, men hadde plugga inn disken frå gamlemaskina og overført rubbel og bit. Judith hadde starta gamlemaskina si som ekstern disk (target mode) og plugga inn i nyemaskina. Eit litt gjennomtenkt Google-søk fann at folk hadde problem også med ein amerikansk videoleverandør som bruker Silverlight.

Løysinga er: Gå til /Library/Application Support/Microsoft/PlayReady og slett fila «mspr.hds». Og det er alt som skal til. Urøynd med å navigere på maskina? Gå til Finder og til menyen «Gå», vel «Gå til mappe…», og tast inn /Library/Application Support/Microsoft/PlayReady (pass på skråstrek også heilt i starten).

PlayReady-mappa

Det er DRM-systemet PlayReady i Silverlight som er problemet. Tydelegvis vert opphavsretten verna så godt at dersom Silverlight på ei bestemt datamaskin fyrst har registrert at ein har sett film på denne datamaskina, så er det denne bestemte datamaskina som gjeld. Å flytte DRM-fila til ei anna maskin (som ved overføring av diskinnhald ved nykjøp) fører dermed til at ein ikkje får sett film før ein slettar fila slik at Silverlight må lage ny. For Silverlight lagar ikkje ny fil sånn utan vidare når den gamle ikkje fungerer.

Kanskje Comoyo og Canal Digital skal få lenkja til denne bloggposten, for no har vi i alle fall funne ut av det.

Oppdatering 22.2.2012:
Comoyo las bloggposten, sende lenkja vidare til dei andre på kundeservice, og gav oss ein gratis film som takk for innsatsen. Eg har ikkje fått tilbakemelding frå Canal Digital enno om dei har lese bloggposten, men dei har refundert filmen vi ikkje fekk sett. Takk til begge!

Read Full Post »

Når biletet er vidare enn det er

Biletformatet 4:3 for video er ikkje 4:3, og 16:9 er ikkje 16:9. Det vil seie, ved overgangen til HD er 16:9 likevel 16:9, men i standardoppløysning (SD) er både 4:3 og 16:9 eigentleg litt vidare. Proffane som eventuelt les dette, får vere tolmodige med meg. Eg er ikkje noko meir enn ein sjølvlærd amatør, og det eg skriv her, er meir unøyaktig og mindre fagleg enn faget fortener.

I alle fall. Det var då eg ville lage stillbilete av videopptaka mine (SD) for nokre år sidan at eg kom bort i dette problemet. Eg hadde nokre videoklipp med flotte motiv som fotoapparatet ikkje hadde fått med seg, så eg laga stillbilete, eksporterte til jpeg, og passa på at biletformatet var nøyaktig 4:3. Sjølvsagt var eg budd på at det skulle verte dårlegare bilete enn frå eit fotoapparat, men eg hadde ikkje venta at folk skulle verte for smale i andletet. Dette fenomenet er også relevant for andre typar arbeid, til dømes:

  1. når ein skal lage stillbilete frå SD-videoen, som substitutt for fotografi,
  2. når ein skal lage mpeg4-eksport el.l. (kvadratiske biletpunkt) av SD-videoen sin,
  3. når ein skal bruke stillbilete frå fotoapparat el.l. som del av SD-videoeprosjektet,
  4. når ein skal bruke video frå fotoapparat/mobiltelefon eller (nedskalert) frå HD-videokamera som del av eit SD-videoprosjekt
  5. når ein skal ta ein SD-video og oppskalere denne i eit HD-videoprosjekt.

Fyrst det som eg allereie visste: Både fotoapparat og HD-videobilete på t.d. 1920 × 1080 har kvadratiske biletpunkt. Eit godt, gamaldags SD-bilete har ikkje det. Eit SD-bilete (PAL) har 720 biletpunkt i breidda og 576 biletpunkt i høgda, same om det er eit 4:3-bilete eller eit 16:9-bilete. Poenget er at desse biletpunkta er avlange, dei er breiare enn dei er høge. Dersom vi lèt biletpunkta vere kvadratiske, vil 720 punkt i breidda verte for smalt i begge tilfella (men særleg smalt for eit 16:9-bilete). Dette er heilt slik som det er venta å vere.

For å illustrere dette kan vi sjå på eit stillbilete som er laga av eit videoopptak, som kompensasjon for at eg ikkje hadde fotoapparatet parat. Det er henta frå eit 4:3-opptak der motivet uoppfinnsamt nok er ei DVD-plate, filma beint på. Denne plata skal sjølvsagt vere heilt rund, men når vi lèt biletet vere 720 kvadratiske biletpunkt breitt, vert ho for smal. Eg har lagt ein raud og heilt rund sirkel rundt som referanse.

Biletet er altfor smalt.

Dette er altså ikkje noka overrasking. Eg visste allereie at biletpunkta i eit SD-videosignal er litt breiare enn dei er høge. Bileta over er slik det ser ut dersom vi ikkje kompenserer for dette, men læst som om biletpunkta er kvadratiske.

Dersom vi strekkjer ut dei 720 punkta til ei breidd som svarer til 768 kvadratiske punkt (fordi 576/3·4=768), får vi akkurat 4:3. Strekk dei ut til 1024, og vi får akkurat 16:9. Men det er her det er lett å gå i fella. Her er biletet i nøyaktig 4:3-format:

Biletet er framleis litt for smalt.

Nettopp. Biletet er mykje betre, men framleis er det litt for smalt. Og det er altså her der er lett å gå i fella. Saka er at av dei 720 avlange biletpunkta i breidda er det i eit SD-bilete (PAL) berre dei 702 i midten som utgjer 4:3-biletet, eller 16:9-biletet, då, for dei som har litt meir moderne opptak. Dei resterande 9+9 punkta kjem altså utanfor fjernsynsbiletet. Grunnen til at det er gjort på denne måten, er at tradisjonell fjernsynsteknologi kjapt sagt trong litt å gå på, og då var det greitt å kunne beskjere tv-biletet litt på denne måten. Derfor dette ekstraområdet til venstre og høgre (overscan heiter det visst).

Eg som ville lage jpeg-stillbilete med kvadratiske biletpunkt, måtte dermed strekkje ut videobileta frå 720 punkt til tilsvarande ca. 787 kvadratiske punkt i breidda for 4:3-bilete (QuickTime Player 7 hintar om 786,667). Eit 16:9-bilete har tilsvarande 1048 punkt i breidda. Då vert bileta korrekt proporsjonerte, men dei vert altså også vidare enn respektive 4:3 og 16:9. På biletet under ser vi dette, eg har lagt inn ei ramme rundt sjølve 4:3-området.

Korrekte proporsjonar.

Å eksportere stillbilete er i og for seg enkelt nok. I fleire program er det vel til og med eit eige menyval for det, og vi treng ikkje å tenkje på biletpunkt og sånt i det heile teke. Men dei siste åra har eg redigert video i Final Cut Express, som Apple nyleg har skrota til fordel for noko nytt og mindre. I FCE har eg brukt å lage ein sekvens («del-film») der klippa er einskilde stillbilete, som eg eventuelt også har deinterlaca. Dette har eg så eksportert til DV i ei QuickTime-fil. Med QuickTime Player 7 Pro kan eg eksportere frå slike DV-filer (eller frå vanleg DV-fil med video i) til jpeg-bilete, og før ein ordnar den eksporten, kan ein i teorien gå til eigenskapane for filmen (⌘J), og endre «blendaropninga» til hovudsporet (les: beskjering og proporsjonar).

No synest det som om min versjon av programmet (7.6.6 på Mac OS X 10.6.8 i skrivande stund) har litt problem med å vere konsistent her, men «Kodede bildepunkter» gjev 720-biletet (det som er altfor smalt), medan dei andre innstillingane i teorien skal kunne gje 768-biletet (det som er litt for smalt), 787-biletet (eller kanskje i praksis 786, innstillinga «Produksjon») eller eit beskore 4:3-bilete (768 i breidda) med korrekte proporsjonar. Skulle programversjonen ha hikke, så passar ein berre på at heile biletet viser (altså at det ikkje er beskore), og så gå til PAL-sporet og passe på at biletet er 576 punkt høgt og samstundes 786/787 punkt breitt (eller 1048 for 16:9-bilete).

Ja, og om eg no ikkje deinterlaca i utgangspunktet men treng å gjere det no, så kan eg huke av for «høy kvalitet» + «enkeltfelt» i QuickTime Player 7 før eksport av «Film til bildesekvens» (merkeleg nok fungerer ikkje slik deinterlacing for videoeksport, berre på bileteksport, prøv heller JES Deintertlacer til videobruk). Ein sjekk av storleiken på eksporterte bilete er òg lurt. Merk at desse bileta ikkje har fargeprofil. Men redigerer du bileta i iPhoto, får dei fargeprofil tilsvarande skjermprofilen din. (Oi oi, no får grafikkproffane låkt i magen. Det er betre å tilordne fargeprofil t.d. i Photoshop eller noko. GraphicConverter kan visst tilordne fargeprofil utan å rekomprimere, om eg har forstått rett.)

Og om ein vil eksportere til mpeg4 eller noko anna med kvadratiske biletpunkt, så må ein tenkje på proporsjonane på same måten.

Her er eit stillbilete henta frå eit amatørvideoopptak av ein kjend tysk visesongar som bukkar etter konserten sin (klikk her for bloggposten om den konserten). Utydeleg vert det når det er videobilete, men fotoapparatet mitt var ikkje framme, og ikkje hadde det god nok zoom heller, så dette vart den naudløysinga som fungerte, og minnet er berga, om enn med låg oppløysning:

Visesongar med korrekte proporsjonar.

Men dette var altså berre to av punkta i lista over: lage stillbilete eller mpeg4 el.l. av videobilete, dvs. når ein i utgangspunktet har avlange biletpunkt og skal over til eit format som har kvadratiske biletpunkt.

Det finst tre punkt til på lista. Punkt nr. 3 og 4 handlar om å bruke materiale med kvadratiske biletpunkt i eit miljø med avlange punkt, punkt 5 på lista handlar igjen om å bruke materiale med avlange biletpunkt i eit miljø med kvadratiske biletpunkt. Eg skal ta alt dette meir eller mindre under eitt her. Og merk at eg ikkje veit korleis saker og ting fungerer i iMovie, Premiere, Final Cut Pro X (som eigentleg berre er ein slags iMovie) eller Final Cut Pro (som var eit proff-program). Eg kjenner berre Final Cut Express 3.5 og 4.0.

Dersom ein har eit SD-prosjekt og vil bruke eit stillbilete t.d. frå fotoapparatet i det videoprosjektet, så må ein vere merksam på dette – og la oss for dømet si skuld rekne med at biletet er i eksakt 4:3-format, og at prosjektet også er 4:3-format:

Fotografi har kvadratiske biletpunkt. Dette veit Final Cut Express, og kompenserer for det. La oss derfor tenkje oss at fotografiet har ei oppløysning på 768 × 576 biletpunkt. Dette er eksakt 4:3. Her er det Final Cut Express gjer ein feil: Fotografiet vert lagt inn tilsvarande 720 avlange punkt i breidda, dvs. at fotoet dekkjer absolutt heile området til videobiletet. Hugs at 4:3-området til tv-biletet eigentleg berre utgjer 702 av desse 720 avlange punkta. Dermed vil folk som er avbilda på fotografiet, verte ekstra breie i andletet, fordi fotografiet vert strekt utanfor 4:3-formatet.

Det same skjer dersom ein importerer ein videosnutt frå eit fotoapparat. Dette har firkanta biletpunkt, og videobiletet der har ikkje noko ekstraområde på sidene. Final Cut Express vil likevel behandle det som eit vanleg videoklipp med ekstraområde på sidene, og dermed vert folk litt for breie i andletet. Slik var det då eg skulle redigere eit 4:3-prosjekt der eg også trong eit 4:3-klipp frå eit fotoapparat. Løysinga var å redusere breidda på klippet til 0,975 gonger original breidd. I Final Cut Express gjer ein dette i Distort-delen av Motion-fana. (Eit anna prosjekt gjorde eg ferdig før eg oppdaga dette. Ja ja, veldig mykje vidare vert ikkje folk av det.)

Om ein vil ta eit SD-prosjekt i DV-format og oppskalere dette i ein HD-sekvens, får ein det motsette problemet: Final Cut Express trur at dei 720 biletpunkta utgjer breidda i eit 3:4-bilete (eller 16:9), dermed vert folk for smale i andletet. Korleis ein gjer det, er kanskje ei smakssak, eg veit ikkje. Det ser i alle fall veldig likt ut for mine augo, anten eg strekkjer ut Distort-punkta på x-aksen frå 360 (halvparten av 720) til 369,231 (som er 720/702 gonger større enn 360), eller om eg justerer Aspect Ratio-variabelen til null og strekkjer ut Distort-punkta til 393,33 (som er 786,67/720 større enn 360), eller om eg justerer Aspect Radio-variabelen til -9,259.

Men korleis den Aspect Ratio-variabelen eigentleg skal reknast ut, har eg ikkje funne ut for visst, for dokumentasjonen er noko mangelfull. Når eit SD/DV-prosjekt vert stappa inn i ein sekvens med oppløysning 1920 × 1080, vert Aspect Ratio automatisk sett til -6,67, noko som strekkjer ut dei 720 biletpunkta til eit område som svarer til 768 kvadratiske punkt i HD-sekvensen (pluss oppskalering i tillegg). Ein PAL-pixel er sjølvsagt ikkje heile 6,67 gonger så brei som han er høg. Derimot ser eg at 768/720=1,0667. Har det noko med saka å gjere? Slik at dersom eg vil bruke Aspect Ratio å strekkje ut 720 PAL-pixlar til 786,667 i breidda, så set eg aspect ratio til -(786,667/720-1)*100 = -9,259? Det såg i alle fall greitt ut.

Same kva, Apple slakta nyleg både Final Cut Express og Final Cut Pro, så spørsmålet er ikkje så aktuelt lenger. Dessutan er det meir eller mindre slutt på uredigerte SD-prosjekt her i garden. I praksis har eg berre utfordringa med eventuelt å konvertere ein del SD til HD, og kven veit kva slags program eg kjem til å bruke til dette.

Read Full Post »

Stavekontroll i Pages

Norsk stavekontroll i Pages på Mac OS X er framleis noko som ein må installere sjølv. Til gjengjeld er det lett å installere, og det er så gratis at eg eigentleg burde bruke stavekontroll oftare.

Eg byrja å kladde denne bloggposten for nauta lenge sidan, men har sete og venta på at iWork ’09 skulle verte utdatert, men så har det ikkje skjett, og i mellomtida har både den eine og den andre spurt om stavekontroll. Ikkje minst dukkar det med ujamne mellomrom opp folk som forvillar seg til eit anna innlegg her etter Google-søk som «norsk ordliste iwork» og «norsk stavekontroll mac». Så då er det kanskje på tide å skrive noko om det.

Det eg skriv her, gjeld Pages ’09 og Mac OS X 10.6, Snow Leopard. Frå og med denne versjonen av operativsystemet er det lagt inn støtte for hunspell-ordbøker (sånne som kan brukast av OpenOffice.org), og oppskrifta er:

Gå til hunspell-sida og klikk på «Dictionaries», så kjem du til ordbokssida til OpenOffice.org. Der er det berre å laste ned av hjartans lyst.

Det som ligg der under «Norwegian» pr. i dag, er ein samla pakke for nynorsk og bokmål. Pakk ut denne zip-fila, finn t.d. nynorskpakken inni det som du nettopp pakka ut (han heiter nn_NO.zip, bokmålspakken heiter nb_NO.zip), pakk ut denne igjen, og finn .dic- og .aff-filene.

Desse filene skal no flyttast til mappa «Spelling» som ligg i ei av mappene som heiter «Bibliotek». Eg plar leggje slikt i Bibliotek-mappa på heimekatalogen min. Finst ikkje Spelling-mappa, kan du lage henne. (Ryktet seier at Mac OS X 10.7 ikkje kjem til å vise Bibliotek-mappene direkte. I Finder kjem du i så fall til dei ved å «Gå til mappe» (⇧⌘G) og taste inn ~/Library for mappa i heimekatalogen, eller /Library for den globale mappa.)

No kan den norske stavekontrollen brukast i alle program som kan bruke stavekontroll frå operativsystemet. Her kjem nokre ord om korleis vi får stavekontrollen til å fungere i Pages. Ta omstart på Pages, og du er så mykje i mål at berre detaljane står att:

Hugs at for at stavekontrollen skal fungere, må Pages vite at det er norsk du prøver å skrive. Det vel du i Inspektør > Tekst > Mer, som vist på biletet. Ver merksam på at denne innstillinga ikkje gjeld for dokumentet generelt, men for akkurat der du har skrivemerket ditt. Så om du vil at eit heilt avsnitt skal verte rekna som t.d. bokmål, så må du markere teksten og velje bokmål.

Eller endå betre: Når du har valt språk for (heile) avsnittet, så definer den aktuelle avsnittsstilen på nytt, ved å klikke på den no raude trekanten ved stilnamnet og velje «Definer stil fra markering på nytt». (Dersom du ikkje ser lista med stilar, så trykk ⇧⌘T.)

Skriv du andre språk innimellom, kan du definere ein eigen avsnitts- eller teiknstil for t.d. engelsk.

Vil du ha norsk som språk også i nye dokument, kan det løne seg å lagre ei tom malfil der du har definert stilane som du vil: Arkiv > Arkiver som mal. Og vil du at nye dokument automatisk skal velje denne malen, så gå inn i Pages > Valg (eller ⌘,) og vel dette der.

Orddeling fungerer ikkje med denne løysinga. Det finst noko som heiter hyph_nn_NO.zip i det som vart lasta ned i stad, men Mac-en bryr seg ikkje om det som ligg der. Hadde han brytt seg om det, måtte vi i alle fall ha passa på å krysse av for orddeling i Inspektør > Dokument, og sett til at orddelinga ikkje er avslegen i for det aktuelle avsnittet i Inspektør > Tekst > Mer. Men slikt får ein inntil vidare heller more seg med på andre språk enn norsk.

Og til slutt:
Akkurat når eg skal trykkje på «Publiser», så kjem Multilingual Mac med ei lenkje til ei side som byr på ein fiks ferdig pakke med norsk stavekontroll. Det fylgjer også med norsk-engelsk og engelsk-norsk ordbok til Ordliste-programmet. Men når eg fyrst har skrive denne bloggposten, så kan eg like gjerne trykkje på «Publiser» likevel.

Read Full Post »

Unicode for amatørar

I ein tidlegare bloggpost tok eg føre meg det å skrive IPA-teikn (lydskrift) på ein Mac. Under betatestinga av tastaturoppsettet som er nemnt der, var det ein brukar som hadde sett seg ned med Word, hadde valt ein IPA-font, og byrja å skrive, men då kom det berre vanlege norske bokstavar. Vedkomande hadde gløymt å endre til IPA-tastaturoppsett.

Det eg skriv om Unicode her, er meint for eit publikum som ikkje har den aller største teknologiske kompetansen (og det er også skrive av ein som ikkje akkurat er ekspert), men sjølv om det til tider er veldig forenkla og amatørmessig, kan somme kanskje ha nytte av det likevel.

Hylleplassar

Det finst mange skriftteikn i verda, og det er ikkje plass til alle på dette vesle tastaturet.

Fyrst nokre ord om tastaturet. På tastane er det bokstavteikn, talteikn osb. Men tastaturet veit sjølvsagt ikkje kva slags bokstavar som er avbilda på dei ulike tastane. Ein kan samanlikne det med at vi leiter fram ein tusj og endrar G-tasten til Q og U-tasten til Ü. Sjølvsagt vil ikkje datamaskina oppdage dette.

I staden opererer tastaturet med tastenummerering, slik at det som menneska kjenner att som G-tasten, er tast nr. 5, medan U-tasten er tast nr. 32, P-tasten er tast nr. 35 osb. Og for å gjere det enkelt for oss menneska har fabrikantane skrive bokstavteikna på tastane, slik at også vi får eit hint om kva vi steller i stand når vi trykkjer på dei ulike tastane.

Når vi trykkjer på det som vi kjenner som P-tasten fordi vi vil skrive ein liten p, seier tastaturet til maskina: «Hei, eg har ei oppgåve til deg. Nokon har nettopp trykt på min tast nr. 35, kva vil du gjere med den saka?»

Maskina seier: «Tast nr. 35? La meg sjå etter i registeret mitt. Jau, tast nr. 35, og utan caps lock eller andre tastar, berre tast nr. 35? Vent litt, eg skal slå opp i registeret mitt over tastar og bokstavar her. Ja, her står det, ja: Eg skal hente fram bokstaven på hylleplass nr. 112.» (Det tekniske ordet for hylleplass er «kodepunkt».)

Så går maskina bort til bokstavlageret og seier: «No kjem eg og hentar deg, du vesle bokstav på hylleplass nr. 112.» Alt etter kva for ein font som vert bruk, vil denne bokstaven, ein liten p, sjå ut på ulike måtar. Er fonten Times, ser bokstaven ut på ein litt annan måte (p) enn om fonten er Verdana (p) eller Courier (p). Og på andre hylleplassar finn vi andre bokstavar, til dømes ein stor A på hylleplass nr. 65 og ein liten æ på hylleplass nr. 230

Frå få til mange hylleplassar

Før i tida var det slik at kva som helst kunne finnast på hylleplass nr. 112. Det var som regel ein liten p, men nokre fontar hadde andre bokstavar eller teikn der. Eller sagt på ein annan måte: Ein liten p såg ikkje berre ut som ein liten p, han kunne òg sjå ut som ein liten gresk π (pi) og mangt anna, avhengig av font. Det vart gjort på denne måten fordi det berre fanst 256 hylleplassar. Så dersom det altså var ein gresk π ein var på jakt etter, så skifta ein berre font og gjekk til hylleplass nr. 112 då òg, for å få ein p som «såg gresk ut». Gresk π var altså altså heilt på line med å skifte font for å få ein vanleg norsk p til å sjå ut på ulike måtar: p p p π π π.

Det var denne gamle vanen som fekk databrukaren i fyrste avsnitt til å gå seg på veggen.

For i dag er det altså annleis. I dag er det ikkje 256 hylleplassar men over ein million i eit hylleplass-system som heiter Unicode (nærare bestemt 1 114 112 hylleplassar, flesteparten er pr. i dag framleis ledige). Nokre av hylleplassane er reserverte for spesielle saker og ting, men det er likevel mange nok plassar til at kvart einaste skriftteikn i heile verda kan ha sin eigen hylleplass. Til og med mange andre teikn får plass, slik som åttandedelsnote ♪ (hylleplass 9834), smilefjes ☺ (9786) og peikefinger ☞ (9758). Liten p er på hylleplass nr. 112 som før, men gresk liten pi π har fått sin eigen heim på hylleplass nr. 960. Ein liten latinsk p eller ein liten gresk π vil framleis sjå ulike ut i ulike fontar, men no er dei i alle fall eintydig ein p eller π.

Dramatisering: Jenta har her rolla som datamaskin. Det finst over ein million hylleplassar med ulike bokstavar og teikn, men datamaskina har nettopp gått til hylleplass nr. 960 for å hente det teiknet som held til der. Dette viste seg å vere den greske bokstaven π (pi). Saman med sjølve opplysninga om at det er ein π som held til på denne hylleplassen, ligg det også opplysningar om korleis teiknet oppfører seg, t.d. at det høyrer til eit skriftsystem som går frå venstre mot høgre (som også i norsk) og ikkje motsett (som i kinesisk). Så no når maskina har funne ut dette, kan ho gå vidare til skjermen og skrive π, slik at vi kan lese bokstaven der. Akkurat korleis bokstaven vert sjåande ut, er avhengig av kva for ein font som vert brukt, men det er i alle fall eintydig ein π og ikkje t.d. ein norsk Æ eller ein russisk И. (Foto: Joe Crawford.)

Slike teikn som er spesielle for lydskriftsystemet IPA, har òg sine heilt eigne hylleplassar.

Dette medfører òg at dersom vi skriv eit stort dokument på norsk, men med lydskrift og nokre greske eller japanske skriftteikn innimellom, så er det ikkje katastrofe dersom vi markerer all teksten og endrar font. Gresk π er framleis ein gresk π. (Ingen einskildfont inneheld forresten alle hylleplassane pr. i dag, men mange fontar inneheld nokså mykje likevel.)

Tastaturoppsett

Men sjølv om det no finst over ein million hylleplassar å velje mellom (derav hundre tusen til eit par hundre tusen hylleplassar med innhald i, alt etter korleis ein tel), så har tastaturet (i alle fall eit MacBook-tastatur) berre 48 tastar med plass til bokstavar, tal og andre teikn, i tillegg til nokre spesialtastar. Desse 48 tastane har i praksis plass til fleire teikn enn som så, t.d. er dollarteiknet $ på same tast som talet 4, og vi kan bruke daudtastar for å stappe inn nokre ekstra bokstavar (til dømes skrive áćéíńóś ved hjelp av akuttaksent + bokstavtast, alle desse ekstrabokstavane har sine eigne hyllepalssar). Men sjølv dette finst det anten grenser for, eller det vert etter kvart upraktisk dersom ein vil skrive til dømes tjue tusen ulike teikn via tastaturet.

Tastaturmenyen i menylina med nokre utvalde tastaturoppsett.

Her er det vi kan ha nytte av å skifte tastaturoppsett. Eit tastaturoppsett er registeret som datamaskina slår opp i når ho skal bestemme seg for kva for ein hylleplass ho skal gå til når vi trykkjer på den eller den tasten. (Sjå også denne bloggposten.) Som standard på ein norsk Mac er det slik at eit trykk på tast nr. 35 dirigerer oss mot hylleplass nr. 112 og ein liten p. Men så kan ein skifte til gresk tastaturoppsett, og når vi då trykkjer på tast nr. 35, så er det fordi vi vil ha bokstaven på hylleplass nr. 960, som er π.

Sameleis, tast nr. 39 gjev til vanleg hylleplass nr. 230, ein liten æ. Men med svensk tastaturoppsett vil denne tasten vere kopla til hylleplass nr. 228 (ä), eit amerikansk tastaturoppsett vil leite fram hylleplass nr. 39 (apostrof), eit kviterussisk oppsett vil gå til hylleplass 1101 (э), og eit devanagari-oppsett finn fram til hylleplass nr. 2335 (ट).

Sjølve tasten er den same, men tastetrykket sender datamaskina til vidt ulike hylleplassar, alt etter kva for eit tastaturoppsett som er i bruk. Bur ein i Sverige, har ein gjerne kjøpt ei datamaskin der bokstavteiknet Ä er prenta på den aktuelle tasten, men som sagt, datamaskina har ikkje noko forhold til kva som er skrive på den fysiske tasten. Dermed kan vi skifte tastaturoppsett så ofte vi vil, sjølv om det jo er praktisk i det daglege å halde seg til eit tastaturoppset som stemmer overeins med dei bokstavane som er skrivne på tastane. (Eventuelt er det praktisk å ha tastar som ser ut i samsvar med det tastaturoppsettet ein bruker i det daglege.)

Desse bileta viser kva slags teikn som dukkar opp når ein trykkjer på Mac-tastaturet, avhengig av om ein har valt norsk eller kviterussisk tastatur. Æ-tasten er for referansen si skuld markert med grønt på begge bileta:

Norsk tastaturoppsett på ein MacBook.

Kviterussisk tastaturoppsett på ein MacBook.

Fleire vegar til Rom

Tilbake til Mac-brukaren som ville skrive IPA-lydskrift, men som fekk ein vanleg bokstav i staden: Fenomenet kom sjølvsagt av at datamaskina gjekk til norske hylleplassar i staden for til IPA-hylleplassane. Då var det lite hjelp i å ha ein font med lydskriftteikn på IPA-hylleplassane, når datamaskina ikkje gjekk til rett hylleplass. Men med litt oppfrisking av gamle kunnskapar gjekk det bra: Skift tastaturoppsett medan du skriv lydskrift.

Å nå bestemte hylleplassar kan ein altså gjere via tastaturet, dersom ein har eit høveleg tastaturoppsett. For meg som skriv lydskrift mykje, er det t.d. kjekt å gjere det på den måten, slik at når eg trykkjer på stor S på tastaturet, så er det ikkje stor S som vert henta fram (hylleplass nr. 83) men lydskriftteiknet for ustemd postalveolar frikativ (ʃ, hylleplass nr. 643).

Men det finst også andre vegar til hylleplassane. Det er til dømes ikkje spesielt ofte eg treng teikn som ☃ (snømann, hylleplass nr. 9731), og ikkje har eg han i noko tastaturoppsett eg veit om heller. I staden kan ein leite seg fram på ei oversikt over alle hylleplassane. Denne oversikta heiter «Tegnvisning» på Mac og er tilgjengeleg anten via ⌘⌥T eller via tastaturmenyen, som kan aktiverast i kontrollpanelet Språk og tekst > Inndatakilder. Det er forresten her vi går også når vi vil bestemme kva for nokre tastaturoppsett vi vil ha tilgang til frå menylina.

For lydskriftbrukarar som ikkje vil bruke tastaturet, finst det også meir avgrensa hylleplass-oversikter spesifikt for det internasjonale fonetiske alfabetet, slik som dette IPA-kartet frå Weston Ruter. Der kan ein klikke på eit symbol, markere og kopiere det, og lime det inn i tekstbehandlaren sin. Dessutan finst det ein IPA-teiknpallett som ein kan køyre lokalt på maskina (men installeringa av versjon 2.0 på min Mac OS X 10.6.6 var litt trøblete).

Mac-brukaren eg nemnde i det fyrste avsnittet, fekk også problem med å skrive norsk. Plutseleg vart det IPA-teikn i staden, og tekstbehandlaren slo over til ein annan font som inneheldt dette teiknet. Mysteriet fekk si løysing: «Du må skru over til norsk tastaturoppsett igjen når du vil skrive vanleg skriftspråk.»

Kjerreveg

Somme har kanskje ikkje oppdaga Rom eller vegane dit, og då kan det gå rett så gale, noko eg har skrive om tidlegare: Klikk her for nokre skrekkhistorier.

Men her vil eg til slutt nemne dei som har oppdaga Rom, men som også gjerne tek seg avstikkarar ut på kjerrevegane. Eg tenkjer på Microsoft. Sjå til dømes dette utdraget frå ein bloggpost av ein truleg heilt uskuldig bloggar:

Sitatene over er hentet fra en av mine mest engasjerte lesere, Gregersen. Jeg kjenner selvfølgelig ikke denne Gregersen, men som en liten anekdote heter høyrehånda til min kone nettopp Gregersen, men han er allerede sjekket ut av saken J. For ordens skyld er han en hedersmann.

At kva for noko? Gregersen er «allerede sjekket ut av saken J»? Kva for ei sak er sak J? Er det saka før sak K?

Nei då. Eg mistenkjer at forfattaren av praktiske grunnar kladda blogginnlegget sitt i eit Microsoft-produkt som Word eller Outlook eller deromkring. I kladden har han truleg skrive eit smilefjes :-) som programmet så har autoretta til eit smilefjes ☺. Her burde programmet sjølvsagt ha valt nettopp smilefjeset ☺ (hylleplass 9786), men i staden har Microsoft bestemt seg for å autorette til teiknet på hylleplass nr. 74, som er hylleplassen til bokstaven J. Dette vart likevel ikkje synleg før teksten vart limt inn i bloggen, for der overlever både halvfeit og kursiv men ikkje fontane. Og dermed overlevde ikkje ☺.

Så kvifor valde Word å autorette :-) til akkurat bokstaven J? Grunnen er at programmet stør seg til ein Microsoft-font som heiter Wingdings, og som av historiske grunnar ikkje forheld seg til Unicode med sine 1,1 millionar hylleplassar, men som synest det er nok med 256 hylleplassar. I den fonten er ☺ berre ein annan måte å skrive J på. Dette er altså gamlemåten å gjere det på, trass i at desse programma i seg sjølve faktisk taklar Unicode.

Eit Google-søk på «velkommen til oss J» finn meir av same sorten.

Judith har forresten skrive ein eigen bloggpost om fenomenet «Hei J» i e-postar frå Microsoft-brukarar.

Heilt til slutt eit avsnitt for dei som kan litt, og som vil prøve sjølve: Dersom du kopierer eit Wingdings-smilefjes frå Word og limer det inn i Pages ’09 på Mac OS X 10.6.6, så vil Pages tolke ☺ som eit teikn frå eit av «privat bruk»-områda av Unicode, medan TextEdit 1.6 konverterer akkurat dette bestemte Wingdings-teiknet til eit ekte Unicode-smilefjes så sant du limer det inn med ⌥⇧⌘V utan å ta med deg stilen frå Word. Limer du inn i html-redigeringa i WordPress, vert det òg eit ekte smilefjes, men lim inn med vanleg ⌘V i «Visuell»-redigeringa og få ein J. Dei tilfella der Wingdings-smilefjeset vert konvertert til eit ekte Unicode-smilefjes, ser ikkje ut til å konvertere andre Wingdings-teikn enn andlet, så Wingdings-peikefinger ☞ vert i TextEdit forstått som «privat bruk» og ikkje som peikefinger. Det verkar altså som det er lagt inn ei spesifikk konvertering av nettopp fjes: Smilefjes vert konvertert til ☺, surt fjes til ☹, medan nøytralt fjes vert konvertert til dei to teikna :| i mangel av eit eige Unicode-kodepunkt for dette fjeset i Mac OS X 10.6.6, som enno ikkje har teke i bruk Unicode 6.0.

Read Full Post »

Lydskrift på Mac

Å skrive lydskrift er ikkje nokon stor kunst. Denne bloggposten handlar primært om lydskrift på Mac, men noko av det (den andre måten under) kan også vere aktuelt for andre operativsystem. Har du Windows, så sjå i tillegg gjerne IPA-Unicode-sida til John Wells.

Fyrst av alt: Ein skriv ikkje lydskrift ved berre å endre font og taste i veg. Slik tilnærming er steinalderteknologi, og vil garantert føre til problem. Men ein treng jo likevel ein font som inneheld lydskriftteikna. Bruk Unicode-fontar, til dømes Doulos SIL eller Charis SIL, som kan lastast ned gratis frå SIL. (Merk: Den nettsida har også ein del andre fontar, og nokre av dei er frå steinalderen. Sjå opp for ord som «symbol-encoded», «obsolete» og «discouraged». Hald deg til Unicode-fontar!)

Som regel må ein endre font, same kva slags metode ein bruker for å stappe inn lydskriftteikn. Unntaket er dersom ein allereie skriv med ein font som inneheld alle dei IPA-teikna ein er interessert i. Til dømes er det mange fontar som inneheld ə og ŋ, m.a. Times, Times New Roman og Monaco (i alle fall dei relativt nye versjonane).

I alle fall, dersom ein har fontar med dei aktuelle IPA-teikna i, så kan ein skrive inn desse teikna på tre måtar.

Den eine måten er å navigere i tabellane i «Tegnvisning» [oppdatering 23.8.2015: frå OS X 10.10.3 heiter det visst «Emoji og symboler»]. Dette er tilgjengeleg i tastaturmenyen i menylina. Gå til Systemvalg > Språk og tekst > Inndatakilder (Mac OS X 10.5 og eldre er det Systevalg > Internasjonalt). Men dette er tungvint ettersom lydskriftteikna er spreidde omkring både her og der, ikkje berre i IPA-blokka. Den nemnde ŋ ligg t.d. i blokka «Latinsk, utvida A». Dersom ein ikkje er heilt stø i sin IPA, risikerer ein også å stappe inn feil teikn, fordi ein finn eit teikn som liknar på det ein ser etter, men som ikkje er det ein eigentleg vil ha.

I Word skal det visst også gå an å setje inn teikn frå ein meny der, men dette har eg aldri fått til, og eg har ikkje prøvt å finne ut av det heller, sidan eg til vanleg bruker Pages. [Oppdatering 23.8.2015: Etter at Apple øydela Pages, har eg gått over til Nisus Writer Pro.]

Ein annan måte å stappe inn lydskriftteikn på er å gå til IPA-tabellane til Weston Ruter, klikke, kopiere og lime inn. Dette er meir brukarvenleg, ettersom ein slepp å navigere så mykje. Dette fungerer på tvers av operativsystem, ein treng berre ein nettlesar. Klikk på det symbolet du treng, så dukkar det opp i eit felt nedst på sida som det er lett å kopiere frå.

Oppdatering 23.8.2015, metode 2b: Som ei blanding av den fyrste og den andre måten (ein treng ikkje å vere på nett), så finst det også ein teiknpalett som heiter IPA Palette, og som har IPA-teikna i det same oppsettet som vi er vane med på IPA-tabellane. Dette er ein reindyrka IPA-slektning av det som i dag heiter «Emoji og symboler». IPA Palette må ein sjølv installere etter nedlasting, paletten vert tilgjengeleg i tastaturmenyen saman med teiknvisinga og tastaturoversikta (han ville altså ha dukka opp som «Vis IPA Palette» i biletet over dersom han hadde vore installert på det tidspunktet), men er mykje lettare å finne fram i til vårt føremål enn metode 1 over. Dei siste åra har eg ofte tilrådd metoden for andre Mac-brukarar, og bruker av og til metoden sjølv òg, men sidan eg skriv lydskrift så mykje som eg gjer, held eg meg stort sett til den neste metoden. (Slutt på oppdatering.)

Den tredje måten (for oss som skriv IPA heile tida) er å omdefinere tastaturet sitt til å plukke fram teikn frå andre kodepunkt i Unicode enn tastaturet til vanleg opererer med. Altså endre tastaturoppsett. Det finst fleire tastaturoppsett for IPA, og eg har òg laga eit. Det som kjem frå mi hand, er omsider ferdig i versjon 2.0. Last det ned, installer (instruksar står i «read me»-fila), logg ut og inn, aktiver det slik at det dukkar opp i tastaturmenyen, og vel det når det trengst.

[Oppdatering 4.7.2011: Dersom du ikkje får kontakt med tenaren, så prøv alternativ lenkje her. Eller ta direkte kontakt.]

IPA-tastaturoppsett. Tastane som er markerte med raudt, er daudtastar.¹

Tastaturoppsettet når ⇧-tasten er trykt ned.
Ein kan også trykkje ned ⌥ og ⌥⇧ for å få endå fleire teikn.

Dette tyder at for å skrive teiknet ŋ (velar nasal) trykkjer ein ⇧N, og ein slepp å leite i teikntabellane og kanskje blande saman med ƞ, som ikkje finst i IPA. I dette tastaturoppsettet trykkjer ein elles ⌥N for å få ɳ (retrofleks nasal) og ⌥⇧N for å få ɲ (palatal nasal).

Og så ei lita åtvaring til slutt: Over nemnde eg dette med å vere stø i sin IPA, og den åtvaringa gjeld både for innsetjingsmenyar i Word og for tastaturoppsett, men sjølvsagt mest for innsetjingsmenyar der ein må navigere for å finne noko som ein håper er rett teikn (ŋ og ƞ er nemnde, eg kunne også nemnt IPA-vokalar som ɵ og ɤ og IPA-konsonantar som θ og ɣ). Min kollega Aleksander plar rå exfac-studentane til å skrive lydskrift for hand i obligatoriske oppgåver. Dette rådet byggjer både på den nemnde faren for feil og på den tida slik navigering kan ta. Det kan dessutan verte kluss med utskrifta dersom den maskina som ein skriv ut med, ikkje har dei fontane som ein har brukt i dokumentet (men om ein lagrar som pdf, går det likevel bra, altså).

_____
¹ Daudtast: tast som ikkje gjev eit ferdig skriftteikn, men som typisk gjev ein del av skriftteiknet, som ein så fullfører med neste tastetrykk. Til dømes tøddel ¨, som etterfylgd av o gjev det ferdige skriftteiknet ö.

Read Full Post »

« Newer Posts - Older Posts »