Materiał ilustracyjny – przetwarzanie XML

Co dalej z XML?

W poprzednim artykule zajmowaliśmy się procesem przetwarzania treści z postaci niestrukturyzowanej do czystego kodu XML. Jest to jednak jedynie pierwszy element układanki, bo publikacja to nie tylko treść. Do nowoczesnych publikacji załącza się bogaty materiał ilustracyjny, dodatkowe materiały w formie elektronicznej czy dostępy do materiałów internetowych. W związku z tym bardzo ważnym elementem procesu powstawania publikacji jest wydajne połączenie wszystkich wymienionych elementów w jedną, kompatybilną całość. W tym artykule skupimy się na materiale ilustracyjnym i wymogach, które powinno spełniać oprogramowanie do jego obsługi.

Materiał ilustracyjny

W skład materiału ilustracyjnego mogą wchodzić, w zależności od profilu wydawnictwa, różne elementy. Najbardziej popularnym są zdjęcia, ale mogą to być także tabele, gdy są na tyle pokaźnych rozmiarów, że jedynym sensownym rozwiązaniem jest obrócenie ich, wykresy czy wzory matematyczne. Te ostatnie są na tyle skomplikowanym zagadnieniem, że zasługują na własny artykuł. W ostatecznym podsumowaniu trzeba stwierdzić, że konieczne jest dysponowanie różnymi formatami każdego elementu ilustracyjnego, aby móc je odpowiednio podłączać do publikacji udostępnianych w różnych standardach. Przykładowo:

• Zdjęcia (rastry) – wysoka jakość, 300 dpi, CMYK do publikacji drukowanych (np. EPS czy TIFF), wysoka jakość, 96 dpi, RGB (do zdjęć wysokiej jakości na stronach internetowych), średnia jakość, 96 dpi, RGB (do zdjęć normalnej jakości na stronach internetowych oraz publikacji elektronicznych EPUB czy MOBI).
• Tabele – kod XML do publikacji drukowanych (eksportowany w postaci np. xHTML do InDesign), stron internetowych (eksportowany bezpośrednio), wysoka jakość, 300 dpi, RGB do publikacji elektronicznych.
• Wzory matematyczne – kod MathML i TEX do publikacji na stronach internetowych czy drukowanych przy wykorzystaniu bardziej zaawansowanych systemów DTP, grafiki wektorowe do publikacji papierowych (np. EPS czy AI), rastry wysokiej jakości do publikacji elektronicznych.

W teorii można zaprojektować system tak, by centralna baza danych przechowywała zarówno tekst jak i ilustracje, ale w praktyce to rozwiązanie rzadko jest opłacalne i wydajne. Wielu użytkowników systemu nie ma styczności z materiałem ilustracyjnym w procesie produkcji. W praktyce nie ma zatem potrzeby trzymać ilustracji i tekstów w jednej bazie. Z reguły efektywnym i skutecznym rozwiązaniem jest zaprojektowanie komunikacji między edytorem a bazą ilustracji w taki sposób, by autorzy i redaktorzy w trakcie pracy z tekstem mogli wykorzystywać prefki (zdjęcia w niskiej rozdzielczości do podglądu), a dopiero na etapie eksportu podłączane są ilustracje we właściwej rozdzielczości. Natomiast w sytuacji, gdy każda publikacja ma bardzo bogaty i mocno powiązany z tekstem materiał ilustracyjny wdrażanie dwóch osobnych rozwiązań do obsługi tekstu i ilustracji może nie mieć sensu. Wtedy wydajniejsze staje się rozwiązanie łączące obie bazy. System pracy z ilustracjami w dużym stopniu zależy od rodzaju publikacji, w wydawaniu których specjalizuje się wydawnictwo.

W przypadku programów do obsługi ilustracji istnieje podobne ryzyko, jak w przypadku programów do DTP – stosunkowo łatwo można przesadzić z funkcjonalnościami. Analizując to, co takie oprogramowanie powinno robić, należy pamiętać, że istnieją bardzo dobre programy „z pudełka” do retuszu i obróbki ilustracji i z reguły nie ma sensu powielać funkcji do obsługi bazy ilustracji w tworzonym oprogramowaniu. Szczególnie, że znacząco wpłynie to na kosztorys planowanego przedsięwzięcia.

Tabele

Ze względu na ograniczenia systemowe, tabele mogą stać się niemałym wyzwaniem dla korzystania z bazy danych wydawnictwa. Po pierwsze, w zależności od ich rozmiaru, lepszym rozwiązaniem może być podłączenie rastra niż tekstu. W formatach EPUB czy MOBI, które nie obsługują leżących tabel, umieszczenie w wersji tekstowej wielorzędowej tabeli z długim tekstem w komórkach przekreśla jej czytelność dla użytkownika na jakimkolwiek czytniku. Niektóre programy DTP mają problem z wczytaniem tabel ustrukturyzowanych, np.  InDesign nie potrafi właściwie zaimportować tabeli zapisanej w kodzie xHTML, nawet jeśli ten kod został wygenerowany w InDesign. O takich ograniczeniach należy pamiętać i rozwiązywać je w trakcie projektowania procesów i procedur. Problem z formatowaniem tabel w InDesign można rozwiązać wczytując dokumenty xHTML najpierw do Microsoft Office.

Wzory matematyczne

Wzory matematyczne, w szczególności wielopiętrowce, w których cyfry stanowią wyjątki od reguły, spędzają sen z powiek wielu wydawcom od zawsze. Istnieje szereg formatów, w których można zapisywać wzory – od najbardziej prymitywnych polegających na manualnym ustawianiu elementów, a następnie eksporcie do rastra lub wektorów, przez oferujące nieco więcej możliwości MS Word, aż po profesjonalne takie, jak MathML czy TEX. Wszystkie te formaty zapisu mają swoje zalety i ograniczenia:

• Rastry – Należy traktować je tak, jak każdą ilustrację, czyli można wczytać je do wszystkich programów DTP, publikacji elektronicznych i wyświetlać na stronie internetowej. Jakość zależy od materiału wejściowego, ale nigdy nie będzie porównywalna z renderowanym tekstem czy zapisem wektorowym. Dostosowanie wielkości fontu do pozostałych elementów publikacji jest skomplikowane. W każdym formacie publikacji, niezależnie od wybranych fontów, wzory będą identycznych rozmiarów i z reguły nie będą pasować do pozostałych elementów publikacji.
• MathML – Format XML przeznaczony wyłącznie do tworzenia wzorów matematycznych. Kompatybilny natywnie ze stronami internetowymi, nieobsługiwany przez większość programów DTP czy formaty EPUB i MOBI. Prosty w edycji (przy wykorzystaniu odpowiedniego oprogramowania nawet banalnie prosty), umożliwia korekty. Jakość w formatach końcowych zależy od metody konwersji i wybranego formatu wyjściowego (z reguły grafiki wektorowej).
• TEX – Stosunkowo podobny do MathML. Przy zastosowaniu odpowiednich bibliotek JS, np. MathJax jest kompatybilny ze stronami internetowymi.

Z punktu widzenia wydawcy kluczowe jest to, aby wzory matematyczne były przechowywane w standardzie TEX lub MathML, by można było nanosić korekty. System ich przechowania musi także umożliwiać eksport do wymaganych formatów, szczególnie graficznych (zarówno rastrów jak i wektorów). Bardzo przydatną funkcją jest możliwość budowania wzorów z funkcją OCR w czasie rzeczywistym. Istnieje co najmniej kilka programów, które umożliwiają tworzenie wzorów w ten sposób i obsługują większość, jeśli nie wszystkie, formaty opisane powyżej.

Oprogramowanie

Z uwagi na powyższe ograniczenia, wymogi oraz charakterystykę różnych kanałów dystrybucji, a także optymalizację oprogramowania zarządzającego bazą ilustracji, musi być możliwość przechowania ich w dwóch formatach:

• Źródłowe – jako materiał źródłowy rozumiemy format o najwyższej rozdzielczości, wartości edycyjnej oraz możliwości konwersji do wszystkich niezbędnych formatów.
• Potrzebne w czasie rzeczywistym – niektóre kanały dystrybucji, w szczególności oparte o strony internetowe (np. dodatkowe materiały, publikacje lub materiały dostępne przez stronę internetową), wymagają stałego dostępu do bazy ilustracji zapisanych w wymaganych formatach. Trudno wyobrazić sobie sytuację, w której oprogramowanie do obsługi ilustracji będzie musiało konwertować ilustracje do odpowiedniego formatu za każdym razem, kiedy strona internetowa zgłosi takie zapotrzebowanie.

Pozostałe formaty, na przykład do publikacji drukowanych czy elektronicznych jak MOBI czy EPUB, nie wymagają przechowania materiałów w wyjściowym formacie. Można je konwertować i eksportować za każdym razem, kiedy będzie taka potrzeba.

Podsumowanie

Kluczowym aspektami oprogramowania do obsługi bazy ilustracyjnej są jego możliowści w zakresie:

• Eksportu do wszystkich niezbędnych formatów bez konieczności zaprzęgania do niego innego, zewnętrznego oprogramowania
• Komunikacji z pozostałymi elementami procesu, w szczególności edytorem w zakresie np. przekazywania prefek, grupowania materiału według publikacji
• Możliwości bezpośredniego podpięcia do strony internetowej tak, by mogła w czasie rzeczywistym pobierać i wyświetlać potrzebny materiał ilustracyjny
• Ergonomii w zakresie zarządania bazą i eksportu, na przykład funkcji łączenia ilustracji z publikacjami tak, aby umożliwić kompleksowy eksport materiału do produkcji lub archiwizacji bez konieczności wybierania powiązanego materiału ilustracyjnego z tekstem za każdym razem, kiedy występuje potrzeba jego eksportu.

Podczas projektowania nowego lub analizy istniejącego oprogramowania należy zwrócić uwagę na to, żeby funkcje nie były dublowane przez inne wdrożone lub planowane rozwiązania. Sytuacja, w której kilka różnych zaimplementowanych programów oferuje te same funkcjonalności kończy się tym, że każdy użytkownik wybiera sobie sam drogi dojścia do planowanego efektu. Brak spójności procedur i jednorodności narzędzi może doprowadzić do pojawienia się szeregu problemów i chaosu. Należy zawsze pamiętać o tym, że oprogramowanie będzie rozwijane, a więc każda zmiana któregoś elementu lub zmiana kadrowa zaburzy prawidłowe funkcjonowanie procesu produkcyjnego.

Dobrze zaprojektowany system przechowywania ilustracji w znaczącym stopniu przyspieszy i ułatwi proces produkcji publikacji oraz, co też jest bardzo ważne, jej archiwizacji. Umożliwia też wdrożenie nowoczesnych rozwiązań w zakresie dystrybucji elektronicznej i załączania dodatkowych materiałów elektronicznych do publikacji wydawanych w innych formatach. Metody komunikacji (API) umożliwiają współpracę z pozostałymi programami wspierającymi proces produkcji, a zachowanie odpowiednich formatów (XML, JSON etc.) z jednej strony zapewnia ich ponadczasową kompatybilność, a z drugiej nie ogranicza wydawcy w wyborze innych programów wspierających produkcję i publikację.