>> wybierz styl >> es :: ns :: bs

Weblog Tomasza Przechlewskiego [Zdjęcie T. Przechlewskiego] [[Ikona]]


scrum
random image [Photo gallery]
Zestawienie tagów
1-wire | 18b20 | 1wire | 2140 | 3rz | alsamixer | amazon | anniversary | antypis | apache | api | arm | astronomy | asus | atom.xml | awk | aws | balcerowicz | balta | bash | berlin | bibtex | bieszczady | biznes | blogger | blogging | blosxom | borne-sulinowo | breugel | bt747 | canon | cedewu | chello | chown | chujowetaśmy | cmentarz | contour | cron | css | csv | curl | d54250wykh | debian | dejavu | dhcp | dht22 | dia | docbook | dom | ds18b20 | dyndns | dynia | ebay | economy | ekonomia | elka | elm | emacs | emacs23 | english | ess | eu | excel | exif | exiftool | f11 | fc | fc11 | fc15 | fc5 | fc8 | fedora | fedora21 | fenix | ffmpeg | finepix | firefox | flickr | fontforge | fontspec | fonty | fop | foto | france | francja | fripp | fuczki | fuji | fuse | gammu | garmin | gawk | gazwyb | gdynia | geo | georgia | gft | git | github | gmail | gnokii | gnus | google | googlecl | googleearth | googlemaps | gphoto | gphoto2 | gps | gpsbabel | gpsphoto | gpx | gpx-viewer | greasemonkey | gruzja | grzyby | haldaemon | handbrake | historia | history | hitler | holocaust | holokaust | hpmini | humour | iblue747 | ical | iiyama | ikea | imap | inkscape | inne | internet | j10i2 | javascript | jhead | k800i | kamera | kleinertest | kml | kmobiletools | knuth | kod | kolibki | komorowski | konwersja | krutynia | kuchnia | kurski | latex | latex2rtf | latex3 | lcd | legend | lenny | lesund | lewactwo | liberation | linux | lisp | lisrel | litwa | logika | ltr | lwp | m2wś | mapsource | marvell | math | mathjax | mazury | mbank | mediolan | mencoder | mh17 | michalak | microsoft | monitor | mp4box | mplayer | ms | msc | msw | mtkbabel | museum | muzyka | mymaps | mysql | nanopi | natbib | navin | neo | neopi | netbook | niemcy | niemieckie zbrodnie | nikon | nowazelandia | nuc | nxml | oauth | oauth2 | obituary | okular | olympus | ooffice | ooxml | opera | otf | otftotfm | other | overclocking | panoramio | pdf | pdfpages | pdftex | pdftk | perl | photo | photography | picasa | picasaweb | pim | pine | pit | plotly | pls | plugin | po | politics | polityka | polsat | postęp | powerpoint | prelink | problem | propaganda | pstoedit | putin | python | r | radio | random | raspberry pi | refugees | relaxng | ridley | router | rower | rowery | rpi | rsync | rtf | ruby | rugby | russia | rwc | rwc2007 | rwc2011 | rzym | samba | sem | sheevaplug | sienkiewicz | signature | sks | skype | skytraq | smoleńsk | sqlite | srtm | ssl | statistics | stats | statystyka | stix | svg | svn | swornegacie | szwajcaria | terrorism | tex | texgyre | texlive | thunderbird | tomato | tourism | tramp | trang | truetype | ttf | turystyka | tusk | tv | tv5monde | twitter | typetools | ubuntu | uchodźcy | udev | umap | unix | upc | updmap | ups | utf8 | varia | video | vienna | virb edit | vostro | wammu | wdc | wdfs | webcam | webdav | wh2080 | wiedeń | wikicommons | wilno | windows | windows8 | wine | wioślarstwo | word | wordpress | wrt54gl | ws1080 | wtyczka | ww2 | www | wybory | wybory2015 | włochy | xemex | xetex | xft | xhtml | xine | xml | xmllint | xsd | xslt | xvidtune | youtube | yum | zakopane | zakupy | zdf | łeba | świdnica
Pobrania via google: [[Ikona]]
Archiwum
Inne blogi
N. Walsh | Morten H. Frederiksen | B. Clementson | prawo.vagla.pl | F. Hecker | M. Olson | J. Tennison | J. Clark | M. Nottingham | M. Shuttleworth | T. Isakowicz-Zalewski | J. Anglim | José A. Ortega Ruiz Modern Perl
Inne tematyczne
Ashwin Amanna | wiesia.nets.pl | Wojt | rwm.org.pl | DataBlog | Revolutions | Learning R | A. Gelman | C. Nel | J. Vogelgesang | ubl.xml.org/ | J.D. Long |
O stronie
wykorzystywany jest blosxom plus następujące wtyczki: tagging, flatarchives, rss10, lastbuilddatexhtmlmime. Niektóre musiałem dopasować nieco do swoich potrzeb. Więcej o blosxom jest tutaj
Subskrypcja
RSS 1.0
Ćwiczenie z XSLT

