Książki żywot ciąg dalszy

Załóżmy, że wydawnictwo przesyła tradycyjny, nieostylowany plik wordowski z kompletem materiałów i wymogiem, by publikacja została przygotowana w InDesign. Co najpierw dzieje się z plikiem?

E: Najpierw otwieram plik i sprawdzam zawartość. Inaczej pracuje się nad książką bardziej złożoną np. z przypisami czy ilustracjami. Sprawdzam czy materiał ilustracyjny jest kompletny i czy załączone pliki są zapisane w wysokiej rozdzielczości. Jeśli czegoś brakuje, to dopytuję wydawnictwo, czy poprawne materiały są w ogóle dostępne. Z reguły w najgorszym stanie są wykresy i rysunki techniczne. Autorzy często przesyłają wydawnictwu materiały graficzne w opłakanym formacie, a nierzadko przechowują u siebie wersje wysokiej jakości.

A: Nie pracuję w badziewiu[śmiech]. Nie, tak poważnie. Lecę przez plik kilkoma makrami – wywalam mistrzów spacji, taguję standardowe wyróżnienia, oznaczam przypisy. Potem lecę przez tekst i taguję na szybko najważniejsze linie – tytuły itp., szukam wszystkiego, co nie jest zwykłym tekstem. Mam własny system, którym określam na początku akapitu jego znaczenie. Przeciętną książkę da się zamknąć w sześciu – ośmiu stylach. Gdy mam oznaczony każdy akapit i wyróżnienia, wyrzucam tekst z Worda do zwykłego edytora np. notepad++ i RegExem (wyrażeniami regularnymi) taguję go w całości automatycznie w standardowym zestawie xHTML. Taki plik zapisuję i wczytuję z powrotem do Worda, dzięki temu otrzymuję ostylowany dokument.

Tak przygotowany plik można już wczytać do InDesign?

E: Tak. W sumie przerabianie go w Wordzie nie ma sensu. Lepiej jest ostylować go dopiero na etapie łamania w InDesign, ponieważ ma lepsze narzędzia i jest bardziej czytelny. Większość elementów przechodzi automatycznie, a jeśli coś trzeba zamienić w całym dokumencie, to zdecydowanie lepiej jest to zrobić już w InDesign, już choćby dlatego, że obsługuje wyrażenia regularne. Wczytany plik przystosowuję do makiety – ustalonej z góry, jeśli jest to seria, albo przygotowanej na potrzeby danej publikacji. W efekcie powstaje plik w całości oparty o style.

A: Jak najbardziej. Jeśli docx ma style, to importują się razem z plikiem do InDesign. Jeśli style mają takie same powtarzalne nazwy, to po wczytaniu jest voilà – cały dokument jest ostylowany. Potem kilka zamian wbudowanych RegExem w InDesign oraz jedno czy dwa sprytne makra i większość dokumentu jest wstępnie obrobiona. Podczas samego łamania można wyłapać ewentualne niedociągnięcia, źle ostylowane fragmenty itp.

Czyli jest to w sumie praca ręczna?

E: Jak najbardziej. Ręczna, precyzyjna i wymagająca dużej uwagi. W założeniu są dwie korekty, tekst do pierwszej powinien być tylko wstępnie obrobiony, ale praktyka jest taka, że od razu do pierwszej korekty oddaje się plik praktycznie przygotowany do druku.

A: Tak, ale to jest nie do uniknięcia. Jakkolwiek by wyglądał plik na wejściu, to na wyjściu musi być dziełem. Dzieła nie generuje się automatycznie, trzeba nad nim posiedzieć i oszlifować. Oczywiście są narzędzia, które pozwalają wygenerować automatycznie plik do druku, ale większość wydawców wyskakuje przez okno na widok takiego łamania.

A po przetworzeniu i przygotowaniu ostatecznego pliku?

E: Na wyjściu powstaje PDF, ewentualnie EPUB, jeśli wydawca sobie tego życzy. Mamy też pliki InDesign, które z reguły przekazujemy do archiwizacji, zgodnie z wersją, w której zostały przygotowane. Pliki wejściowe raczej do niczego się już nie nadają, bo nie zawierają żadnych korekt. Ewentualnie eksportujemy z InDesign także pliki wordowskie.

A: Zabawne jest, jaką magię potrafią ukryć w środku pliki PDF. Na górze jest elegancka, gotowa do druku książka, a w środku może być w sumie cokolwiek. Byle podmalowane wizualnie. W każdym razie wychodzi oczywiście elegancki PDF, znacznie mniej elegancki EPUB (jeśli jest eksportowany z InDesign), docx, który jak się nie nadawał do niczego, tak się nie nadaje i plik InDesign, z którym powodzenia życzę.

