Sun uvolnil javový PDF renderer

Sun Microsystems uvolnilo open source PDF renderer, který je kompletně v Javě. Je k dispozici pod licencí LGPL. Není to žádný čerstvý projekt, Sun na něm pracoval už od roku 2003.

17.12.2007 21:40 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[YYY]

Nevi prosim nekdo, jakou alternativu pro export do pdf pouziva oo.org? Diky jestli nekdo tusi

[R]

Neviem, ale nie je to v Jave. Je to podozrivo kvalitne, funkcne a celkom rychle. Mohol by taky byt cely OOo :))

[cronin]

V Jave to je. Čo je čudné na tom, že program napísaný v Jave je rýchly, kvalitný a dobre funguje? Pred 6-7 rokmi, prosím; ale dnes mi to príde celkom normálne.

[elviin]

exportovat pdf == renderovat pdf?

[R]

Nie je to v Jave, lebo Javu nemam vobec nainstalovanu a funguje to. Preco by mal byt dnes program v Jave rychlejsi ako pred 6 rokmi? Lebo mas rychlejsie PC? Ja nemam.

[jean]

Protoze se mezitim brutalne zlepsily virtualni masiny - alespon ty od Sunu.

[neurol23]

protoze sun vylepsil jvm? protoze pouziva jit?...

[cronin]

Nie je to v Jave, lebo Javu nemam vobec nainstalovanu a funguje to.

Kúzelník!

[Václav HFechs Švirga]

Tak pak jsem mágem taky, stačí mít oo zkompilovaný s -java, jre v gentoo není :). Ale oo s javou se mi zdá paradoxně rychlejší (ve startu třeba).

[Jakub Lucký]

Taky jsem tomu nevěřil do té doby, než jsem se potkal s muCommanderem... Ten je v Javě, je brutálně rychlý a nežere (proti třeba Krusaderu (v GNOME))

[Kyosuke]

Huff...chci Tvůj počítač! Nevymeníš? Otevřel jsem dokument, skočil do poloviny - 160 MB paměti, 30 sekund strojového času, než se mi ta stránka zobrazila, a pak to šrotilo další dvě minuty. KPDF 30 MB, 2,5 sekundy; XPDF 15 MB, 0,6 sekundy. Hmm, myslím, že měnit nebudu.

[Daniel Kvasnička ml.]

Vzhledem k tomu, ze ODF je XML, jsem si na 99 % jisty, ze v tom exportu figuruje XSLT. Vubec bych se nedivil, kdyby transformovali ODF pomoci XSLT na XSL-FO stylesheet a pak nejakym vestavenym FO procesorem vyplivli PDF. Apache FOP pod Apache licenci by myslim klidne mohli pouzivat, ne?

[petr_p]

Apache FOP pod Apache licenci by myslim klidne mohli pouzivat, ne?

Asi ne. FOP obsahuje chyby (včetně chybějící podpory některých FO konstrukcí jako je zabránění zlomu stránky mezi dvěma bloky), kterými OOo netrpí. Navíc export v OOo byl už v době, kdy posledním výkřikem FOPU byla verze 0.20, která neuměla vkládat textový popis ke znakům z unicodových fontů.

[Daniel Kvasnička ml.]

Asi ne. FOP obsahuje chyby (včetně chybějící podpory některých FO konstrukcí jako je zabránění zlomu stránky mezi dvěma bloky), kterými OOo netrpí. Navíc export v OOo byl už v době, kdy posledním výkřikem FOPU byla verze 0.20, která neuměla vkládat textový popis ke znakům z unicodových fontů.

Zajimave, asi jsem FOP precenil. Muzete doporucit nejaky jiny open source XSL-FO procesor, ktery existuje jako Java knihovna? (aXSL?)

[petr_p]

Nemůžu. FOP je procesor (bez ohledu na jazyk), který dosahuje „nejlepších“ výsledků ze všech, které znám.

Ale vyvíjí se. Verze 0.93 už unicodovou textovou vrstvu do PDF zvládá (naopak se tam rozbily velké tabulky).

[Filip Jirsák]

Nemůžu. FOP je procesor (bez ohledu na jazyk), který dosahuje „nejlepších“ výsledků ze všech, které znám.

Nějaké komerční FO procesory jsou možná lepší (ale moc jsem je nezkoumal), z OSS je ale FOP opravdu nejlepší (resp. je to snad jediná implementace, která zvládá něco víc než jen naprostý základ).

Ale vyvíjí se. Verze 0.93 už unicodovou textovou vrstvu do PDF zvládá (naopak se tam rozbily velké tabulky).

A mezi tím tu máme už verzi 0.94, jsem zvědav, co bude spravené a co rozbité tam. Moc přehled nemám, protože rozdíly zkoumá kolega, ale zatím jsem zaznamenal jenom trochu jiné vykreslování rámečků tabulek (ovšem je dost možné, že teď se vykreslují správně a že se nám kreslily správně dřív byla jen souhra náhod, resp. souhra chyb).

