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:
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.
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
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ę...
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:
Rysunek zapisany w OO Draw przyciąć używając do tego pdfcrop
.
Ten pdfcrop
to skrypt w Perlu, dostępny w TeXlive i MikTeX.
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.