Kluczowe założenia
W dzisiejszym artykule poruszymy skomplikowany problem importowania do bazy danych treści już przetworzonych na etapie DTP. Unikalne wymagania każdego formatu wymagają czasem daleko idącej ingerencji w treść, co nie jest tajemnicą dla nikogo, kto kiedykolwiek składał cokolwiek bardziej skomplikowanego od wizytówki. Niestety, jak przy większości konwersji, bardzo ważne jest, by nie traktować treści łomem w postaci stratnych, nieodwracalnych konwersji. Przywrócenie jej do postaci akceptowalnej przez jakąkolwiek bazę danych może być wtedy bardzo trudne, albo wręcz niemożliwe.
Kluczowym założeniem jest to, że po szczęśliwym zakończeniu wszystkich prac nad publikacją, każdy format musi mieć taką samą, identyczną wersję. Po pierwsze warto się zastanowić, dlaczego zwrotna konwersja miałaby być potrzebna. Może być na przykład tak, że publikacja jest na tyle skomplikowana, że prace redaktorskie nie mogą zostać przeprowadzone na etapie bazy danych. Innym przypadkiem mogą być publikacje o założonej z góry objętości – określenie długości treści ma wtedy kluczowe znaczenie, a nie da się jej dokładnie oszacować przed wlaniem jej w makietę.
W założeniu w procesie produkcji opartym o XML wszystkie korekty powinny być wprowadzane na poziomie edytora i bazy danych, czyli do produkcji powinny trafiać pliki po korektach językowych i merytorycznych. Niestety nie zawsze jest to możliwe i wtedy pojawia się Problem Importu.
Problem Importu
Powrót z programu DTP do bazy danych może rodzić szereg problemów. O ile większość takich programów posiada wbudowane parsery, które zapewniają spójność kodu XML, o tyle baza danych wymaga z reguły nieco więcej niż tylko „poprawnego kodu”. Na przykład zdecydowana większość baz danych układa treści według unikatowego klucza, z reguły licznika. Prosta z punktu widzenia użytkownika czynność wstawienia jakiegoś elementu między dwa inne już istniejące, jest z punktu widzenia bazy danych procesem dość skomplikowanym. W pierwszej kolejności nowy element otrzymuje swój licznik, a następnie wszystkie elementy po nim następujące są przenumerowywane o jeden. I tutaj pojawia się jeden z zasadniczych problemów edycji tekstu na etapie składu i łamania.
Wstawienie nowego akapitu czy wydzielenie jakiejś części do nowego elementu rodzi szereg problemów po stronie bazy danych, która ma tę znowelizowaną treść wczytać. Sytuacja komplikuje się jeszcze bardziej, jeśli na etapie składu i łamania poszczególne elementy zostaną poprawione, usunięte, wstawione lub zamienione miejscami. W efekcie baza danych nie ma pojęcia, jak się ma odnieść do zaimportowanych materiałów, jaka jest poprawna kolejność w stosunku do wersji, która została wyeksportowana.
W efekcie zmian, korekt, poprawek i redakcji wprowadzanych na etapie DTP treść zostaje czasem poddana bardzo daleko idącym przeróbkom. Każda z nich jest kolejnym wyzwaniem stojącym przed bazą danych na etapie importu. Aby ułatwić jej zadanie i generalnie uprzyjemnić sobie dzień (lub w przypadku niektórych szczególnie brutalnie potraktowanych projektów cały kwartał), warto mieć w pamięci Problem Importu od początku prac nad projektem. Można sobie z nim poradzić na kilka sposobów, z których absolutnie żaden nie zadziała, jeśli pytanie o import pojawi się w momencie otrzymania pliku XML ze studia DTP.
Praca równoległa
Najprostszym, a jednocześnie najbardziej czasochłonnym i podatnym na błędy, rozwiązaniem jest równoległa praca w programie DTP i bazie danych. Wszystkie korekty przekazywane do studia DTP, są jednocześnie wprowadzane bezpośrednio w bazie danych. Takie rozwiązanie ma swoje zalety:
- Treść może zostać wyeksportowana w wygodnym formacie, bo nigdy nie musi wrócić do bazy danych. Można zatem pracować na dowolnym z obsługiwanych formatów programów do składu i łamania bez konieczności ingerowania w kod XML.
- Treść w ogóle nie wraca do bazy danych, więc problem sprawdzania, poprawiania ewentualnych błędów, wczytywania i sprawdzania efektów importu przestaje istnieć.
Wszystkie korekty nanoszone przez redakcję są w takim modelu wysyłane do DTP i jednocześnie wprowadzane w bazie danych. Niestety, ze względu na rozdzielność procesów, konieczne jest sprawdzenie obu wprowadzonych korekt – błędy mogą się pojawić zarówno po stronie składu jak i redakcji.
Jest to najbardziej „ręczne” obejście Problemu Importu. Nie warto go jednak tylko z tego powodu od razu odrzucać, bo ma swoje mocne strony i w przypadku niektórych projektów jest bezsprzecznie najlepsze. W sytuacji, kiedy do poprawki jest tylko kilka większych elementów, a korekty nie sięgają w serce treści zbyt głęboko, zaprzęganie któregoś z bardziej skomplikowanych rozwiązań jest typowym przerostem formy nad treścią.
Wysyłanie „po kawałku”
Aby uniknąć czasochłonnego sprawdzania wprowadzanych korekt można je nanosić bezpośrednio w bazie danych i wysyłać do składu we fragmentach. Ogromną pomocą w takim trybie pracy jest odpowiednio zaprojektowany system eksportów z bazy danych, który umożliwia np. wypuszczanie materiałów według czasu edycji lub po prostu wybieranych przez redaktora. Dzięki temu treść w bazie danych jest poprawna od samego początku, w związku z czym nie trzeba jej sprawdzać. Do składu trafiają całe wymienione fragmenty, a jedynym zadaniem operatora jest wstawienie części w odpowiednie miejsca.
Taką techniką tworzyliśmy wspólnie z Wydawnictwem PWN 30-tomową encyklopedię PWN. Ogromna baza haseł encyklopedycznych została stworzona w standardzie XML. Korekty, wprowadzane na etapie łamania, redaktor nanosił w bazie, a następnie eksportował poprawione hasło i przekazywał je w całości. Dzięki temu struktura bazy nie była w żaden sposób naruszana i import tekstu do bazy nie był zaburzony żadnymi błędami. Zastosowany do łamania w naszym studiu program PTC Arbortext Editor umożliwiał wprowadzanie korekt do treści w XML również na etapie pracy w studiu DTP bez niszczenia struktury dokumentu.
Bardzo ważne jest, by przesyłane fragmenty były możliwie jak najmniejsze. W procesie składu i łamania pojawia się cała masa dodatkowych znaczników i drobnych poprawek, które umożliwiają odpowiednie ułożenie tekstu. Te dodatki są usuwane przy eksporcie, ale konieczność dodawania ich za każdym razem, kiedy redaktor dostawia przecinek właściwie przekreśla możliwość pracy z XML, przynajmniej z punktu widzenia biednego operatora DTP, któremu nie pozostaje nic ponad załamanie rąk i wykonanie tej samej (obiektywnie najnudniejszej) części pracy ponownie.
Praca z programem obsługującym XML
Istnieją na rynku profesjonalne programy do pracy z językami znakowanymi jak XML. Przykładem takiego programu może być PTC Arbortext Editor. Program ten umożliwia budowanie skomplikowanych struktur skryptów wokół dokumentu, zaimportowanie DTD lub Schemy bezpośrednio wraz z dokumentem i jednoczesną pracę na gotowym tekście i kodzie źródłowym dokumentu. Dzięki temu można nanosić poprawki na etapie DTP aż do zakończenia pracy nad wersją PDF, bez martwienia się o poprawność bazy danych. Dopiero po stworzeniu ostatecznej wersji dokumentu, kod XML można wyeksportować z zastosowaniem odpowiednich skryptów, które np. wyczyszczą dokument, poprawią kolejność kluczy bazy danych i przygotują go według założonego schematu do importu.
Zaletą takich rozwiązań są niemal nieograniczone możliwości edycji tekstu bez ingerowania w kod źródłowy (np. przestawianie akapitów miejscami bez zmieniania kolejności w bazie danych, ukrywanie, powielanie elementów itp.), stały dostęp do kodu źródłowego i zaawansowane języki skryptów.
Oczywistą wadą jest cena takich rozwiązań i poziom komplikacji. Cena jednej kopii Editora to suma, która umożliwia wyposażenie kilku studiów graficznych w InDesign. Z drugiej strony, jedno takie stanowisko w efektywności i poprawności pracy zastąpi kilka stanowisk wyposażonych w jakikolwiek inny program „przystosowany” do pracy z XML. Arbortext Editor, z którego kolejnych wersji korzystamy od blisko 20 lat, ma wbudowaną obsługę własnego języka programowania (showstrings), RegExp, xPatha i Perla. Efektywne i bezpieczne dla publikacji wykorzystanie tego typu programów wymaga specjalistycznej wiedzy, a to pociąga za sobą koszty, ale przekłada się na długotrwałe korzyści.
Co musi umieć baza danych?
W każdym z powyższych procesów, z wyjątkiem pracy równoległej, kluczową rolę pełni baza danych i jej możliwości w zakresie importu. W celu zachowania systemów kontroli wersji (a przypominam, że backupów można mieć tylko o jeden za mało) baza danych musi wiedzieć o wczytywanym tekście wszystko – skąd się wziął, gdzie było jego oryginalne miejsce w dokumencie, jakie jest jego nowe miejsce i jakiego rodzaju korekty zostały wprowadzone.
W zależności od tego, czy tekst będzie przesyłany we fragmentach, czy przygotowywany w profesjonalnym programie do obsługi treści w XML i wczytywany do bazy danych, proces importu może być odpowiednio bardziej lub mniej czasochłonny. Na pewno nie będzie to jednak polegać na kliknięciu przycisku z napisem IMPORT, wybrania pliku i kliknięciu OK. Baza danych może wykonać wiele, albo nawet wszystkie, czynności automatycznie, ale i tak konieczne będzie co najmniej sprawdzenie importu publikacji pod kątem kompletności materiałów i spójności z zamierzoną wersją.
Projektując procesy obsługiwane przez bazę danych warto w Wielkiej Liście Wyjątków uwzględnić sytuację, w której kod XML będzie musiał w jakiejś postaci wrócić do bazy danych po składzie. Odpowiednie zaprojektowanie możliwości bazy i systemu eksportu/importu pozwoli znacznie zmniejszyć bolesność tego procesu. Zastosowanie na przykład dwóch zestawów kluczy sortujących i skryptów numerujących rekordy przed importem pozwoli bazie zorientować się, co powinno trafić w które miejsce, które elementy zostały dodane, które usunięte, a które przeniesione w nowe miejsce.
Niezależnie od możliwości bazy danych, programów DTP i poziomu wiedzy po stronie wszystkich zaangażowanych stron warto pamiętać, że znacznie lepiej jest unikać problemów niż sobie potem z nimi próbować radzić. Dlatego przy każdej publikacji celem powinno być zamknięcie wszystkich poważnych prac redakcyjnych przed wyeksportowaniem treści z bazy danych tak, by nie było konieczności importowania jej z powrotem. W idealnym świecie klucz perfekcyjnie pasuje do zamka, każda publikacja trafia do składu w idealnym stanie, a jedyne poprawki dotyczą ułożenia tekstu i ewentualnie kilku przecinków. Niestety nie żyjemy w idealnym świecie, więc czasem zamek, zamiast kluczem, trzeba otworzyć jednym z powyższych wytrychów.