Weblog Tomasza Przechlewskiego

Pobieranie informacji o książce/płycie o podanym numerze UPC/EAN z amazon.com

Jest gotowa aplikacja służąca do katalogowania książek za pomocą czytnika kodów kreskowych opisana w artykule A Perl script catalogs books and CDs... (tu jest wersja HTML z likiem do kodu źródłowego opisanego skryptu).

Od pierwsze strzału aplikacja nie działa. Żeby w ogóle Perl chciał program wykonać należy z przodu pliku dodać wiersz:

## http://perlmeister.com/forum/viewtopic.php?t=3596&sid=59d9cb0bda64235bda70315d6e9031e8
use POE::Loop::Tk ;

Teraz działa ale nie zawsze. Ponadto program Schilli'ego w zamierzeniu obsługuje tylko kody UPC a moje książki/płyty są oznaczane kodem UPC i/lub EAN.

Kody EAN są 13 cyfrowe a UPC 12 cyfrowe. Żeby było śmieszniej amazon.com nie rozumie kodów EAN -- trzeba odpytywać jakąś europejską filię, np. amazon.co.uk.

## moja wersja procedury amzn_fetch:
sub amzn_fetch {
  my($upc_or_ean) = @_;
  my $resp;

  my $amz_locale = 'us'; # default is US
  if ( length ("" . $upc_or_ean ) > 12) {
    $amz_locale = 'uk';
    print STDERR "*** $upc_or_ean looks like EAN code\n";
  } else {
    $amz_locale = 'us';
    print STDERR "*** $upc_or_ean looks like UPC code\n";
  }

  my $amzn = Net::Amazon->new(
      token => $amz_token,
      secret_key => $amz_secret,
      locale => $amz_locale,
      ua    => $UA,
  );

  my $req ;
  if ( $amz_locale eq 'uk') {
    print STDERR "*** Fetching from $amz_locale with mode $current_amz_cat ***\n";
    $req = Net::Amazon::Request::EAN->new(
          ean  => $upc_or_ean,
          mode => $current_amz_cat,
         );
  } else {
      print STDERR "*** Fetching from $amz_locale with mode $current_amz_cat ***\n";
       $req = Net::Amazon::Request::UPC->new(
	  upc  => $upc_or_ean,
          mode => $current_amz_cat,
       );
  }

  $resp = $amzn->request($req);

 ## ... itd ...

Skrypt Schilli'ego zakłada ponadto, że zapytanie zawiera UPC/EAN oraz nazwę kategorii (books, music DVD), bo tak kiedyś działał Amazon. Teraz wydaje się, że działa inaczej. Podanie np. kodu książki + kategorii music, daje błąd. Nie zamierzałem grzebać w pakiecie Net::Amazon, więc zmieniłem skrypt w ten sposób, że kategoria jest deklarowana explicite przez operatora:

my @MODES = qw(books music dvd);

## ... itd ...

## cf. http://www.ibm.com/developerworks/aix/library/au-perltkmodule2/
my $MODE  = $top->Label();

my $current_amz_cat = $MODES[0]; ## domyślną jest pierwsza kategoria
foreach(@MODES) { 
  $MODE->Radiobutton( 
      -text => $_, 
      -value=> $_, 
      -variable => \$current_amz_cat,
      -command => sub {
	print STDERR "*** Current mode is: $current_amz_cat \n";
      } )->pack(-side => 'left', -expand => '1', -fill => "x" )
}

Na wypadek gdyby operator zapomniał kliknąć w co trzeba:

  if($mode eq "books") {

    eval { $resp->properties()->isbn(); } ; ## bez eval będzie krasz

    if ($@) {## błąd jeżeli `item' nie zawiera isbn, tj. nie jest książką... 
      print STDERR "*** ERROR: $@\n";
      $PRODUCT->configure( -text => "NOT BOOKS TYPE ITEM / REENTER"); return 1;  }
 ## ... itd ...

Opis książki różni się od opisu CD (np. książka ma element isbn a płyta tracks). Schilli ominął ten problem ignorując elementy specyficzne, definiując jeden typ rekordu i jedną tabelę. Ostatnia zmiana w porównaniu do skryptu Schilli'ego, to dodanie do bazy pola przechowującego opis książki/CD w formacie XML (zamiast definiowania różnych tabel dla książek, płyt CD i filmów). W zależności od typu danych ten opis XML zawiera to co trzeba (czyli specyficzne dla opisywanego obiektu atrybuty). Np:


 Edward R. Tufte
 Edward R. Tufte
 The Visual Display of Quantitative Information
 Graphics Press USA
 2nd edition
 2001-01-31
 0961392142
]]>

Tak działającym skryptem skatalogowałem jakieś 30--40% zawartości mojej biblioteki. Stare książki nie mają kodu kreskowego. Część polskich książek jest w zasobach Amazona ale części nie ma (np. książki wyd. Readme -- i słusznie bo to prawie w całości badziewie:-)

Tu jest corpus delicti. Moja biblioteka jest tutaj i tutaj -- jakby ktoś był ciekaw.

Skrypty można znaleźć tutaj.

Dopisane 1 września 2011: Zapomniałem napisać o istotnej sprawie. Żeby móc odpytywać Amazon trzeba się zapisać do Product Advertising API, tj. założyć konto. Aby móc korzystać z ww. API trzeba wypełnić odpowiedni formularz i zgodzić się na licencję, która jest mówiąc oględnie taka sobie.

To begin the enrollment process, you must submit a complete and accurate enrollment form. In your enrollment form, you must describe the application you intend to develop and use with the Product Advertising API or on which you intend to display Product Advertising Content. We will evaluate your enrollment form and notify you of its acceptance or rejection. We may reject your enrollment form if we determine that your application is unsuitable. Unsuitable applications include those that:

do not have as their principal purpose advertising and marketing the Amazon Site and driving sales of products and services on the Amazon Site

Wygląda groźnie ale wystarczy podać -- jako opis aplikacji -- URL, pod którym będziemy ,,promować'' Amazon. Proces koncesyjny jest (póki co?) uproszczony -- nikt niczego nie rozpatruje. Ale to się może zmienić...

In addition, we may terminate or suspend your license to access and use the Product Advertising API, Data Feed, or any part of or all Product Advertising Content at any time without terminating this License Agreement by giving you written notice.

Jednym słowem do poważnych zastosowań to się nie nadaje. Ale do katalogowania własnej biblioteczki może być...

Po założeniu konta, pod adresem Manage Your Account→Access Identifiers →Click here w rubryce Access Credentials tworzymy/zarządzamy Access Key ID/Secret Access Key -- niezbędnymi do korzystania z opisywanego wyżej skryptu:

my $amz_token = '???'; ## Access Key ID
my $amz_secret = '???'; ## Secret Access Key

url | Wed, 31/08/2011 19:35 | tagi: amazon, aws, perl

Wycieczka na Hel

Popłynęliśmy wczoraj (30 08) z KP i JP na Hel tzw. tramwajem wodnym z Sopotu na Hel. Bilety (1 normalny i dwa ulgowe + bilety na trzy rowery za 45 PLN) kupiliśmy w kasie na molo poprzedniego dnia. Z Helu pojechaliśmy do Władysławowa (jakieś 35 km) gdzie zjedliśmy obiad w tawernie/barze Checz. Po obiedzie pojechaliśmy do Pucka. W Pucku JP miał dość i pojechał dalej pociągiem a my we dwójkę przez Rzucewo i Połchowo do Rumii. Tam wsiedliśmy w SKM i do domu... Razem wyszło rowerem ca 80 km.

Ślad jest tutaj, a zdjęcia tutaj.

url | Wed, 31/08/2011 10:57 | tagi: inne, rowery

Fixing /dev/ttyUSB0 permissions for GPSBabel in fedora 15

Gpsbabel does not work at all in brand new fedora 15. I have followed suggestions from https://bugzilla.redhat.com/show_bug.cgi?id=713483 and rebuild it from the source .rpm. I have also fixed udev rules, as described here:

## /etc/udev/rules.d/51-garmin.rules
SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", MODE="0666"

Now (sometimes) I was able to fetch GPX trace but only as a root.

Inspecting /var/log/messages I noticed suspicious messages from gpsd daemon, ie:

Aug 14 16:50:09 darkstar gpsd.hotplug: gpsd_control(action=add,arg=/dev/ttyUSB0)

Moreover the deamon starts/stops in some tricky way as it is down if one looks in Programs →Administration→Services, but ps uax | grep gpsd indicates something contrary:

nobody  2530  0.0  0.0  12652  1412 ? S<s  13:31  0:00 gpsd -n -F /var/run/gpsd.sock

As gpsbabel works flawlessly in my fc11 w/o gpsd I have decided to remove it:

yum erase gpsd
## removes also following dependencies:
 kdeutils-libs-4.6.5-2.fc15.i686 kdeutils-4.6.5-2.fc15.i686
 kde-settings-kdm-4.6-10.fc15.noarch kdm-4.6.5-2.fc15.i686
 digikam-1.9.0-2.fc15.i686 digikam-libs-1.9.0-2.fc15.i686
 kdeedu-marble-4.6.5-1.fc15.i686 kdeedu-marble-libs-4.6.5-1.fc15.i686
 kdeplasma-addons-4.6.5-1.fc15.i686
 kdeplasma-addons-libs-4.6.5-1.fc15.i686 ktorrent-4.1.1-1.fc15.i686
 ktorrent-libs-4.1.1-1.fc15.i686 kpackagekit-0.6.3.3-2.fc15.i686
 kde-plasma-networkmanagement-vpnc-0.9-0.53.20110616git.nm09.fc15.i686
 kde-plasma-networkmanagement-openvpn-0.9-0.53.20110616git.nm09.fc15.i686
 plasma-scriptengine-python-4.6.5-2.fc15.i686
 kdenetwork-4.6.5-1.fc15.i686 kdenetwork-libs-4.6.5-1.fc15.i686
 kde-plasma-networkmanagement-pptp-0.9-0.53.20110616git.nm09.fc15.i686
 kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15.i686
 kde-plasma-networkmanagement-libs-0.9-0.53.20110616git.nm09.fc15.i686
 kdebase-workspace-4.6.5-2.fc15.i686
 kdebase-workspace-libs-4.6.5-2.fc15.i686 gpsd-2.95-6.fc15.i686
## and disables the following udev rules:
 ostrzeżenie: /etc/udev/rules.d/99-gpsd.rules zapisano jako
 /etc/udev/rules.d/99-gpsd.rules.rpmsave

Pretty surprising that so many KDE packages depends on gpsd! Now I have access to gpsbabel as normal user. (It needs 10--20 second to plug the device in fc15 while in fc11 it was instantaneously.)

Moreover my Gnome3 desktop once unusable looks much better (I still intend to use Xfce however). It seems KDE in FC15 interfere in a nasty way...

Added 24 august 2011: Xine error while playing .avi file resolved.

$ rpm -qa '*ffmpeg*' 
ffmpeg-devel-0.7-0.3.20110612git.fc15.i686
ffmpeg-libs-0.7-0.3.20110612git.fc15.i686

$ rpm remove ffmpeg-devel
$ yum downgrade ffmpeg-libs

Removed:
ffmpeg-libs.i686 0:0.7-0.3.20110612git.fc15 

Installed:
ffmpeg-libs.i686 0:0.6.90-0.2.rc0.fc15

xine now works with .avi. Btw:

$ rpm -qa '*git*'
emacs-git-el-1.7.6-1.fc15.noarch
emacs-git-1.7.6-1.fc15.noarch
git-1.7.6-1.fc15.i686

It appears ffmpeg-libs-0.7-0.3.20110612git and ffmpeg-devel-0.7-0.3.20110612git were the only compiled from git shapshots packages installed in my system (providing gip snapshots are always marked by adding git to package name).

It is convenient to add exclude=ffmpeg-libs to /etc/yum.conf to prevent yum to update ffmpeg libs with yum update command.