Jaka jest wartość takich materiałów przy kolejnym wydaniu?

E: Zawsze można skorzystać przynajmniej z części materiałów. Jeśli między pierwotnym a nowym wydaniem minęło trochę czasu, to może być problem, na przykład z wersją InDesign. Jeśli książka ma prostą strukturę i nie trzeba było zbyt mocno kombinować, żeby uzyskać efekt końcowy, to z reguły przynajmniej większość wczytuje się poprawnie.

A: Taka sama jak pierwotnego wydania, czyli niewielka [śmiech]. Nie no, poważnie zgadzam się. Wszystko zależy od książki i czasu. Woda płynie przez strony i kolejne wersje, ale robiłem kiedyś dla pewnego wydawcy podręcznik do języka niemieckiego i wszystkie elementy graficzne takie, jak ikony były dopasowywane z dokładnością co do milimetra i zawieszone na kotwicach (anchorach). Nie pamiętam, czy to było za czasów CS3 czy CS4, ale dzisiaj te anchory muszą wyglądać zabawnie. Wolałbym skoczyć do pustego basenu na główkę, niż przygotować dzisiaj kolejne wydanie tej książki [śmiech].

Wspominaliście kwestię EPUBów. Dzisiejszy rynek wymaga tej wersji praktycznie dla każdej publikacji. Czy tutaj kwestia plików wejściowych coś zmienia?

E: Nie. Efektem pracy nad PDF jest i tak ostylowany plik. Style można już raczej bezboleśnie przekładać między formatami, a EPUB to nic innego jak ostylowany dokument z dołączonym arkuszem stylów. Staramy się nie korzystać z eksportera InDesign, bo generuje bardzo duże objętościowo pliki, z którymi niektóre czytniki mają trochę problemów.

A: Tak, jak na widok automatycznie przełamanych plików PDF przez okno wyskakują wydawcy, tak na widok takiego automatycznego EPUBa przez okno wyskakują czytniki. Objętość kodu w wygenerowanych automatycznie EPUBach jest zawyżona jakieś sześć razy przez masę niepotrzebnych informacji, które program do nich dokłada. Żeby uzyskać poprawny plik można albo ten wyeksportowany od gruntu przerobić, albo zrobić go samemu od początku. Co nie zmienia faktu, że plik wejściowy ma znikome znaczenie. Oczywiście przy założeniu, że dalej rozmawiamy o docx albo pokrewnym formacie.

A co, jeśli wejściowym plikiem jest XML?

E: I dalej mówimy o pracy w InDesign?

Nie, możemy pracować, w czym nam się podoba.

E: No to praca przebiega zupełnie inaczej. Otrzymany plik wczytujemy bezpośrednio do Arbortexta. Listę niezbędnych stylów, czyli tagów, dostajemy automatycznie. Definiujemy w stylach wszystkie elementy, zadajemy ogólne warunki w makiecie, przypisy wczytujemy automatycznie i tak przygotowany plik zaczynamy łamać.

A: InDesign i XML nie za bardzo się lubią. Znaczy, żeby nie było nieporozumień, wsparcie oczywiście jest, ale moim zdaniem homeopatyczne. Dlatego jeśli XML, to tylko Arbortext. Wiesz, że mogę zawiesić na czymś, na przykład na tytule, warunek, że w PDF będzie kolorował się na czerwono, jeśli licząc od końca dokumentu zsumowana liczba akapitów podzielona przez trzy zostawi nieparzystą resztę? Albo jeśli jest wtorek?

Z takim dokumentem możemy praktycznie zrobić wszystko w ogóle go nie dotykając. Jeśli na przykład wydawca zażyczy sobie, żeby przed nazwą rozdziału był jego numer, a w oryginalnym pliku go nie było, to nie musimy go dopisywać. Możemy go dogenerować dynamicznie do PDFa w ogóle nie ruszając źródła. Dlatego wyeksportowany potem plik będzie spełniać wszystkie założenia pliku wejściowego.

E: To, co można zrobić z XML w procesie przygotowania PDF zależy w głównej mierze od tego, jakim oprogramowaniem dysponuje studio. Arbortext jest naszym zdaniem najlepszym programem do łamania XML na świecie, ale nie jedynym.

A: Wszyscy wprowadzają XML na swój sposób. Na razie nikt nie dogonił tego, co potrafi Arbortext, ale na przykład najnowsza wersja Quarka ma już bardzo ciekawe rozwiązania.

Na czym polega największa różnica w pracy z nieostylowanym dokumentem i XML?