Zadanie polega na wydłubaniu z pliku GPX pierwszego i ostatniego elementu <time>, który jest dzieckiem elementu <trkpt>. (Nie może być po prostu <time>, bo element ten występuje także w innym kontekście.)

Coś takiego wymyśliłem:

<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:gpx="http://www.topografix.com/GPX/1/0">

<xsl:output method="text"/>

<xsl:param name='Position' select="'First'"/> 

<xsl:template match="/" >

<xsl:for-each select='//gpx:trkpt'> 

  <xsl:if test="position()=1 and $Position='First'">
    <xsl:value-of select='gpx:time'/>
    <xsl:text>&#10;</xsl:text>
  </xsl:if>

  <xsl:if test="position()=last() and $Position='Last'">
    <xsl:value-of select='gpx:time'/>
    <xsl:text>&#10;</xsl:text>
  </xsl:if>
  
</xsl:for-each>
  
</xsl:template>

</xsl:stylesheet>

W praniu się okazało, że jest jeden drobny, komplikujący życie feler-nie-feler. Struktura plików GPX (w zależności od tego czym są one generowane) jest identyfikowana albo z przestrzenią nazw http://www.topografix.com/GPX/1/0 albo z http://www.topografix.com/GPX/1/1. Praktycznie żadna różnica, ale szablon przestaje działać. Aby uodpornić szablon na wersje formatu można zamienić:

<xsl:for-each select='//gpx:trkpt'> 

na

<xsl:for-each select='//*[local-name()="trkpt"]'> 

Teraz szablon `reaguje' na element <trkpt> z dowolnej przestrzeni nazw. Oczywiście reguła wyboru węzłów stała się teraz `mniej specyficzna', co w przypadku bardziej skomplikowanych transformacji może nie być najlepszym pomysłem, ale w przypadku tak prostego schematu jak GPX i banalnej transformacji, jak powyższa nie powinno być problemów.

Podobnie można zamienić:

<xsl:value-of select='gpx:time'/>

na:

<xsl:value-of select='*[local-name()="time"]'/>

Teraz, przykładowo uruchomienie xsltproc (opisany wyżej szablon jest zawartością pliku gpxtimestamp.xsl):

xsltproc --param Position '"First"' gpxtimestamp.xsl 20120107.xml
xsltproc --param Position '"Last"' gpxtimestamp.xsl 20120107.xml

Wypisuje odpowiednio zawartość pierwszego i ostatniego elementu <time>.

url | Sun, 08/01/2012 21:53 | tagi: ,
Zbędne deklaracje xmlns przy zamianie KML→GPX

Z pliku XML w wersji KML, tj. googleearth chcę wydłubać współrzędne punktów MyPlaces oraz zapisać je w formacie GPX (celem późniejszego załadowania do Garmina). Używam do tego następującego arkusza XSLT:



  

  
    

        
    
  

  
    
      
        
      
      
        
      
      
        
      
      
        
      
    
  

]]>

Gdyby w powyższym arkuszu XSLT zamiast

    <wpt xsl:exclude-result-prefixes="gpx kml" 
         xmlns='http://www.topografix.com/GPX/1/0'>
    ...

było po prostu:

    <wpt xsl:exclude-result-prefixes="gpx kml" 
    ...

to znaczy zostałaby pominięta deklaracja przestrzeni nazw elementu wpt, wtedy procesor XSLT zapisałby na wyjściu coś w rodzaju:

 <wpt xmlns="" lat="19.35304208110762" lon="54.35681836243874">
   ...

A to oznacza, że wpt pochodziłby z pustej przestrzeni nazw, xmlns="". Niby proste, ale nie jest oczywiste jak usunąć -- na pierwszy rzut oka zbędne (a tak na prawdę błędne) -- wpisy xmlns="".