Added 31 august 2011: According to man xine one can specify ``additional command line arguments'' using ~/.xine/xinerc where each line specifies an additional command line argument. However --geometry 990x650 does not work, as well as -G 990x650. By trial and error I have figure out the only(?) working syntax:

##vi ~/.xine/xinerc
-G990x650

Note no space after -G.

url | Fri, 19/08/2011 08:26 | tagi: fc15, fedora, gpsbabel, linux

Katalogowanie książek -- pierwsze rezultaty

Pobieranie informacji o książce/płycie o podanym numerze UPC (z amazon.com):

#!/usr/bin/perl
# 
use Net::Amazon;
use Net::Amazon::Request::UPC;

my $code = '633367991522' ; # UPC (z kodem EAN są problemy)

# Token/secret_key do pobrania po zarejestrowaniu się na str. 
# https://aws-portal.amazon.com/gp/aws/developer/account/index.html/177-3749078-2923747
my $ua = Net::Amazon->new(
   token       => '####################',
   secret_key  => '########################################', 
);

my $req = Net::Amazon::Request::UPC->new( upc  => $code, mode => 'music', );

# Response is of type Net::Amazon::Response::UPC
my $resp = $ua->request($req);

if($resp->is_success()) {
   print $resp->as_string(), " (UPC)\n"; } else {
   print "Error: ", $resp->message(), "\n"; }
# end

url | Tue, 16/08/2011 22:55 | tagi: amazon, aws, perl

Aktualizacji mojego Linuksa ciąg dalszy...

Aparat PTP

Od ręki nie działa. Próbowałem rozwiązać problem instalując następujące pakiety:

yum install  gphoto2 gvfs-gphoto2 gtkam digikam gthumb geeqie

Geeqie to zamiennik gqview, które używałem do tej pory. DigiKam nie działa (gryzie się z XFce). Wydaje mi się, że większość tego co zainstalowałem nie jest potrzebna -- istotne jest geeqie, dzięki któremu mogę wygodnie zaimportować zdjęcia z aparatu na komputer (lądują w katalogu ~/Pictures).

Wysyłanie fotek na flickr.com za pomocą Emacsa

Prawie działa. Problem stanowią słowa kluczowe zawierające polskie znaczki. Trzeba nieco zmodyfikować skrypty generujące bazę słów kluczowych tj. flickr_getalltags, i inne.

Cała procedura odświeżania tagów i innych metadanych jest uruchamiana skryptem flickr_update_kb, który w uproszczeniu wygląda następująco:

#!/bin/bash
# Get list of public photos with 'flickr.people.getPublicPhotos
flickr_getphotolist.pl -u hr.icio

# Refreshing information on tags/sets/geolocs"
# Get information on sets defined by the user:
flickr_getsets && \
# Get tags from flickr for current user
flickr_getalltags && \
# Get information on groups to which one can add photos
flickr_getgroups && \
## For flickr_xml2el we need _special treatment_ otherwise UTF is spoiled
PERL_UNICODE=S flickr_xml2el > ~/.flickr/hr.icio.el

cd ~/.knows &&  make 2flicker && \
cd ~/.flickr && make check

Z nieustalonych powodów cześć komunikatu zwracana przez flickra jest teraz kompresowana (a nie była -- nowsza wersja pakietu Perla?). Z tego też powodu konstrukcja (ze skryptu flickr_getalltags.pl -- w innych skryptach podobnie):

my $xm = $xmlp->XMLin($response->{_content}, forcearray=>[raw]);

została zamieniona na:

## zmienione 15.08.2011 (gzip as content-encoding)
## ustalenie w jakim `content_encoding' jest _content
my $content_encoding = $response->{_headers}->{'content-encoding'} ;
my $plain_content;
if ($content_encoding =~ /gzip/ ) {## jeżeli gzip to odpakować:
    $plain_content = Compress::Zlib::memGunzip( $response->{_content});
} else { $plain_content = $response->{_content};  }