[Filip Jirsák]

Apache FOP pod Apache licenci by myslim klidne mohli pouzivat, ne?

Nemohli. Ne kvůli licenci, ale proto, že by to nezvládl. Ostatně by to nejspíš nezvládl ani žádný jiný FO procesor, protože formát FO je proti možnostem dnešních textových procesorů značně omezený. Pro export do PDF se v OOo nepoužívá ani XSLT (pokud tedy není zadrátováno jinak, než mezi ostatními XSLT šablonami). Navíc XSLT by pro tohle bylo dost neohrabané.

[Daniel Kvasnička ml.]

Navíc XSLT by pro tohle bylo dost neohrabané.

No ja nevim. Za predpokladu ze by XSL-FO zvladalo co by bylo potreba, jaky lepsi zpusob pro prevedeni XML do PDF byste volil?

[Kyosuke]

Jakého XML? Copak OpenOffice.org při editaci textu upravuje UTF-8 buffer s dokumentem v serializované podobě?

[Daniel Kvasnička ml.]

No tak pokud vim, tak OOo umi konvertovat dokumenty do PDF i pres nejake API. Takze scenare, kdy vstupem je XML, urcite existuji.

Kazdopadne odpoved na tu otazku bych rad znal i bez vazby na OOo, ciste z praktickych duvodu.

[Filip Jirsák]

Myslím, že pro takovouhle transpormaci by se už jen vzhledem ke struktuře dokumentů vyplatilo napsat vlastní transformační engine, který by nemusle být tak obecný jako XSLT a tudíž by nepotřeboval tolik kontextových informací.

Ale jako daleko větší problém bych viděl zacílení XSLT – to je určené pro generování XML nebo textových formátů. Jenom z řešení toho aby vám transformace necpala mezery kam nemá byste se zbláznil. A pak ty různé komprese, katalogy katalogů a streamy v PDF, to by se přes XSLT dělalo dost nešikovně.

[Daniel Kvasnička ml.]

Ale jako daleko větší problém bych viděl zacílení XSLT – to je určené pro generování XML nebo textových formátů. Jenom z řešení toho aby vám transformace necpala mezery kam nemá byste se zbláznil. A pak ty různé komprese, katalogy katalogů a streamy v PDF, to by se přes XSLT dělalo dost nešikovně.

Vsak ja jsem nemyslel primo z XSLT to PDF!...to snad nikdo nedela... XSLT se prece vyuziva k transformaci libovolneho XML na FO stylesheet, ktery se pak prozene FOPem.

[m1c4a1]

Zajímalo by mě srovnání jejich rendereru s nějakými ostatními.

Jinak další skvělý krok od Sunu; teď si hraju s jejich Solarisem a až na pár chybek v GUI mi to přijde jako fajn systém.

[stativ]

Tak pokud zrovna nepoužíváš CDE tak je stejně problém nejspíš i v linuxové verzi GNOME tak nahlaš bug report.

[PMD]

Byl jsem zprvu nadšený, ale ale: nemá to podporu průhlednosti, různých kódování fontů, podporuje pouze podmnožinu pdf 1.4 a navíc chtějí podepsat nějakej svůj agreement, kdyby chtěl někdo přidat víc jak 20 řádek kódu... Být vývojářem, asi bych se jim na to pěkně z vysoka...

[Pev]

Tenhle podpis je nutný třeba i pro příspěvky openoffice.org a ti tim nemaji problem. A ze jich par tisic bude :).

Já bych spíš viděl problém toho, že vlastníkem kódů je Sun, přitom do openoffice.org přispívá firem několik.

[Petr Adámek]

Podpisem contribution agreement nepřevádíte všechna práva na SUN - ta licence, kterou mu poskytujete, je neexluzivní, takže "vlastníkem" kódu jste stále Vy a SUN Vás ani nikoho jiného nijak nemůže v nakládání s ním omezovat.

[Petr Adámek]

Podpis contribution agreement je požadován u většiny open source projektů za nimiž stojí firma SUN a většina vývojářů s tím nemá problém (já jej mám podepsaný pro NetBeans, OpenJDK, OpenSolaris i OpenOffice). Důvod je prostý - pokud by se objevily nějaké potíže např. s licencí, SUN má dostatečná práva na to, aby mohl licenci změnit. Už k tomu dokonce několikrát došlo, např. když NetBeans přešly z NetBeans License na CDDL nebo když byly nyní uvolněny i pod GPL. Když vidím problémy spojené s GFDL na Wikipedii (viz článek na Lupě) nebo když si uvědomím, že je prakticky nemožné, aby Linuxové jádro přešlo na GPLv3, přijde mi to jako docela rozumné řešení.

Pravda, někdo může mít výhrady k tomu, že se částečně zříká možnosti ovlivnit budoucí licenci jeho kódu, ale i kdyby SUN někdy v budoucnu této možnosti zneužil (čemuž nevěřím) a změnil licenci nepřijatelným způsobem, pořád je možné udělat fork pod licencí původní.