Trable s hromadnou korespondencí v OOo

5.6.2006 16:43 | Přečteno: 1718× | Mohlo by se někomu hodit

Teoreticky není na hromadné korespondenci nic obtížného, prostě se textová šablona naplní daty z databáze a výsledek pošle na tiskárnu. Z mně neznámého důvodu však tuto činnost vždy doprovázím skřípáním zubů, aktuálně jsem tím zabil takřka celý minulý týden.

Zadání úkolu

Mým úkolem bylo připravit řádově stovky smluv, každou ve dvou vyhotoveních, přičemž tyto smlouvy obsahují osobní údaje osob, tj. mimo jiné jméno, bydliště a datum narození. Tato data lze (s patřičným oprávněním) relativně snadno získat z našeho informačního systému ve formě textových souborů (klasické CSV – hodnoty oddělené středníkem); vzhledem k jakési klasifikaci skupin osob se mi podařilo vydolovat asi dvacet takovýchto tabulek údajů.
Jelikož šablonu již kdosi připravil přede mnou ve Wordu, sáhl jsem pro účely hromadné korespondence po OpenOffice; vinou jakýchci peripetií jsem celý proces absolvoval jak ve verzi 1.1.3, tak v 2.0.0, díky čemuž jsem získal získal velmi přesnou představu o rozdílech, jak tyto různé verze OOo spravují datové zdroje.

Problém s datumem

Databáze, odkud jsem tahal potřebné údaje, umí vypsat datum v několika variantách, mimo jiné také měsíc slovně v druhém pádě, tj. například 2. června 2006. Vzhledem k tomu, že právě v tomto tvaru jsem datum narození chtěl ve výsledných dokumentech vypisovat, zvolil jsem tuto možnost. To jsem samozřejmě ještě netušil, jak moc se bude OpenOffice snažit být chytřejší než uživatel – OOo ve verzi 1.1.3 poznal, že se jedná o datumy, a proto ve výpisu zdrojů datum vypsal měsíce číslicemi. To by nebyl zas až takový problém, protože lze snadno naklikat, který formát datumu se má na výstupu používat, včetně slovního vyjádření v druhém pádě, zádrhel byl ovšem v tom, že nerozumí termínu července – v těchto místech prostě v tabulce ukazuje prázdné místo a při dosazení dat do formuláře pak vypisuje datum 1. 1. 1900. Nepřišel jsem na to, jak při vytváření zdroje dat specifikovat pro jednotlivé sloupce datový typ a dodatečné změny z datumu na text mají za následek vypisování nějakého čísla, patrně počtu dní od nějakého počítačového počátku.

OOo 2.0 datum s měsícem slovně v druhém pádě nezná a ani jej neumí takto formátovat – což je zcela jistě krok zpět oproti jedničkovým verzím OOo. Pro mé potřeby se to však zdánlivě jevilo výhodnější, neboť datum mohl OOo chápat jako text a nepokoušet se o nějakou konverzi, o kterou nestojím. Nebýt ovšem toho, že měsíc září má druhý pád stejný jako první. A slovní vyjádření měsíce v prvním pádě OOo 2.0 zvládá – stále mi není jasné, na základě čeho OOo při definici datového zdroje rozhoduje, že data v daném sloupečku tvoří datum, každopádně však u zhruba poloviny tabulek to poznal, výsledkem čehož byly prázdná místa v tabulce všude tam, kde byl jiný měsíc než září. Grrr!

Korespondence v OOo 1.1

Definici zdrojů dat jsem v OOo 1.1 zvládl rychleji než později v novější verzi kancelářského balíku, pro mé potřeby zde bylo hned vše po ruce včetně specifikace kódování znaků; tabulku, kterou chci aktuálně plnit šablonu, stačí vybrat jen jednou. S výjimkou výše popsaného problému s datumem šlo vše hladce až do okamžiku, kdy jsem zjistil, že OOo 1.1 neumí sloučit výsledek do jediného dokumentu! A já nebyl v situaci, kdy bych mohl výsledek přímo posílat na tiskárnu. Rozhodl jsem se tuto hořkou piluku spolknout s úmyslem, že jednotlivé dokumenty dávkově převedu na PDFka a ty následně sloučím.