url | Wed, 31/03/2010 09:21 | tagi: , , ,
Drobny przykład w XSLT

Fragment pliku XML wygląda jakoś tak:

 <month no="1">  
   <item data="2009/01/03" dist="20" exdist="18.60" />
   <item data="2009/01/25" dist="50" exdist="49.10" />
 <month no="2">  
   ...
 </month>

Wszystkie item pomiędzy month trzeba zsumować aż do zadanego numeru miesiąca (włącznie), który jest n.b. wartością atrybutu no. Poniższy szablon wykona ww. zadanie:

  <xsl:template name='drukuj-do-mc'>
    <xsl:param name='mc'/>
    <xsl:text> [od początku roku: </xsl:text>
    <xsl:value-of select="sum(//item[not(../@no &gt; $mc)]/@dist)"/>
    <xsl:text> km] </xsl:text>
  </xsl:template>

Wyróżniony wiersz zawiera kluczowe przekształcenie XPath: //item[not(../@no &gt; $mc)]/@dist, co można zinterpretować następująco: wszystkie atrybuty dist przyczepione do elementu item, z całego dokumentu, ale pod warunkiem, że wartość atrybutu no elementu nadrzędnego jest nie większa niż $mc.

url | Fri, 22/05/2009 17:57 | tagi: ,
Formatowanie elementu optional (w Docbook XML)

W nazwiązaniu do poprzedniego wpisu. W dokumencie o XPath pojawia się taki oto fragment:

[predykat]*]]>

Co ma oznaczać, że wyrażenie ścieżkowe XPath składa się z  osi i testu oraz opcjonalnego predykatu, który może być powtórzony wielokrotnie (stąd *). Teraz standardowo szablony XSL Docbook (aka XSLDB) zamieniają ww. fragment XML na coś takiego:

oś::test[[predykat]*]

Niezręczność polega na tym, że nawiasy kwadratowe raz są używane do oznaczania części opcjonalnej a raz oznaczają, że należy je wstawić literalnie. W XSLDB znaki wstawiane wokół elementu optional są sparametryzowane -- są to mianowicie: arg.choice.opt.open.str oraz arg.choice.opt.close.str. Zamiast `[' i `]' zdecydowałem się na U+27E8 (Mathematical left angle bracket) oraz U+27E9 (Mathematical right angle bracket) Teraz próba uruchomienia:

xsltproc --stringparam arg.choice.opt.open.str "&#x27e8;" \
   --stringparam arg.choice.opt.close.str" select="&#x27e9;" ...

Kończy się błędem basha... Ciekawe czemu? Można podać ww. znaki binarnie -- wtedy wszystko działa. Ale UTF-8 w Makefile? Miałem opory, dodałem więc do arkusza uruchamiającego transformację XML → XHTML:

<xsl:param name="arg.choice.opt.open.str" select="'&#x27e8;'" />
<xsl:param name="arg.choice.opt.close.str" select="'&#x27e9;'" />

Teraz omawiany fragment wygląda mniej dwuznacznie:

oś::test⟨[predykat]*⟩

BTW w trybie nxml wpisanie &#x27e8; powoduje, że automagicznie kształt znaku pojawia się za średnikiem (ale nie jest wstawiany do tekstu -- po prostu jest to podpowiedź Emacsa, jak wygląda kształt znaku.) Dodatkowo po najechaniu myszą na encję wyświetlana jest nazwa znaku (w oknie podpowiedzi zwanym tooltip). Te ułatwienia są fajne w środowisku jednobajtowym--a ja póki co używam jako domyślnego kodowania ISO-8859-2.

Przy okazji użyteczne zestawienie znaków Unicode -- odpowiedników różnych TeXowych symboli matematycznych. Wystarczy zaznaczyć myszą i wkleić do Emacsa a następnie C-x = (what-cursor-position) wyświetli co zacz, w tym numer znaku.

url | Sat, 01/11/2008 20:58 | tagi: , , , ,
SVG, Docbook i Firefox

Zaczęło się od tego, że chciałem wstawić ilustrację w formacie SVG do dokumentu redagowanego w Docbooku. Jakoś tak:


  Osie (środkowy węzeł <literal>p</literal> jest węzłem kontekstowym)
  
    
      
    
  
]]>