Powyższe załatwia problem z (nie) działaniem skryptów flickr_getphotolist.pl, flickr_getsets, flickr_getalltags, flickr_getgroups.

Konwersja plików XML do formatu Emacsa za pomocą skryptu flickr_xml2el daje w rezultacie las komunikatów Wide character in print at... a plik wynikowy jest błędnie kodowany. Problem ciągle wraca a ja ciągle nie wiem czemu. Zaślepkowo pomogło dodanie PERL_UNICODE=S (zaklęcie to należy wstawić w odpowiednie miejsce także do pliku Make w katalogu ~/.knows).

Po tych wszystkich ww. zabiegach (które zajęły mi pół dnia) jestem w stanie odświeżyć bazę metadanych z mojego konta na flickr.com. Sukces:-)

url | Mon, 15/08/2011 18:55 | tagi: emacs, fc, fc15, fc8, fedora, flickr, linux, perl, utf8

Aktualizacja mojego Linuksa (przejście z FC8 na FC15)

Przejście z FC8 na FC15 rozpoczęło się od wymiany starego dysku (250Gb) na WDC EADS 1Tb (Green Power). Już na początku się zdarzył falstart, bo zarówno BIOS jak i Linux utrzymywał uparcie, iż dysk ma pojemność ok. 33Mb. Nie wchodząc w szczegóły problem powoduje błąd w BIOSie (starych) płyt Gibabyte (cf. WD10 EADS problem ..from 1TB to 31MB). The reason the drive is reporting 33MB is that Gigabyte's BIOS has a bug that incorrectly adjusts the drive's capacity after creating the HPA. 1TB drives are reduced to 33MB, 1.5TB become 500GB, and 2TB become 1TB. (cf. Lost Partition on Hitachi...).

Więcej na temat można się dowiedzieć wpisując w Google HDA+Gigabyte i/lub ze strony Wikipedii.

Aby przywrócić ,,fabryczną'' pojemność postąpiłem wg. zalecenia: The solution is to use a tool such as HDAT2 or the HDD Capacity Restore Tool to remove the HPA (Host Protected Area), tyle że zamiast HDAT2/HDDCRT użyłem poczciwego hdparm.

## Potrzebny jest hdparm > 8.0 cf http://en.wikipedia.org/wiki/Host_protected_area
## w zapisie p1953525168 litera `p' jest OK i oznacza `permanent'
[root@darkstar]#hdparm -N p1953525168 /dev/sdb

/dev/sdb:
 setting max visible sectors to 1953525168 (permanent)
 max sectors   = 1953525168/1953525168, HPA is disabled

[root@darkstar]#hdparm -N /dev/sdb

/dev/sdb:
 max sectors   = 1953525168/1953525168, HPA is disabled

Teraz podzieliłem dysk na partycje używając gparted: / (ok. 50Gb), /swap (ok. 2Gb), /boot (ok. 500Mb), /home (ok. 750Gb). Zainstalowałem FC15 używając do tego obrazu Fedora-15-i686-Live-Desktop ze strony http://torrent.fedoraproject.org/. Instalacja zakończyła się dziwnym błędem, objawiającym się tym, że partycja / miała 50Gb według np. fdiska, a 2,5Gb tak w ogóle i na prawdę. W drugiej próbie podział na partycje został wykonany przez instalator i wtedy było dobrze. Czemu było źle za pierwszym razem nie wiadomo...

Z jakiś powodów Fedora gadała do mnie po angielsku (Założyłbym się, że w czasie instalacji nikt mnie się nie pytał czy chcę po angielsku czy nie...) Zmieniłem to wpisując do /etc/sysconfig/i18n:

##LANG="en_US.UTF-8" ## tak było po instalacji
LANG="pl_PL.UTF-8"
SYSFONT="latarcyrheb-sun16"

Jednym słowem zamierzam przejść na Unicode (do tej pory używałem ISO-8859-2). Kompatybilność wstecz gwarantuje mi Emacs, w którym redaguję moje dokumenty/pliku tekstowe. Dla przypomnienia następujące zaklęcia gwarantują, że Emacs przełączy się na właściwe kodowanie:

% -*- coding: iso-8859-2 -*-
tra-ta-tata

% Local Variables:
% coding: iso-8859-2
% ispell-local-dictionary: "polish"
% End:

Zaklęcie % -*- coding: iso-8859-2 -*- musi być w pierwszym wierszu. Wpisy Local Variables: ... End: na końcu pliku. Do przestawienia kodowania wystarczy albo wpis w pierwszym wierszu albo Local Variables:. Można zastosować też oba na raz -- nie będzie błędu.

Gnome3

Po kilkugodzinnej walce z Gnome 3 zmieniłem go na Xfce. Szkoda czasu na deliberowanie, w jaki sposób zdefiniować tak elementarne rzeczy, jak przykładowo skrót do programu (Nb. sposoby podane np. tu albo tu u mnie nie działają.)

Gpsbabel

Fundamentalna dla mnie aplikacja, a mianowicie gpsbabel nie działa. Na szczęście, ktoś już z tym walczył przede mną (cf. libusb-config missing from libusb-devel):

## Gpsbabel w fc15 jest `broken' trzeba go skompilować:
wget http://mirrors.xmission.com/fedora/updates/15/SRPMS/gpsbabel-1.4.2-6.fc15.src.rpm  
## bo nie bo w http://download.fedoraproject.org/pub/fedora/linux/releases/15/

rpm -ivh gpsbabel-1.4.2-6.fc15.src.rpm
## się rozpakował w /root/rpmbuild/

yum install rpm-build  rpm-build-libs
rpmbuild -ba /root/rpmbuild/SPECS/gpsbabel.spec # tam się rozpakował SPEC
rpm -Uvh /root/rpmbuild/RPMS/i386/gpsbabel-*
## zgłaszany jest konflikt zatem
rpm -e gpsbabel
rpm -Uvh /root/rpmbuild/RPMS/i386/gpsbabel-*
##

## Poniższe jest potrzebne do moich skryptów obsługujących ściąganie śladu z Legenda:
wget http://search.cpan.org/CPAN/authors/id/B/BL/BLUEFEET/Geo-Distance-0.17.tar.gz
tar -zxvf Geo-Distance-0.17.tar.gz && cd Geo-Distance-0.17
perl Makefile.PL && make && make install

Niestety coś się zmieniło i magiczne zaklęcie (wpisane do /etc/udev/rules.d/51-garmin.rules) działające w poprzednich fedorach:

SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", MODE="0666"

przestało działać. Na razie odpuszczam i będę ściągał ślady jako root; z czasem się dowiem jak problem pokonać.

Googleearth

Instalowanie Googleearth też nie okazało się oczywiste:

wget http://dl.google.com/earth/client/current/GoogleEarthLinux.bin
sh ./GoogleEarthLinux.bin
## się wysypało z błędem, przy czym
## skrypt pyszczył, że mu brakuje LSB
yum install redhat-lsb redhat-lsb-graphics

## dalej się wysypuje. Ale znalazłem via google co robić:
./GoogleEarthLinux.bin --target /tmp/ge
## kończy się błędem ale idziemy dalej:-)

cd /tmp/ge/setup.data/bin/Linux/x86/
mv setup.gtk setup.gtk2
cd /tmp/ge
## poniższe polecenie jako `root' oczywiście:
./setup.sh

Na razie tyle... Da się tego używać, ale z ostateczną oceną się na razie wstrzymuję -- zobaczymy co jeszcze zostało spartolone...

Dopisane 15 sierpnia 2011: Dopisałem do .emacs polecenia, które mają powodować, że pliki TeXa oraz pliki w formacie Blosxoma są domyślnie redagowane w Emacsie w kodowaniu jednobajtowym:

(modify-coding-system-alist 'file "\\.blx\\'" 'iso-8859-2)
(modify-coding-system-alist 'file "\\.tex\\'" 'iso-8859-2)

Zastanawiam się też nad dodaniem czegoś takiego (najpierw wypróbuję czy na pewno działa):

(modify-coding-system-alist 'process "svn" 'iso-8859-2)

Dopisane 18 sierpnia 2011: Pobieranie zrzutu ekranu. W gnome jest do tego gnome-screenshot a w Xfce -- xfce4-screenshooter (cf. http://goodies.xfce.org/projects/applications/xfmpc). Program gnome-screenshot (uruchamiany jako gnome-screenshot --interactive) działa ,,nieintuicyjnie'' przy wybraniu zrzutu z okna, xfce4-screenshooter działa lepiej

Dopisane 21 sierpnia 2011: Avatary w ekranie logowania (gdm). W internecie są sprzeczne informacje na ten temat. Niektórzy twierdzą, że się nie da. W rzeczy samej sposób najprostszy, a polegający na umieszczeniu stosownej ikony w postaci pliku o nazwie .face w katalogu domowym użytkownika nie działa, ale działa umieszczenie tegoż pliku (niekoniecznie nazywającego się .face tym razem) do katalogu /var/lib/AccountsService/icons/ oraz dodanie do każdego pliku z katalogu /var/lib/AccountsService/users/ wpisu:

Icon=/var/lib/AccountsService/icons/nazwa_pliku_zaw_avatara

Por. https://bugzilla.redhat.com/show_bug.cgi?id=705240.

Dopisane 26 sierpnia 2011: Konfigurowanie drukarki (system-config-printer). Zalecany sterownik pn. HP LaserJet 6P Cups+ Gutenprint v.5.2.7 simplified [en] czasami nie działa (np. plik .ps generowany przez pstops drukuje ohydnymi fontami bitmapowymi o niskiej rozdzielczości). Pomaga przestawienie na sterownik pn. HP LaserJet 6P Foomatic/ljet4.

Dodałem też syntax off do ~/.vimrc ponieważ kolorowane pliki były skrajnie nieczytelne.

Prywatne pakiety R, takie jak Rcmdr będę instalował w katalogu R_LIBS=$HOME/R. Odpowiedni wpis dodałem zatem do ~/.bash_profile.

url | Sat, 13/08/2011 20:30 | tagi: fc, fc15, fc8, fedora, linux

Pxfonts/qxfonts gryzie się inputenc

Zaczęło się od tego, że LaTeX złożył tabelę w taki sposób, iż wszystkie wiersze zostały nałożone na siebie, tworząc jeden wiersz. Usuwając kolejno dołączane pakiety ustaliłem, że ww. dziwny efekt jest spowodowany błędem w pakiecie pxfonts (qxfonts oczywiście też)... A objawia się, jeżeli pakiet ów jest dołączony łącznie z pakietem inputenc.

Gorzej... Czego nie widać na pierwszy rzut oka, pxfonts przedefiniowuje LaTeXa, a konkretnie polecenie \k, które zamiast wstawiać znak ą albo ę wstawia dwa nałożone na siebie znaki, np. a i ogonek. Tak się składało polskie teksty w LaTeXu 20 lat temu...

Za powyższe anomalie odpowiada w pakiecie pxfonts wewnętrzne polecenie: \T@n@@nc@d@ngM@cr@M@d. Wydaje się, że wystarczy wpisać do preambuły:

\def\T@n@@nc@d@ngM@cr@M@d{}

aby usunąć błąd. (Wszystko będzie też OK, jeżeli w tekście nie pojawi się znak zawierający ogonek...)

Do tej pory uważałem pakiety pxfonts/qxfonts za dobrej jakości. Do tego stopnia dobrej, że w książce Nie za krótkie wprowadzenie..., które współtłumaczyłem jest on polecany. Teraz zrobiłem kwerendę w google na okoliczność, i stwierdziłem, że 1) pakiety te wydają się być mało używane, 2) nie są od lat pielęgnowane i 3) można znaleźć opinie o ich kiepskiej jakości. Hmmm...

Z drugiej strony trudno jest znaleźć coś jednoznacznie lepszego...

Mini-przykład ilustrujący problemy zamieszczam poniżej:

url | Thu, 04/08/2011 10:44 | tagi: latex