Acrobat Readera w zasadzie nie używam. Za duże, nieporęczne itp.

Domyślnie -- z przyzwyczajenia -- oglądam pliki pdf w xpdf (dość wiekowej aplikacji) lub za pomocą evince (ten z kolei jest domyślny w rzadkim przypadku korzystania przeze mnie z MS Windows).

Długie dokumenty lubię wydrukować w postaci broszurki (2 strony A5 na kartce A4, druk obustronny czyli 4 strony a5 na kartce) używając do tego pstops. Zatem najpierw PDF→PostScript, a potem zamiana pliku .ps na wersję z dwoma stronami na kartce. Zwykle działa xpdf. Kiedy zawodzi, wtedy próbuję evince, albo jako Wunderwaffe Acrobat Reader. Ostatnio mam już drugi przypadek pliku PDF, w którym po potraktowaniu pstops cudownie rozmnażają się strony. Konkretnie jest ich 2 razy tyle co powinno być. W rezultacie oczywiście broszurka jest do kitu -- strony nie pasują do siebie...

Za słabo znam PostScript żeby ustalić czemu tak, więc próbuję różnych programów: xpdf nie działa, evince nie działa, Reader tak samo. Okular produkuje prawidłowy plik PostScript.

Nb. feralny plik PDF wygenerowano za pomocąInDesign CS5.5 (Adobe PDF Library 9.9).

Taką zamianę można wykonać za pomocą komercyjnej i do tego windzianej aplikacji Acrobat Pro. Zamiast Acrobata Pro można też użyć ghostscripta:

#!/bin/bash
INPUT=$1
OUTPUT=`basename $1 .pdf`_grayscale.pdf
gs -sOutputFile=$OUTPUT -sDEVICE=pdfwrite \
 -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray \
 -dCompatibilityLevel=1.4 $INPUT < /dev/null

Sprawdziłem -- na dużym pliku -- i wygląda, że działa.

Tutaj piszą, że nie zawsze.

Dawno temu zrobiłem systemik formatujący pewien plik XML do postaci pliku PDF. Ten cel jest realizowany na dwa pas. Najpierw skrypt Perla zamienia XML na plik TeXa, który to plik jest zamieniany pdfTeXem na dokument PDF. 10 lat działało i nagle ktoś dostrzegł, że zakładki (bookmarks) są nie po polsku. No nie są, bo kiedyś było to trudne do wykonania... A teraz faktycznie nie jest trudne -- wystarczy zamienić kodowanie z jednobajtowego na UTF-8.

Po tej właśnie linii zaatakowałem problem, tj. 1) zmieniłem kodowanie w generowanym pliku TeXowym z ISO8859-2 na UTF-8 oraz, w związku z tym 2) zmieniłem pdfTeXa na XeTeXa. Jak zwykle nie obyło się bez problemów:

1. Elementy nawigacyjne są definiowane inaczej w XeTeXu niż w pdfTeXu, więc za pierwszym razem bookmarki zniknęły w ogóle. Gdybym swoje makra pisał w LaTeXu problem by nie istniał, ale w plain TeXu zwykle trzeba wszystko samemu... Tym razem na szczęście z pomocą google znalazłem działające gotowe makra pn. navigator.

2. Kolory też są inaczej definiowane. Ja to zrobiłem tak:

   \def\cmykRed{0 1 1 0}
   \def\setcolor#1{\special{color push cmyk #1}}
   \def\endcolor{\special{color pop}}
   
   \setcolor\cmykRed \bf Cośtam-coś-tam-na-czerwono \endcolor
   

