życie zabija powoli :)

Jak zacząć z latex?

Na początek jak zrobić minimalny poprawny dokument:

otwieramy edytor tekstowy i piszemy co następuje

\documentclass{minimal}



\begin{document}



\end{document}

Na tym etapie nieistotne jest w czym napisaliśmy ten plik. Ale wkrótce będzie to ważne. Zapisujemy plik jako np dokument.tex

Na początek możemy spróbować skompilować dokumentację, poleceniem

pdflatex dokument.tex

, lub jeżeli mamy jakiś edytor z obsługą LaTeX, szukająć w menu polecenia „PdfLatex”.

Powinien wygenerować się nam pusty dokument w formacie pdf.

Jeżeli nie – nasza instalacja texlive/miktex jest niekompletna.

Dopiszmy teraz między linie \begin i \end dowolną treść, najlepiej z polskimi znaczkami.

\documentclass{minimal}



\begin{document}

Zażółć gęślą jaźń

\end{document}

Tutaj pojawia się problem – latex może nie zgadnąć w jakim kodowaniu podaliśmy mu tekst. Po wygenerowaniu w pliku pdf mogą być „krzaki” zamiast polskich znaków ( jeżeli nie było, masz farta, ale przed problemem daleko nie uciekniesz ;-) ) .

Dlatego też dopiszmy do pliku, pod pierwszą linią następujące polecenia :

\usepackage[cp1250]{inputenc}
\usepackage[T1]{fontenc}

, lub

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}

Wpisy te ustalają wejściowe kodowanie cp1250 (używane domyślnie w windows), lub utf8 (domyślne na większości nowoczesnych dystrybucji linuksa). Wtedy pdflatex wie z jakim kodowaniem ma do czynienia.

W razie wątpliwości – Jeżeli piszesz pod windows w notatniku, lub innym windowsowym edytorze który nie pozwala wybrać kodowania przy zapisie – spróbuj dodać wpis z cp1250. W przeciwnym razie zapisuj pliki w kodowaniu utf8 i używaj utf8.

Drugi wpis ustala kodowanie czcionki która zostanie wykorzystana w pliku pdf, na ogół wystarcza podanie T1, dla większości europejskich języków.

Oczywiście kodowań jest więcej, ale te dwa są najczęściej spotykane (w okolicach Polski).

Wygenerujmy plik pdf jeszcze raz. Łatwo zauważyć że wizualnie nie wygląda zbyt imponująco. To dlatego że użyliśmy stylu minimal aby ograniczyć ilość komend (na początek)

Jako pracę domową, proponuję zrobić kilka plików, i sprawdzić jak ilość pustych linii w tekście wpływa na jego układ na końcowym dokumencie pdf.

ps. Kolejny wpis juz wkrótce.

Libre.fm

Od wczoraj zaczalem kombinowac ze stroną libre.fm.

W sumie jest to strona o takim samym przeznaczeniu co last.fm. Z wyjątkiem tego że jest darmowe, w stanie alpha, oraz wykorzystuje ten sam protokół scrobblowania utworów. No i cały kod strony jest otwarty i dostępny – w ten sposób każdy może postawić sobie własną stronę tego typu, mając serwer z php oraz bazą danych.

Na razie udało mi się scrobblować dane na stronę klientem mpdas. Efekt widać tutaj

Dostęp do strony na razie jest poprzez zaproszenie (które jest obecnie zablokowane), ale myślę że to się wkrótce zmieni.

Pandoc – narzedzie do konwersji plików tekstowych

Dzisiaj przypadkiem odkryłem programik o nazwie pandoc. Potrafi on konwertować pliki z różnych formatów między sobą, np latex, markdown, html, „goły” txt, w praktycznie każdej kombinacji.

Szczególnie ciekawa jest możliwość łatwego skonwertowania gołego tekstu do latex lub, coraz bardziej mnie interesującego formatu Markdown.

Link do strony projektu – KLIK. Z tego co widzę programik jest dostępny w AUR archlinuksa, być może dla innych dystrybucji też się znajdzie.

Niestety takie konwertery na ogół wykładają się na „ambitniejszych” konstrukcjach w LaTeX (jak niektóre stosowane u mnie), więc przydatne będą dla ludzi piszących prostszą dokumentację lub krótkie notki. Programik na pewno przyda się początkującym użytkownikom Markdown lub LaTeX, oraz tym którzy nigdy nie pamiętają jak się pisze podstawowy nagłówek dokumentu (ja też nigdy nie pamiętam).

Zakładam tu, że pandoc jest w miarę stabilny na prostych plikach, bo przetestowałem tylko kilka prostych przykładów.

dwie klawiatury – dwa układy klawiszy

Czesi mają przesrane. Ich układ klawiatury jest taki, że zamiast 1234567890 na górnym rządku klawiszy wychodzą ich czeskie znaczki. W przypadku gdy komputer z czeskim układem klawiatury korzysta z czytnika kodów kreskowych – pojawia się wyzwanie dla kogoś kto taki komputer konfiguruje.

Czytnik bowiem działa jak klawiatura. Bez szczególnego majstrowania będzie pracować w kodowaniu klawiatury. A poniewaz większośc kodów kreskowych składa się z cyfr… sami wiecie :]

Ale w miarę aktualna wersja X.org potrafi rozwiązać taki problem – wystarczy podpiąć sobie obsługę daemona HAL do x.org i w jakiś sposób odróżnić klawiaturę i czytnik od siebie :

Uwaga : W przypadku gdy klawiatura jest na ps/2 a czytnik na usb – jest łatwo. Gdy czytnik jest na przelotce spięty z klawiaturą w jednym porcie ps/2 – to rozwiązanie raczej nie zadziała, ponieważ czytnik nie będzie widoczny jako osobne urządzenie wejściowe.

Najpierw sprawdźmy co mamy w systemie z urządzeń wejściowych :

# lshal | grep input | grep product
  input.product = 'Macintosh mouse button emulation'  (string)
  input.product = 'Power Button (CM)'  (string)
  input.product = 'Power Button (FF)'  (string)
  input.product = 'PC Speaker'  (string)
  input.product = 'AT Translated Set 2 keyboard'  (string)
  input.product = '?Symbol Technologies, Inc, 2002 Symbol Bar Code Scanner'  (string)
  input.product = 'Logitech USB-PS/2 Optical Mouse'  (string)

Jak widać mam tutaj czytnik Symbol, mogę go odróżnić po kluczu input.product od klawiatury. Bazując na tym przerabiamy domyślny konfig hal’a dla urządzeń wejściowych :

< >

/etc/hal/fdi/policy/10-keymap.fdi

<?xml version=„1.0” encoding=„ISO-8859-1”?> <!— * SGML * —>

<deviceinfo version=„0.2”>
  <device>
    <match key=„info.capabilities” contains=„input.keymap”>
      <append key=„info.callouts.add” type=„strlist”>hal-setup-keymap</append>
    </match>



<!— czytnik —>

<match key=„input.product” contains=„Symbol”>
    <merge key=„input.xkb.rules” type=„string”>base</merge>
    <merge key=„input.xkb.model” type=„string”>keyboard</merge>
    <match key=”/org/freedesktop/Hal/devices/computer:system.kernel.name”
string=„Linux”>
    <merge key=„input.xkb.model” type=„string”>evdev</merge>
    <merge key=„input.xkb.layout” type=„string”>pl</merge>
    <merge key=„input.xkb.variant” type=„string” />
    </match>

</match>

</device>

  <device>
    <match key=„info.capabilities” contains=„input.keymap”>
      <append key=„info.callouts.add” type=„strlist”>hal-setup-keymap</append>
    </match>
<!— klawirka —>
    <match key=„input.product” contains=„keyboard”>
      <merge key=„input.xkb.rules” type=„string”>base</merge>

      <!— If we’re using Linux, we use evdev by default (falling back to
           keyboard otherwise). —>
      <merge key=„input.xkb.model” type=„string”>keyboard</merge>
      <match key=”/org/freedesktop/Hal/devices/computer:system.kernel.name”
             string=„Linux”>
        <merge key=„input.xkb.model” type=„string”>evdev</merge>
      </match>



      <merge key=„input.xkb.layout” type=„string”>cz</merge>
      <merge key=„input.xkb.variant” type=„string” />
    </match>

  </device>
</deviceinfo>

Teraz pozostaje skonfigurować X.org aby korzystał z ustawień hal, poprzez wpis w xorg.conf :

Section "ServerFlags"
        Option "AutoAddDevices" "True"
EndSection

oraz restart hal’a i X.org. Klawiatura powinna działać po czesku, a czytnik po polsku. Metodę można oczywiście zaadoptować do innych urządzeń ;-)

Plik jest oparty na przykładzie z hal. Kluczowe są linijki

<match key=„input.product” contains=„Symbol”>

<merge key=„input.xkb.layout” type=„string”>pl</merge>

które identyfikują urządzenie i ustawiają dla niego układ klawiatury.

Pojawia się pytanie – jak to zrobić w windows?