W pliku PDF wygenerowanym FOPem ilustracja wygląda OK. W dokumencie HTML oglądanym w FF 2.0.0.16 wygląda dziwnie: wyświetlany jest tylko fragment rysunku a z boku pojawia się pasek do przewijania (scrollbar). I nie idzie tego się pozbyć...

Zaktualizowałem zatem Firefoxa do wersji 3.0.3. Teraz rysunek jest wyświetlany prawidłowo. Opera 9.27 nie pokazuje go wcale, ale jeżeli pominie się atrybut width, to rysunek jest wyświetlany prawidłowo. Skoro tak to wymyśliłem sobie coś takiego:


  Osie (środkowy węzeł <literal>p</literal> jest węzłem kontekstowym)
  
    
      
    
    Na wypadek gdyby powyższy rysunek
był niewidoczny tu jest wersja w formacie PNG 
    
  
]]>

Powyższa uwaga w pliku PDF jest bez sensu. Na szczęście łatwo się go pozbyć, bo w Docbooku zaimplementowano warunkowe przetwarzanie dokumentu (profiling). Następujące kilkanaście atrybutów może być używanych do tego celu:

Nazwa atrybutu Opis Parameter XSL
arch Computer or chip architecture, such as i386. profile.arch
audience Intended audience of the content, such as instructor. profile.audience
condition General purpose conditional attribute, with no preassigned semantics. profile.condition
conformance Standards conformance, such as lsb (Linux Standards Base). profile.conformance
lang Language code, such as de_DE. profile.lang
os Operating system. profile.os
revision Editorial revision, such as v2.1. profile.revision
revisionflag Revision status of the element, such as changed. This attribute has a fixed set of values to choose from. profile.revisionflag
role General purpose attribute, with no preassigned semantics. Use with caution for profiling. profile.role
security Security level, such as high. profile.security
status Editorial or publication status, such as InDevelopment or draft. profile.status
userlevel Level of user experience, such as beginner. profile.userlevel
vendor Product vendor, such as apache. profile.vendor
wordsize Word size (width in bits) of the computer architecture, such as 64bit. Added in DocBook version 4.4. profile.wordsize

Teraz po wpisaniu ... ]]> do dokumentu należy uruchomić procesor XSLT z odpowiednią wartością parametru (podanego w trzeciej kolumnie tabeli). Mówiąc konkretnie:

## Transformacja za pomocą xsltproc xml2xhtml
xsltproc --stringparam chunker.output.doctype-public "-//W3C//DTD XHTML 1.0 Strict//EN" \
     --stringparam chunker.output.doctype-system http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" \
     --stringparam profile.condition "html" -o plik.xhtml szablon.xsl plik.xml

## albo za pomocą procesora saxon:
saxon -o plik.fo plik.xml szablon.xsl profile.condition="pdf"

Do tego zamiast standardowego arkusza XSL-ROOT/xhtml/chunk.xsl (XSL-ROOT oznacza katalog główny dystrybucji arkuszy XSL Docbook) należy w przypadku zamiany na XHTML uruchomić XSL-ROOT/xhtml/profile-chunk.xsl. Podobnie zamieniając XML na FO/PDF należy uruchomić XSL-ROOT/fo/profile-docbook.xsl zamiast XSL-ROOT/fo/docbook.xsl. Oczywiście ww. arkusze są uruchamiane pośrednio, poprzez arkusz dopasowujący nastawy XSL Docbook do moich potrzeb. Początek tego arkusza wygląda zatem następująco:



 
]]>

Teraz jest tak: plik PDF jest OK. Plik XHTML nie do końca--nie widać wpisu Na wypadek gdyby powyższy rysunek.... Zasłania go rysunek; co ciekawe identycznie wygląda to w Firefoksie i Operze (tzn. identycznie nic nie widać). Relewantny fragment pliku XHTML wygląda następująco:


   

Rysunek 1. Osie (środkowy węzeł p jest węzłem kontekstowym)

Na wypadek gdyby powyższy rysunek był niewidoczny tu jest wersja w formacie JPG

]]>

Jeżeli się wstawi element object do elementu p, to tekst się pojawia... Ale żeby object był wewnątrz akapitu to trzeba zmienić relewantne szablony XSL Docbook; w tym przypadku nie aż tak trywialne zadanie... Poddałem się i uwagę dodałem w formie akapitu pod pod rysunkiem. Ostatecznie wygląda to tak.