E: Na powtarzalności. Ponieważ standard XML pozostaje niezmienny niezależnie od treści, którą wypełniona jest struktura i kolejnych wersji różnych programów, praca nad dokumentem o tej samej strukturze zawsze przebiega jednakowo. W trakcie pracy nad encyklopedią trzydziestotomową nie miało żadnego znaczenia, nad którym tomem pracujemy. Jedna szczegółowo zdefiniowana makieta pozwalała zautomatyzować większość prac pomimo tego, że treść była zupełnie inna.

A: Na możliwościach i eksporcie. Po pierwsze, XML jest z założenia eksportem z jakiejś bazy danych, więc można bezpiecznie założyć, że na wejściu leży tak daleko od książki, jak to tylko możliwe. Dlatego programy takie jak InDesign nie mają szans w starciu ze skomplikowanym XMLem. Jeden ze słowników, który przygotowywaliśmy, składał się w 99.8% z oznakowania (same tagi!). Przygotowany do druku miał sześćset stron, a wydrukowany razem z otagowaniem prawie trzydzieści tysięcy. Dzięki temu producent treści nie musi się ograniczać po swojej stronie z eksportem i przygotować specjalne systemy, żeby z bazy danych, która ma wiele różnych zastosowań, przygotować akurat plik do pracy nad formatem PDF. A my ze swojej strony możemy taki plik obsłużyć nie tylko ograniczając wyświetlanie w pliku PDF do sprecyzowanych elementów, ale jeszcze oddać taki sam plik po korektach na wyjściu do wczytania do bazy danych. I jeśli będzie to słownik, to może od razu posłużyć za wkład do dowolnych innych projektów – słowników internetowych, aplikacji mobilnych czy czegokolwiek, co tam sobie właściciel wymarzy.

Czy obsługa XML jest ograniczona do jakichś konkretnych programów?

E: Tak, program do składu musi mieć obsługę XML, żeby pracować w nim natywnie. Można go jednak trochę oszukać, jeśli nie ma konieczności eksportowania treści po zakończeniu prac.

A: Kwestią jest bardziej to, jak dobrze dany program obsługuje XML. Jest to język na tyle spopularyzowany, że większość nowych programów ma jakąś formę jego obsługi – InDesign czy Quark również. Jeśli jednak pojawi się problem w danym programie, to w miarę bezboleśnie można przekonwertować XML na coś strawniejszego.

E: Na przykład xHTML.

Jaki jest sens pracy w XML po stronie wydawcy?

E: Z naszego punktu widzenia XML jest bardziej skomplikowaną formą pracy ze względu na to, że znaczenie ma nie tylko wyjściowy PDF. W toku prac opiekujemy się materiałem wydawcy i po ich zakończeniu musimy zwrócić plik w idealnym formacie. XML nie toleruje żadnych błędów czy odstępstw od reguł, musi zostać oddany tak samo jak przyszedł. Dla wydawcy oznacza to pewność, że po wszystkich pracach redakcyjnych, dostanie materiał w idealnej postaci niezależnie od studia. W przypadku projektów przygotowanych w innych standardach wszystko jest w rękach studia, przez co czasami materiały pośrednie są w koszmarnej jakości. Widzieliśmy na przykład publikacje w InDesign przełamane ręcznie, bez użycia stylów. Wprowadzanie jakichkolwiek poprawek czy robienie nowych wersji na ich podstawie jest w sumie pracą od początku, poprzednie materiały mają zerową przydatność. Powiem więcej, lepiej zrobić wszystko od nowa niż rzeźbić.

A: Ujemną, nie zerową, bo jeszcze utrudniają pracę. Robiliśmy kiedyś encyklopedię tematyczną, w której w oryginalnej wersji każda rozkładówka była osobnym plikiem. To był dopiero projekt z piekła rodem. Jeśli chodzi o zastosowanie XML, to bezpieczeństwo to jeden aspekt, ale drugim jest jednak uniwersalność języka. Wszystko dzisiaj komunikuje się w jakiejś formie w standardzie XML, od systemów API wszelkiego rodzaju po systemy bankowe. Standard pozostaje niezmienny, bo nie ma po co w nim czegokolwiek ruszać. Raz zbudowana baza danych będzie kompatybilna ze wszystkimi nowymi formatami, które rynek raczy sobie wymyślić i daje otwarte pole do popisu wszelkim pomysłom wydawcy. Od książek generowanych na życzenie, przez aplikacje mobilne, aż po strony internetowe. W tradycyjnym modelu nie ma możliwości przełożenia materiałów na cokolwiek innego niż proste projekty dostępne dzisiaj. Każdy nowy format będzie zaskoczeniem i będzie wymagać zasadniczych zmian w procesie produkcji, żeby mu sprostać. XML to przede wszystkim bezpieczeństwo – nie tylko w zakresie pracy studia, ale przede wszystkim na przyszłość.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *