602 Form Filler – FOP

10.6.2009 22:07 | Přečteno: 5994× |

Jak si poradí FOP s formulářem ve formátu firmy Software 602?

Získat přístup do testovací datové schránky lze nyní jen „vyplněním“ Žádosti o zřízení DEMO datové schránky.

Struktura

Soubor se žádostí je zipový archiv obsahující jediný soubor form.fo.

Ten obsahuje XMLdsig obálku s digitálním podpisem, ta uvnitř obsahuje XSL-FO dokument (xmlns:fo="http://www.w3.org/1999/XSL/Format").

Tento dokument začíná popisem struktury 602 XML formuláře (xmlns:fm="http://software602.cz/forms"). V ní je definována obálka datové zprávy (xmlns:p="http://isds.czechpoint.cz") spolu s odkazem na SOAP rozhraní Informačního systému datových schránek.

Následuje pojmenovaní vazeb mezi položkami formuláře (závislosti), omezení datových typů pomocí XMLSchema (xmlns:xs="http://www.w3.org/2001/XMLSchema"), definice SOAP komunikace (xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/").

Pak je sekce s nápovědou k formuláři napsaná taktéž v XSL-FO, výčtové datové typu (např. jména států) ve jmenném prostoru fm, pak validační funkce napsané v XSLT (xmlns:xsl="http://www.w3.org/1999/XSL/Transform"). A pak už je samotná grafická podoba formuláře v XSL-FO.

XSL-FO a FOP

Tuto část jsem zkoumal a krmil jsem jí FOP. V podstatě to jsou samé tabulky a bloky.

Problém na straně FOPu je s fo:multi-switch a souvisejícími elementy. Tyto elementy slouží k popisu proměnných částí formuláře a k mechanismu přepínání mezi případy zobrazení (například jiné „osobní“ údaje má fyzická osoba, jiné údaje poskytuje podnikající fyzická osoba). FOP toto (zatím) neimplementuje, protože se zaměřuje na sazbu statických dokumentů k tisku.

Pak jsou problémy na straně Software 602: Porušuje specifikaci, když do fo:table-cell strká rovnou inline elementy. Dále si k některým elementům přidává vlastní atributy (z globálního jmenného prostoru). Řeší tak třeba checkboxy, listboxy nebo tooltipy.

Další problém je s fonty – namísto nějakého volného fontu je v tomto konkrétním dokumentu požadována Tahoma. Dále obrázky jsou dodávány jako JPEG/JFIF kódovaný v Base64 ve jmenném prostoru fm.

Skripty

V archivu zadost_demo_ds.tar.lzma je uložen zmiňovaný formulář (zadost_demo_ds.zfo), rozbalený a naformátovaný formulář (form.fo.formated), XSLT šablona na vytažení XSL-FO formuláře (extract_fo.xsl), šablona na vytažení obrázků do adresáře internal_graphic (extract_internal_graphic.xsl), výsledný XSL-FO dokument (fo.xml) a vysázený FOPem do PDF (fo.pdf).

Práci řídí Makefile (all a clean), který obsahuje dvě konfigurační volby: jestli se mají neimplementované elementy fo:multi-* nahradit bloky (kvůli FOPu) a jestli se má nahradit font. Aktuální nastavení je u obou ano a jako font se použije Linux Libertine, který je přiložen v adresáři fonts.

Pro ty, co jen chtějí vidět výsledek, mám PDF.

       

Komentáře

[User682]

zdravim,

pekne. Hezky vyzkum.

Muzete mi poslat vystup z fop-u v rtf ? Emailem na goldenfish at linuxsoft dot cz nebo nekam vystavit.

Jak se Vam povedlo do fop-u dat ceske fonty ? Toto je vcelku porad problem.

Jinak v soucasnosti delam vcelku dost veci a vyzkumne cinnosti ohledne certifikatu a PKI.  A ohledne implementaci elektronickeho podpisu mozna bude dost

problemu s certifikaty. Protoze treba podpora revokaci a OCSP validaci asi nebude v linuxu na nejlepsi urovni. I kdyz ohledne OCSP validaci, tak na tom Windows nejsou take nejlepe. Toto jede pry az od Visty (uz asi vim, proc online validace Ceska postan eudelalala...) .

A i kdyby nekdo udelal fop-filtr pro 602 formulare do kancelarskeho baliku, tak bude vesele dodelavat veci okolo PKI infrastruktury.

Ono by mozna neskodilo s 602-software zaposlupracovat. Podle me by mohli byt v tomto pristupni.

S odstupem doby a zkusenostmi zjistuji, ze skoro vse neni poradne implementovano jak na Linuxu, tak i Windows. Samozrejme, ze se pak snazime jit za hranice moznosti implementace dane technologie. Specielne treba nejaka zabezpecena komunikace pres ruzne formaty. Nekdy ma clovek pocit, ze to IT a vyvoj software je takova divna fraska....

 

 

[petr_p]

Muzete mi poslat vystup z fop-u v rtf ?

fo.rtf.gz. OOo3.1 na něm havaruje :(

Jak se Vam povedlo do fop-u dat ceske fonty ?

Nápověda k FOPu ohledně fontů. Kdysi jsem to zkoumal a spolu s pročítáním mailing listu jsem dal dohromady skript, kterému se předhodí adresář s TTF fonty a název, pod jakým mají vystupovat v FO, a on vygeneruje soubory s metrikami a konfigurační soubor. Tohle je v obsaženo v podadresáři fonts. Když smažete *.xml a *conf a pustíte ./generatemetrics, tak to je ono.

Pak stačí fopu ukázat na konfigurační soubor parametrem -c fonts/fopfontconfig.xml.

Protoze treba podpora revokaci a OCSP validaci asi nebude v linuxu na nejlepsi urovni.

Nevím, jak je na tom OpenSSL, ale NSS to údajně umí (alespoň programy od Mozilly na to mají konfigurační dialog).

[User682]

zdravim,

\\add rtf - zkuste to rtf vygenerovat pres fop z trunk verze. V dane verzi, z ktere to generujete, tak se generuji spatne treba tabulky fontu - toto bylo opraveno, reportoval jsem to. Pak se to da i otevrit v AbiWord-u.

viz toto:

{\fonttbl {
\f0 Arial;}{
\f1 Symbol;}{
\f2 Times New Roman;}{
\f3 linlibertine;}
}

 

Pad OpenOffice - minimalne jsem se snazil zjistil/analyzovat pred rokem chybu, kde pada OpenOffice. Neuspesne. Minimalne se mi povedlo privest k Padu OO2, pri tabulkach v seznamech. Podle me se nekde generuje spatne rtf. Mozna, ze na to prijdu a jsem ochoten se mrknou na opravu ve fop-u, respektive tomu venovat nejakou hodinu. Takze tento tescase mi mozna pomuze. I kdyz importovaci filtr pro RTF do OO2,  tak to je taky kapitola sama pro sebe. Obcas chodi skvele, obcas lehne na krofky.

Ve Wordu je RTF rozhozene. Abiword - kresli to pekne, jako obvykle - importer rtf je relativne dobre napsany.

\\ add OSCP - vim, ze Mozilla toto umi. Co ale potrebuju zjistit, je treba MUA Evolution nebo KMail. Protoze elektronicky podpis bez overeni platnosti (vzhledem k odvolani) je na nic.

jinak diky.

  gf

 

[petr_p]

zkuste to rtf vygenerovat pres fop z trunk verze

Tak jsem si posháněl živé ebuildy a výstup je jiný, ale OOo stejně padají. To mi ale ani tak moc nevadí.

Jestli vás ten soubor zajímá, tak je na stejné adrese. Navíc obsahuje vizualizované informace o značkovaní form602 (zeleně).

[User682]

diky, soubor mam. Vcelku dost mi to pomuze ohledne hledani chyby.

 

[Pavel Kysilka (goldenfish)]

tak chyba nalezena.

Problemovy element se jmenuje cellx0 . Staci idealne smazat nebo doplnit misto nuly nejake cislo, idealne 1 az 20.

Nekde je chyba pri vypoctu vysky bunky tabulky.

Pak uz to OpenOffice renderuji o neco lepe (idealne pri smazani elementu - i s obrazky). Nejlepsi rendering rtf ma vsak Abiword.

Uz to chce jenom najit, kde se to spatne pocita.

gf

 

[Matěj Cepl]

\\ add OSCP - vim, ze Mozilla toto umi. Co ale potrebuju zjistit, je treba MUA Evolution nebo KMail.

Jenom poznamenám, že Evolution je také postavena na Mozillím NSS, takže by to snad mělo jít.

[petr_p]

A já poznamenám, že žádná česká autorita neprovozuje OCSP. Nabízejí jenom CRL. Naopak třeba německé autority musí provozovat OCSP. A vzhledem k tomu, že u nás ze zákona platí i unijní autority, tak je potřeba umět oboje.

[Non_E]

Moc hezký průzkum. Je vůbec nadějné tohle implementovat v linuxu přímo, bez wine?

[petr_p]

Jak na to koukám, není to zas tak složité. Spíše jde o to propojit všechny technologie dohromady – a to velmi těsně.

Takže je třeba knihovna, která rozumí XSL-FO, která dokáže vykreslit formulář. Do tohoto formuláře je nutné zasadit prvky uživatelského rozhraní (vstupní řádky, tlačítka, přepínače).

Na událost uživatelského rozhraní (např. změna hodnoty jednoho pole) musí zareagovat skript, který je vybudován na základě deklarativního popisu ve formulářovém souboru (atributy @calculate, @depends). Musí umět vyhodnocovat XPath výrazy (a navíc nějaké rozšířené funkce) nebo XSLT šablony.

Pak tam jsou navěšeny akce (@action), které umí provádět vygenerovaný kód (eval), které umí HTTP nebo SOAP protokol nebo ukládat do souboru nebo zobrazit uživateli modální okno.

Osobně tam vidím dvě větve kódu: jedna je datový model (struktura dat, vazby, závislosti, akce) a druhá je uživatelské rozhraní (widgety a FO). Tyhle dvě si zasílají události. Datový model si pak na věci mimo (HTTP, X.509, XPath, XSLT) volá funkce z jednotlivých knihoven.

Nicméně mi hlavou vrtá uživatelské rozhraní. V podstatě by se muselo udělat vykreslovací jádro jako mají webové prohlížeče. To znamená věnovat spoustu práce a výsledkem by byl od původních knihoven odtržený kód, kam by se už nedalo nic přijímat z vnějšku (něco jako se z KHTML stal Webkit). Tohle se mi vůbec nelíbí.

[User682]

V rychlosti: Vykreslovaci jadro podle me delat nemusite. To uz existuje v fop-u. Staci, kdyz si date vystup jako AWT. Tak se to tusim jmenuje.

Zkusim nejak odpovedet behem 2 dni.

[petr_p]

Obohatil jsem skript o možnost ztvárnit informace o atributech @form602*, které mimo jiné vyznačují widgety uživatelského rozhraní.

Funkce je opět volitelná. Je-li zapnutá, bude do dokumentu zelenou barvou vyznačena jejich přítomnost, typ a kontextová nápověda. Například typ txt značí textovou vstupní řádku, typ dat značí datum, typ ilb je interaktivní list box (výběr z jedné možnosti formou rozbalovací nabídky). V hranaté závorce je udán název proměnné, do které bude hodnota uložena. (Přesněji se jedná o název vazby, které jsou definovány výše a ukazují na validační funkce a na odpovídající element v XML formuláři.)

Kromě toho si můžete všimnout, že v záhlaví vpravo je dvojrozměrný čárový kód, který reprezentuje zřetězenou hodnotu všech polí formuláře. Vlevo pod záhlavím je zase místo pro MD5 otisk této hodnoty.

Nová verze je uložena ve stejné adrese (archiv i PDF).

[Fero]

Na Wikipedii se objevil clanek o 602XML. Vypada to jako napsane nekym ze Software 602. http://cs.wikipedia.org/wiki/602XML_Formul%C3%A1%C5%99