Dopisane 2 listopada 2008: Wzmiankowany dokument wyświetla się w programie Exploder czy jakoś tak, tzw. czołowej firmy zupełnie kuriozalnie, mianowicie do połowy (tj. do rysunku). W związku z tym nawet ostrzeżenie: Na wypadek gdyby powyższy rysunek był niewidoczny tu jest wersja... nie jest wyświetlane, ani link do pliku PNG, ani nic po rysunku. Ci to zawsze potrafią zaskoczyć.

Firma owa uparła się bowiem ignorować standardy a wciskać na siłę swoje szajsowe rozwiązania typu VML czy jakiś EMF. Ich sprawa...

url | Sat, 01/11/2008 20:00 | tagi: , , ,
Apache Velocity DocBook Framework

Wymieniony w tytule Apache Velocity DocBook Framework (AVDF) to sterowany antem zbiór narzędzi do zamiany dokumentów DocBook na HTML/PDF. Konkretnie tymi narzędziami są Fop (w wersji 0.20.5), Saxon i szablony XSL N. Walsha. Po ściągnięciu archiwum .zip lub .tgz ze strony projektu i rozpakowaniu, na dysku pojawi się następująca struktura katalogów:

<korzeń instalacji AVDF>
  |
  +---- build-docbook.xml
  +---- project.properties 
  +-- src
       +-- styles
  
  +-- docs
       +-- build.xml
       +-- project.properties
       +-- src
            +--css
            +--docbook
            |    +--<projekt>
            +-- images 
	    +-- target
  +-- lib

Katalog lib zawiera fopa i saxona plus niezbędne dodatkowe aplikacje. Katalog src/styles zawiera szablony ,,startowe'', uruchamiane przy zamianie plików XML na HTML i PDF. [Tu trzeba dłubnąć żeby dokonać polonizacji.] Wreszcie dokument ,,źródłowy'' ma być obowiązkowo umieszczony w katalogu docs/src/docbook/<projekt>. Pliki z rysunkami zaś muszą być umieszczone w docs/src/images. Wynik transformacji będzie się znajdował w docs/target/<projekt>. Dodatkowo w docs/src/css znajduje się szablon CSS wykorzystywany przez wygenerowane pliki HTML.

Polonizacja wymaga: 1) ściągnięcia następującego archiwum .zip i rozpakowania jego zawartości w tak sposób aby została dodana do oryginalnej dystrybucji AVDF (kilka plików zostanie nadpisanych); 2) wykonania polecenia ant -f build-docbook.xml dbf.init z poziomu korzenia instalacji AVDF. Tyle -- powinno działać. Reszta tego wpisu dotyczy szczegółów: co, jak i dlaczego. Można nie czytać...

Pliki build-docbook.xml zmieniłem tak, że dodałem do wywołania fopa argument -c plik.cnf, tj.:

<java classname="org.apache.fop.apps.Fop" fork="true" maxmemory="256m"
    dir="${basedir}" classpathref="dbf.classpath">
   <arg value="${pdf.target.file}.xml"/>
   <arg value="${target.dir}/${docbook.dir}/pdf/${docbook.file}.pdf"/>
<arg value="-c"/>
   <arg value="${dbf.basedir}/conf/userconfig.xml"/>
</java>

Parametr ${dbf.basedir} to katalog główny, w którym znajduje się cały framework. Dodany katalog conf/ zawiera plik konfiguracyjny fopa + pliki metryczne fontów. Same fonty (pliki .ttf) są w katalogu fonts/. Dodanie do AVDC fontów powoduje, że całość jest gotowa do użycia w każdym systemie. [Można oczywiście tak skonfigurować AVDF żeby używał fontów systemowych]. Z kilku zestawów rozpowszechnianych bezpłatnie fontów truetype (Core fonts for the Web (Nie najwyższej jakości i do tego ich rozpowszechnianie podlega pewnym ograniczeniom), TeX Gyre, Quasi, STIX (tylko jedna odmiana -- brak kroju bezszeryfowego i kroju typu monospace), DejaVue) zdecydowałem się na fonty Quasi. Wprawdzie są one już obsolete ale działają z fopem a fonty TeX Gyre, które są lepszą wersją Quasi -- nie bardzo. [Są problemy nawet po konwersji OTF->TTF.]

Położenie fontów w systemie jest określone w pliku conf/userconfig.conf. Ponieważ ścieżka do fontu nie może być zaszyta na zicher, plik conf/userconfig.conf rozpoczyna się od następującej deklaracji DOCTYPE:

<!DOCTYPE configuration SYSTEM "config.dtd" [
<!ENTITY fop.home  "@dbf.basedir@">
<!ENTITY ttf.dir   "@dbf.basedir@/fonts">

Napisy @dbf.basedir@ są zamieniane na to co trzeba po uruchomieniu ant -f build-docbook.xml dbf.init (trzeba to zrobić dokładnie raz). Cel (target) dbf.init wygląda zaś następująco:

 <target name='dbf.init' description='Adjust some system specific files'>

  <copy file="${basedir}/conf/userconfig.conf" tofile='${basedir}/conf/userconfig.xml'
     overwrite="true" failonerror="false" filtering="on" >
    <filterset>
      <filter token="dbf.basedir" value="${basedir}"/>
    </filterset>
  </copy>
  </target>

Jak widać plik conf/userconfig.conf jest kopiowany do conf/userconfig.xml a dodatkowo napisy @dbf.basedir@ są zamieniane na bieżącą wartość ${basedir}. To się nazywa token substitution (cf. Using Ant as a Text Substitution Preprocessor).

Ostatni etap polonizacji AVDF to poprawienie plików html.xsl, htmlsingle.xsl z katalogu src/styles. Dodałem do plików html.xsl oraz htmlsingle.xsl:

<xsl:output method="html" 
     encoding="utf-8"
     indent="no"
     saxon:character-representation="native;decimal" 
     xmlns:saxon="http://icl.com/saxon" />

<!-- zapisuje znaki `natywnie' a nie jako encje (domyślnie) -->
<xsl:param name="chunker.output.encoding" select="'utf-8'"/>
<xsl:param name="saxon.character.representation" select="'native;decimal'"/>

A do pliku pdf.xsl (z tego samego katalogu):

<!-- przełącza się na fonty Quasi, domyślnym fontem szeryfowym jest
 QuasiPalatinoTTF, zmień na QuasiTimesTTF jeżeli ma być Times New Roman -->
<xsl:param name="sans.font.family" select="'QuasiSwissTTF'"/>
<xsl:param name="title.font.family" select="'QuasiSwissTTF'"/>
<xsl:param name="body.font.family" select="'QuasiPalatinoTTF'"/>
<xsl:param name="monospace.font.family" select="'QuasiCourierTTF'"/>

Powyższe to minimum: polskie znaki są prawidłowo wyświetlane na ekranie oraz -- co ważne -- zapisywane w pliku jako sekwencje UTF a nie w postaci encji (tj. &oacute;). Jeżeli układ graficzny dokumenty komuś nie odpowiada, no to musi jeszcze bardziej zmodyfikować pliki .xsl i/lub CSS (oczywiście szablony CSS dotyczą wyłącznie dokumentów HTML).

url | Wed, 27/08/2008 13:11 | tagi: , , ,
Publikowanie ciekawych miejsc z Googleearth

Jak w googleearth doda się żółtą pinezkę (dodaj oznaczenie miejsca), to zaznaczone miejsce jest zapisywane w pliku ~/.googleearth/myplaces.kml. Plik ten oprócz informacji o pinezkach zawiera różne inne informacje. Poniższy skrypt upraszcza myplaces.kml usuwając wszystko za wyjątkiem węzłów Document/Folder/Placemark jeżeli element Folder zawiera napis "Moje miejsca":

<?xml version="1.0" encoding="iso-8859-2"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    xmlns:kml="http://earth.google.com/kml/2.2" version="1.0" >
  
  <xsl:output method="xml" indent="yes" />

  <xsl:template match='/'>
    <kml xmlns="http://earth.google.com/kml/2.2">
      <Document>
	<name>Ciekawe miejsca Tomasza Przechlewskiego</name>
	<xsl:apply-templates select='//kml:Document/kml:Folder[kml:name/text()="Moje miejsca"]/kml:Placemark' />
      </Document>
    </kml>
  </xsl:template>

  <xsl:template match="kml:Document/kml:Folder/kml:Placemark">
    <xsl:copy-of select="."/>
  </xsl:template>
</xsl:stylesheet>

Koniecznie trzeba używać przestrzeni nazwa. Inaczej nie działa: kml:Document oraz Document to dwie różne rzeczy.

Moje miejsca są tutaj.

url | Thu, 08/05/2008 12:50 | tagi: , ,
Czy flickr umie liczyć?

Flickr wyświetla liczbę że tak powiem odsłon pod każdym zdjęciem, zbiorczo dla każdego zbioru oraz łącznie dla całego albumu (zakreślone na czerwono na rysunkach poniżej). Wydawać by się mogło, że np. sumując odsłony dla wszystkich zdjęć otrzyma się łączną liczbę odsłon w albumie, to znaczy ile razy oglądano nasze zdjęcia. Już na pierwszy rzut oka widać, że tak nie jest. Po prostu nic nie jest sumowane a każdy licznik ,,liczy'' swoją stronę. Odzielnie jest sumowana ,,strona główna'', oddzielnie każda strona dla pojedynczego zdjęcia i oddzielnie strona główna każdego zbioru.

A jak obliczyć łączną liczbę odsłon dla wszystkich zdjęć? Wydawałoby się, że to pryszcz, bo flickr słynny jest ze swojego API. Akurat tego jednak nie da się ustalić -- nie ma takiej metody. Wprawdzie flickr.activity.userPhotos. zwraca m.in. liczbę wyświetleń każdej pojedynczej strony, ale tylko dla stron na których coś się stało: dodano komentarz, ktoś dodał taga albo dodał zdjęcie do swoich ulubionych. Do tego maksymalnie można ściągnąć 50 zdjęć na raz (maksymalna wartość per_page), parametr timeframe może przyjąć maksymalnie wartość jednego miesiąca (30d, większe wartości są ignorowane) a metodę można uruchomić powtórnie nie częściej niż co godzinę (czyli co godzinę można ściągnąć jedną stronę). Poddałem się...

Nie ustaliłem wprawdzie ile było odsłon zdjęć w moim albumie ale eksperymentując z API flickera odkryłem przynajmniej jak można obejść się bez perlowego pakietu Flickr-API (ale nie bez Perla). Otóż wystarczą moduły LWP::Simple oraz Digest::MD5:

Niektóre metody nie wymagają uwierzytelnienia. Ich wywołanie jest szczególnie proste -- nie jest potrzebny nawet moduł Digest::MD5 -- i sprowadza się do konstruowania adresów URL według następującego schematu (znak \ na końcu oznacza kontynuację wiersza):

http://www.flickr.com/services/rest/?method=metoda&parametr1=wartość1\
  &parametr2=wartość2...

W metodach, które uwierzytelnienia wymagają sprawa się komplikuje. Trzeba podać api_key, auth_token oraz secret (poniżej nazwany shared_secret) opisane tutaj i/lub w dokumentacji modułu Flickr-Upload. Najpierw należy zbudować napis według schematu:

secretapi_keyapi_keyauth_tokenauth_tokenmethodmethodarg1wart1arg2wart2 ... 

Następnie utworzyć jego skrót za pomocą funkcji MD5. W przypadku Perla może to wyglądać jak na poniższym przykładzie (metoda flickr.activity.userPhotos ma argumenty page, per_page oraz timeframe). Obliczony skrót dodajemy jako ostatnią część adresu URL:

Digest::MD5 qw(md5_hex);
my $method = 'flickr.activity.userPhotos';

 ## ...
 ## skrót MD5:
my $api_sig = md5_hex( "${shared_secret}api_key${api_key}auth_token${auth_token}method${method}" .
   "page${page}" . "per_page${per_page}" . "timeframe${timeframe}" ) ;

my $url = "http://www.flickr.com/services/rest/?method=$method" .  
   "&api_key=$api_key" . "&auth_token=$auth_token" . 
   "&page=$page" . "&per_page=$per_page" .
   "&timeframe=$timeframe" . "&api_sig=$api_sig" ; ## wstaw skrót tutaj

print $url;

Przy okazji -- jak to często bywa -- znalazłem ciekawą stronę dotyczącą języka Perl. Jest też na ww. stronie opis pakietu Flickr-Upload, z którego też korzystam. Norman Walsh zaimplementował nawet API flickra w XSLT -- ciekawe ale przydatność taka sobie.

url | Wed, 14/11/2007 08:28 | tagi: , , , ,