Pro převod výsledných smluv na příkazovém řádku jsem použil makro a skript odsud. Funguje krásně a pokud je přitom i nějaká aplikace OOo spuštěna, funguje i docela svižně, neboť se pořád dokola celé OOo nespouští a neukončuje (což jsem si bohužel všiml, až když už jsem měl skoro vše převedené).
Pro sloučení jednotlivých PDFek do jediného dokumentu jsem sáhl po prográmku pdftk, který jsem si v poslední době velice oblíbil – až nyní jsem však zjistil, že neskousne soubor obsahující v názvu diakritiku, a já si samozřejmě výsledné soubory nechal pojmenovat po dotčené osobě. Takže před převodem jsem ještě absolvoval hromadné přejmenovávání souborů, zde mi pomohl KRename.

Korespondence v OOo 2.0

Druhý den jsem zjistil, že exportní funkce do PDF v OOo nezachovává průhlednost u obrázků, což se v mém konkrétním případě ukázalo jako velmi podstatný problém, takže jsem byl vlastně zase na začátku, ovšem u jiného počítače s novější verzi OpenOffice. Ta již naštěstí umí výsledek hromadné korespondence sloučit do jediného výsledného souboru, proto jsem hledal cestu, jak export do PDF udělat jinak a lépe. S pomocí programu na správu tiskáren v OpenOffice spadmin (chvíli mi trvalo, než jsem zjistil, že v SUSE 10.0 je nainstalován v /usr/lib/ooo-2.0/program) jsem přidal nové propojení na převaděč PDF a jako ovladač zvolil Adobe Distiller. Ten nejenže zvládá průhledné obrázky, ale výsledné soubory měly až poloviční velikost.

Jak jsem zajásal, že OOo 2.0 již umí výsledek sloučit do jednoho dokumentu, tak jsem záhy zjistil, že poněkud předčasně. V textu smlouvy se totiž vyskytuje číslovaný seznam odrážek, který měl tendenci v číslování pokračovat z předchozí stránky – tento nešvar jsem zatrhl vložením logické sekce na konec šablony, možná právě to však zase způsobilo, že za každou smlouvu se vložila jedna prázdná strana. Grrr. Naštěstí text smlouvy vyšel taktéž na jednu stránku, takže jsem později do PDF tiskl vždy jen liché strany.

Pro definování datových zdrojů nově v OOo 2.0 slouží samostatný modul databáze, což s sebou sice přináší některé nové vlastnosti, na druhou stranu například takovou znakovou sadu je nutno dodefinovat až dodatečně (Úpravy – Databáze – Vlastnosti) a nepřišel jsem na to, jak ze všech souborů s definovanou příponou (obvykle TXT či CSV) v jednom adresáři vybrat pouze některé z nich. O problému s datumem již nemluvě. Dále jsem nepochopil, proč tabulku, s kterou chci právě pracovat, musím vybírat dvakrát, jednou v průvodci hromadnou korespondencí a podruhé přes dialog Úpravy – Vyměnit databázi. Průvodce mě přesto potěšil – na vhodných místech disponuje tlačítkem Upravit dokument, které průvodce odsune do pozadí a dovolí s aktuálním stavem dokumentu dělat libovolné úpravy. Díky tomu jsem průvodce ani jednou nedokončil, ve vhodný okamžik jsem se přepnul na úpravy a tiskem do PDF jsem se konečně dočkal touženého výsledku.

Tisk dokumentů