3. Miłą cechą XeTeXa jest to, że można korzystać z fontów systemowych. Wymyśliłem zatem, że dokument będzie składany fontem TeX Gyre Heros w odmianie wąskiej. Można to zadeklarować następująco:

   %% Podstawowym fontem jest TeX Gyre Heros w odmianie `Condensed'
   %% cf. http://www.gust.org.pl/projects/e-foundry/tex-gyre/heros
   \def\MainFont{TeX Gyre Heros Cn}\def\MainXFont{TeX Gyre Heros}
   \font\rm = "\MainFont:mapping=tex-text" 
   \font\bf = "\MainFont/B:mapping=tex-text"
   \font\it = "\MainFont/I:mapping=tex-text"
   %% W stopniu 8pt zamiast odmiany wąskiej używamy normalnej %%
   \font\eightrm = "\MainXFont:mapping=tex-text" at 6.25pt
   \font\eightbf = "\MainXFont/B:mapping=tex-text" at 6.25pt
   \font\eightit = "\MainXFont/I:mapping=tex-text" at 6.25pt
   

   Zapis mapping=tex-text oznacza, że font ,,reaguje'' na TeXowe ligatury, m.in -- oraz --- zamieniając je (odpowiednio) na półpauzę i pauzę. Zapis /B włącza odmianę grubą a /I kursywę...

4. I gdy już wszystko było prawie gotowe nieopatrzenie zajrzałem do pliku .log a tam cała masa wpisów:

   Invalid UTF-8 byte or sequence at line 22 replaced by U+FFFD.
   

   Czyli Perl jednak sygnalizował coś brzydkiego wypisując:

   Wide character in print at ....
   

   Mój skrypt czyta plik XML, parsuje go z wykorzystaniem XML::Parser, który to -- jak powszechnie wiadomo -- wypluwa dokument w UTF-8. Więc czemu w efekcie dostaję błędnie kodowany plik?? Ustalenie co jest nie tak zajęło mi kilka godzin a sprawa sprowadzała się do dodania:

   open (OUT, ">:utf8", "plik-out") # zamiast open (OUT, ">plik-out")
   

   zamiast open (OUT, ">:utf8"... można wpisać:

   use open ":encoding(utf8)";
   use open IN => ":encoding(utf8)", OUT => ":utf8";
   

   Wpisanie zaś:

   use utf8 ;
   

   wskazuje tylko tyle, że skrypt Perla jest kodowany w UTF-8.

Rysunek utworzony w OO Calc kopiuję do OO Draw następnie zapisuję jako PDF. Jest prawie dobrze -- prawie bo MediaBox, czyli najmniejszy prostokąt zawierający rysunek jest zły -- OO Draw zapisuje rysunek jak całą stronę. Są dwa rozwiązania:

1. Rysunek zapisany w OO Draw przyciąć używając do tego pdfcrop. Ten pdfcrop to skrypt w Perlu, dostępny w TeXlive i MikTeX.

2. Zamiast do OO Draw skopiować (poprzez kopiuj/wklej) do Inkscape. Teraz zaznaczyć obiekt (with the rubber band selector) i następnie kliknąć w Właściwości Dokumentu → Dopasuj do ramki zaznaczenia. Teraz export do PDF da w rezultacie rysunek z prawidłowo przyciętym MediaBoxem. Por. też tutaj.

Próbowałem kopiuj/wklej do Infranview ale wynikowy plik PDF jest złej jakości (fonty są zamieniane na bitmapy)... Być może można to dokonfigurować.

Niestety Mbank, który do niedawna uważałem za wzorowy przykład serwisu neutralnego technologicznie dołączył do grona lamerów. Mianowicie wydruk potwierdzenia operacji (w postaci pliku PDF) jest tworzony z wykorzystaniem fontów firmy Microsoft (Arial, Verdana, Tahoma). W rezultacie, przykładowo Acrobat tego nie wydrukuje, przynajmniej w systemie Linux. Jest pytanie po co do drukowania zwykłego potwierdzenia potrzebny jest MS Windows? Najwidoczniej jakiś odpowiedzialny ignorant z Mbanku na powyższe pytanie sobie nie odpowiedział... Albo inaczej: czy złożenie druczka za pomocą Times New Roman zamiast Tahomy i reszty cokolwiek by zmieniło?

Co więcej, mam podejrzenie graniczące z pewnością, że jakiś czas temu było inaczej, tj. dokumenty nie korzystały z fontów komercyjnych...

NB: evince drukuje dokument, podstawiając inny font (z błędnym kodowaniem)...

Opisany wcześniej skrypt uruchamiam ,,spod'' Emacsa działającego w trybie BibTeX. Konkretniej poniższa funkcja bibtex-adjust-pdf-filename pobiera wartości pól author, title, year oraz tp:keywords, a następnie przekazuje te wartości w postaci argumentów ww. skryptu uruchamianego jako polecenie systemowe. Mam nadzieję dzięki temu mieć większy porządek w przechowywanych dokumentach pobranych z różnych archiwów elektronicznych.

(defun bibtex-adjust-pdf-filename (file)
"Dla bieżącego rekordu bibtexa modyfikuje plik zawierający relewantny dokument PDF 
(dodaje co trzeba do słownika Info oraz modyfikuje nazwę). Oryginalna nazwa pliku
PDF jest podana z minibufora. Modyfikacja jest dokonywana przez zewnętrzny skrypt. 
Cała ta procedura jest po to żeby można łatwiej później odszukać plik na dysku...."
  (interactive "fNazwa pliku: ")
  (save-excursion
    (bibtex-beginning-of-entry)
    (let* ( (author (bibtex-text-in-field "author"))
	    (year (bibtex-text-in-field "year")) 
	    (keywords (bibtex-text-in-field "tp:keywords")) 
	    (title (bibtex-text-in-field "title")) 
	    (command (format "%s -rename -f \"%s\" -t \"%s\" -a \"%s\" -k \"%s\" -y \"%s\""
			  (executable-find "pdf_set_info.pl") ;; script name
			  (expand-file-name file) title author keywords year)) )
      (progn  (shell-command command)
	      (previous-line)
	      (beginning-of-line)
	      (insert (concat "%% patched with pdf_set_info.pl %%" ))))))

Przy okazji namiar na bloga anonimowego użytkownika Emacsa zawierającego parę ciekawych rzeczy.

PdfTk nie ma w zasobach fc8. W nowszych dystrybucjach też nie ma z uwagi na restrykcyjną licencję (znalazłem -- podobno działajacy -- rpm dla fc9 na stronie Gregory R. Kriehna, ale ja używam ciągle fc8). Nie idzie też tego skompilować: błąd zgłaszany przez gcj. Z opisu wynika, że sprawa jest trudna, bo pdftk jest źle zakodowany (I think all of us were amazed that it ever worked. That it did was by accident.:-)

Głupia sprawa... bo to przydatna aplikacja. Potrzebowałem akurat narzędzia do zmiany wpisów w słowniku Info plików PDF (pola Title, Author itp.). Znalazłem inne rozwiązanie wykorzystujące perlowy pakiet PDF::API2.

Najpierw instalacja (był dostępny w repozytoriach yuma):

yum install  yum install perl-PDF-API2

Skrypt jest banalny:

#!/usr/bin/perl
use PDF::API2;
use Getopt::Long;

my $USAGE = "*** pdf_set_info -t title -k keywords -a author -f file ***\n";

GetOptions( 't=s' => \$title, 'a=s' => \$author, 'k=s' => \$keywords,
 'f=s' => \$file, );

unless ($file) { print STDERR $USAGE; exit }

$pdf = PDF::API2->new;
$pdf = PDF::API2->open($file) || die "*** Problems opening $file ****";

%H = $pdf->info;
if ( $H{'Title'} ) { 
   print STDERR "**** Original title: $H{'Title'} ****\n";
   if ($title) { $title .= " ($H{'Title'})" ; }
 }

## Modyfikacja:
if ($title) { $H{'Title'} = $title }
if ($author)  { $H{'Author'} = $author }
if ($keywords)  { $H{'Keywords'} = $keywords }

unless ($title || $author || $keywords) { print STDERR $USAGE; exit }
%H = $pdf->info( %H );
$pdf->update;

Uruchomienie:

./pdf_set_info.pl -t tytuł -a autor -f słowa-kluczowe -f plik.pdf

Tytuł jest dodawany do tego co już jest w pliku PDF. Nie jest nadpisywany. Autor/Słowa kluczowe są nadpisywane. Uwaga: pakiet PDF::API2 nie jest mi bliżej znany, zatem trzeba uważać czy po zmianie Info plik PDF dalej da się oglądać.

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. ó). 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).

Fop w wersji 0.2* zniknął już dawno ze strony xmlgraphics.apache.org/fop/ co spowodowało m.in. że moja notka nt. polonizacji była nie tylko przestarzała ale także myląca. W szczególności fop 0.9* ma inną składnię pliku konfigurującego fonty, więc jeżeli ktoś próbował moich wskazówek, to mu raczej fop nie działał.

Uaktualniłem zatem notkę, poprawiłem ją także w paru miejscach bo była mętna a nawet błędna. Przetestowałem działanie z trzema zestawami fontów: MS Core Fonts, DejaVue. Całość jest tak sobie przydatna dla mnie -- fopa na co dzień nie używam, ale widzę z logów, że od czasu do czasu ktoś wpisuje do google fop+polskie+znaki no i ten dokument jest oglądany.

Dziś zostałem zapytany czy można dołączyć do dokumentu PDF font Times New Roman ze zbioru TrueType core fonts for the Web. Na zdrowy tzw. chłopski rozum, wydaje się, że tak ale z kolei w przypadku firmy MS może być różnie więc niekoniecznie może to być możliwe (zgodne z licencją).

Sprawdziłem licencję i można. Oczywiście jeżeli dokument zawiera podzbiór znaków (emedded subset) ale to akurat jest normalne/zwyczajowe ograniczenie. Na ten temat traktuje też [11] [8].

W uzupełnieniu informacji o manipulowaniu plikami PDF dziś wypróbowałem program pdftk do dzielenia plików PDF na strony. Działa. Jedyny kłopot był z instalacją. Z pomocą yuma się nie dało. Z pliku *.src.rpm ani kompilując ze źródeł też nie, bo za każdym razem był zgłaszany jakiś błąd. Znalazłem wreszcie działający pdftk-1.12-7.fc5.i386.rpm pod 'egzotycznym' adresem: linuxmirror.museum.state.il.us

Przy okazji zmieniłem swój skrypt do publikowania wpisów na tym blogu. Ułatwić sobie chciałem, żeby mi skróty rozwijał do pełnych adresów URL. Nie wchodząc w banalne szczegóły, problem pojawił się w miejscu, w którym apostrof i cudzysłów miały być częścią perlowego wyrażenia regularnego cytowanego w skrypcie basha. Jakoś tak:

perl -ne '..coś-tam...; s/blog:["'] ...itd... '

Po dłuższym kombinowaniu (głównie wokół dokumentów HERE) wreszcie wpadłem na oczywiste rozwiązanie:

perl -ne 'my $qchars = "\042\047"; ...coś-tam; s/blog:[$qchars] ...itd... '

Jak zamienić wiele plików w formacie MS Powerpoint na dokumenty PDF przy pomocy programu OpenOffice ale z poziomu wiersza poleceń opisał Bob DuCharme w tekście Moving to OpenOffice: Batch Converting Legacy Documents. W skrócie postępuje się następująco: w OO należy przejść do okna dialogowego Narzędzia->Makra->Zarządzaj Makrami. Następnie utworzyć moduł, np. MyConversion i wpisać do okienka następującą treść :

' BASIC, see: http://www.xml.com/pub/a/2006/01/11/from-microsoft-to-openoffice.html
' Based on code from http://www.oooforum.org/forum/viewtopic.phtml?t=3772
' Save document as an Acrobat PDF file.
Sub SaveAsPDF( cFile )
   cURL = ConvertToURL( cFile )
   ' Open the document. Just blindly assume that the document 
   ' is of a type that OOo will correctly recognize and open 
   ' without specifying an import filter.
   oDoc = StarDesktop.loadComponentFromURL( cURL, "_blank", 0, _
            Array(MakePropertyValue( "Hidden", True ),))

   cFile = Left( cFile, Len( cFile ) - 4 ) + ".pdf"
   cURL = ConvertToURL( cFile )
   
   ' Save the document using a filter.   
   oDoc.storeToURL( cURL, Array(_
            MakePropertyValue( "FilterName", "writer_pdf_Export" ),)
   
   oDoc.close( True )
End Sub

' Save document as a Microsoft Word file. 
Sub SaveAsDoc( cFile ) 
   ' mostly a copy of SaveAsPDF
   cURL = ConvertToURL( cFile )
   oDoc = StarDesktop.loadComponentFromURL( cURL, "_blank", 0, (_
            Array(MakePropertyValue( "Hidden", True ),))


   cFile = Left( cFile, Len( cFile ) - 4 ) + ".doc"
   cURL = ConvertToURL( cFile )
   
   oDoc.storeToURL( cURL, Array(_
            MakePropertyValue( "FilterName", "MS WinWord 6.0" ),)
   oDoc.close( True )

End Sub


' Save document as an OpenOffice 2 file. 
Sub SaveAsOOO( cFile ) 
   ' mostly a copy of SaveAsPDF. Save as an OpenOffice file. 
   cURL = ConvertToURL( cFile )
   oDoc = StarDesktop.loadComponentFromURL( cURL, "_blank", 0, _
            Array(MakePropertyValue( "Hidden", True ),))

   ' Set output file extension based on lower-case 
   ' version of input extension.
   Select Case LCase(Right(cFile,3))
     Case "ppt"         ' PowerPoint file.
       cFileExt = "odp"
     Case "doc"         ' Word file.
       cFileExt = "odt"
     Case "xls"         ' Excel file.
       cFileExt = "ods"
     Case Else
       cFileExt = "xxx"
    End Select
       
   cFile = Left( cFile, Len( cFile ) - 3 ) + cFileExt
   cURL = ConvertToURL( cFile )
   
   oDoc.storeAsURL( cURL, Array() )
   oDoc.close( True )

End Sub


Function MakePropertyValue( Optional cName As String, Optional uValue ) _
   As com.sun.star.beans.PropertyValue
   Dim oPropertyValue As New com.sun.star.beans.PropertyValue
   If Not IsMissing( cName ) Then
      oPropertyValue.Name = cName
   EndIf
   If Not IsMissing( uValue ) Then
      oPropertyValue.Value = uValue
   EndIf
   MakePropertyValue() = oPropertyValue
End Function

Uruchamia się to następująco (Linux):

ooffice -invisible "macro:///Standard.MyConversion.SaveAsPDF($PWD/plik.ppt)"

albo via prosty jednoargumentowy skrypt oo2pdf:

#!/bin/bash
# Konwersja do formatu PDF
echo "Konwertuję $1..."
ooffice -invisible "macro:///Standard.MyConversion.SaveAsPDF($PWD/$1)"

Koniecznie trzeba podać pełną ścieżkę do pliku (stąd zmienna PWD) bo inaczej zgłoszony zostanie błąd. W MS Windows też trzeba podać pełną nazwę, co nie do końca może być wygodne. Ale to już nie moje zmartwienie. Makra działają nie tylko dla plików .ppt, ale też .doc i .odt/odp.

Na ww. stronie jest też podana następująca zgrabna pętla zamieniająca wszystkie pliki (w tym przypadku .ppt) w katalogu bieżącym i jego podkatalogach:

for i in $(find ./ -name "*.ppt"); do oo2pdf $i ; done 

Być może to find ./ -name jest nawet przesadne i wystarczy zwykłe for i in *.ppt; do.

Jak połączyć wiele plików PDF w jeden? Okazuje się, że tego typu montaż jest możliwy przy wykorzystaniu program epdftex, który jest standardowym składnikiem każdej nowej dystrybucji TeXa i poniższego skryptu (autor P. Pianowski):

\nopagenumbers
\def\picdir {pic/}

\hoffset -1in \voffset -1in \topskip 0pt

\newdimen\HS \HS=210mm   \newdimen\VS \VS=297mm
\hsize\HS \vsize\VS

\pdfpagewidth=\HS \pdfpageheight=\VS

%\def\letter {letter} \def\aiv {a4}

\def\stronapdf #1#2#3#4{\pdfximage page #1 {\picdir #2}
  \vbox to\VS{\vskip #4 \hbox to\HS{\hskip #3%
  \pdfrefximage\pdflastximage \hss}\vss}
  }

\newcount\odstrony \newcount\dostrony
\newcount\nstr  \newcount\lstr

\def\strony#1#2#3#4#5{%
  \odstrony #1 \dostrony #2
  \def\przesunieciex {#3} \def\przesunieciey {#4}
  \lstr \numexpr \dostrony-\odstrony+1 \relax
  \nstr 1
  \loop
    \stronapdf \nstr{#5}\przesunieciex\przesunieciey
    \vfil\break
  \ifnum\nstr<\lstr \advance\nstr 1 \repeat
}

%% --- tu zmieniać: ---
\strony {01}{12}{5mm}{5mm}{plik_0.pdf}
\strony {13}{18}{5mm}{5mm}{plik_1.pdf}
 ... itd ...
\bye

Oczywiście koniec pliku należy zmodyfikować, wywołując polecenie \strony tyle razy ile trzeba. Powyższe wypróbowałem i działa doskonale. Trzeci i czwarty argument polecenia \strony określa przesunięcie i umożliwia dopasowanie marginesów na stronie (dla każdego pliku oddzielnie).

Inne proponowane do tego celu rozwiązania to: latex plus pakiet pdfpages, pdftk (ORA wydało nawet książkę PDF Hacks--nie wiedziałem) albo ghostscript uruchomiony w następujący sposób:

gs -q -sPAPERSIZE=A4 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite \
   -sOutputFile=out.pdf in1.pdf in2.pdf...

Więcej informacji na temat łączenia plików PDF można znaleźć w tekście: How to concatenate PDFs without pain.