Pro úplnost dodávám, že ani tisk té hromady papírů se neobešel bez problémů. Nejdříve jsem totiž zkoušel tiskové úlohy svěřit kopírkotiskárnám provozovaným jistou nejmenovanou firmou v naší škole. Bohužel zdejší stroje Ricoh Aficio neobsahují Postscript a pro Linux jsem zase neobjevil nativní ovladač PCL 5c. Ono by to zas až tak nevadilo, protože donedávna jsem úspěšně používal nějaký obecný ovladač PCL 5c; někde se však něco muselo změnit, neboť nyní už mi z tiskárny lezou jen prázdné papíry. A když jsem to zkoušel řešit s technikem, tak ten se jen divil, proč mu to účtuje korunu deset za barevný tisk, no škoda mluvit ... smlouvy nakonec musel tisknout kolega z počítače s Windows

Bojujete také občas s hromadnou korespondencí?

       

Komentáře

[Robert Krátký]

Bojuji s tím vždy jednou do roka, když je čas rozeslat autorům abclinuxu.cz vyúčtování honorářů za články. Letos mi dělaly největší starost pády OOo při pokusu o start generování jednotlivých dopisů. Spolehlivě to slítlo vždy při stejném kroku - tj. definice datového zdroje, polí atd., to všechno bylo v pohodě, ale jakmile jsem chtěl spustit generování dokumentů, program se poroučel.

Řešení bylo nakonec velmi jednoduché. Stáhl jsem build přímo od českého lokalizačního týmu a nahradil jsem jím verzi z Debianu, kterou jsem měl nainstalovanou původně. A bylo hotovo - tento build nepadal.

Samou radostí jsem pak zapomněl zkontrolovat oslovení v generovaných mailech (generovaná PDF jsem rovnou rozesílal emailem), takže všichni dostali zprávu, která začínala:

Vážená paní,

[Filip Jirsák]

Jsou popsané chyby OOo nareportované do bugzilly? Nebo alespoň konzultované s českým lokalizačním týmem? Nerad bych na ně narazil, až budu hromadnou korespondenci v OOo potřebovat

[Jiří Poláček]

Ne. Jsem jediný, kdo trpí averzí se pořád někde registrovat?

[Filip Jirsák]

A tady se registrovat vám nevadilo?

Nezlobte se, ale stěžovat si na chyby, když máte možnost přispět k jejich opravě a neuděláte to, mi přijde přinejmenším sobecké. Pochopil bych, že se někdo nevyzná v IssueZille, pochopil bych, že se někdo necítí chybu dobře popsat, pochopil bych, že si někdo nevěří ohledně angličtiny. Ve všech těch případech bych ocenil, kdybyste napsal "necítím se na to, pomůže mi někdo chybu reportovat?" (A to nejlépe kdyby to bylo už v původním spotu.) Ale averze k registracím mi připadá jako výmluva.

Skoro bych si přál, aby v OOo ta chyba zůstala a vy jste se s ní musel za půl roku trápit znova. Patřilo by vám to.

[Jiří Poláček]

A tady se registrovat vám nevadilo?

Vadilo, však jsem se taky hodně dlouho rozmýšlel.

Ano, je to sobecká výmluva, ale pravdivá. A ano, je docela pravděpodobné, že se s tou stejnou chybou budu za půl roku trápit znova. Asi to zní divně, ale já to beru jako cenu za tu svou averzi

[Petr Kroupa]

Zkousel jsem to jednou a bylo to horsi nez porod. Tak jsem to po hodine vzdal a sel do M$ Wordu, kde mi to trvalo asi 3 minuty. Tady ma OO jeste velky kus cesty pred sebou.

[fettgesicht]

V MS Office tahle záležitost taky není bez problémů - konkrétně datum. Jako zdroj dat do dopisů jsem použil excelovou tabulku, ale za živého boha jsem nemohl Word/Excel přinutit, aby ve výsledné korespondenci bylo datum v nějakém českém formátu. Adresáti mi pak odpovídali stylem, že "k události X určitě nedošlo 2.25.2004...