Vlákno názorů k článku LibreOffice: první rok na svobodě od Rover623 - Dost se na tom pořád dělá, za dob...

Ehm... Není mi jasná návaznost vašeho příspěvku na můj.

Ale když už o tom začínáte, tak není žádný oběd zdarma. Programátoři musí jíst, bydlet, platit účty apod. Open source hnutí stojí na myšlence, že autory SW zaplatí někdo jiný. Třeba ošklivá korporace typu Oracle, která prodává close source SW. Hlavně nesmí nic platit koncový uživatel, protože... proč vlastně? Protože komunismus až na věky? ;)

To si nějak pletete s propagandou od Microsoftu. Open source stojí na tom, že za vývoj se platí jednou, ve chvíli, kdy jej potřebujete, ne že se platí za každou kopii a ještě pokud možno několikrát. Stejně tak není pravda, že open source má být zadarmo. Free as in free speech, not a free beer.

OK, vývoj se zaplatí jednou. A je to fakt dobré pro toho, kdo ten vývoj platí? Není lepší, když se náklady na vývoj rozpustí mezi nějakou větší skupinu lidí, kterým můžeme říkat třeba platící zákazníci? Ti platící zákazníci totiž dovedou zaplatit i vývoj věcí jako AutoCAD nebo Photoshop. Vývoj open source naopak často načíná na nějakém obšlehnutém či komerčním světem opuštěném projektu, ke kterému se bez ladu a skladu připisuje, jako když pejsek a kočička vaří dort. Gimp je pěkná ukázka.
Open source je zadarmo pro každého, vyjma toho prvního.

Pokud je to pro vás moc drahé, můžete sehnat skupinu firem, které ten vývoj zaplatí. Anebo můžete použít systém spousty velkých firem vyvíjejících open source, kdy vývoj platí nějaký investor a peníze získává zpět na podpoře.

Připisování bez ladu a skladu jsem potkal věci spíše v komerčních aplikacích. MS Office je toho krásná ukázka.

Když získáte program pod open source licencí, je jenom na vás, jestli jej budete šířit dál nebo ne.

Zaplatit vývoj podporou je většinou nemožné. Už jsem to několikrát psal. Podporu může dělat kdokoliv (má k dispozici i zdroják), a nemusí platit vývoj.

Naopak MS Office je ukázka dobře napsaného SW. Ukázkou lepení je třeba ten Gimp. Všimněte si, že za MS Office jsou profesionální uživatelé ochotní zaplatit dost peněz. Gimp profi uživatele prakticky nemá.

Dle vaší teorie je to nemožné, ale reálně to funguje. Zvláštní, že?

MS Office rozhodně není dobře napsaný software. Má historii, hezky to vypadá, lidi jej znají a je problematické z něj odmigrovat někam jinam a to je tak vše. Ale když s tím zkusíte pracovat třeba pomocí VBA, tak uvidíte, jak úžasně napsané to je. Postupy používané ve Wordu nefungují v Excelu a Power Point pro jistotu nepodporuje skoro nic. Nehledě na časté kompletní změny ovládání a dělání z uživatelů blbce, aniž by bylo možné to jakkoliv přepnout do nějakého pokročilejšího režimu.

Btw. právě proto se u nás ve firmě už před několika lety přešlo z Outlooku na Lotus Notes a vážně se uvažuje o přechodu na LibreOffice. Zanedlouho možná nebude ani důvod mít tu Windows.

Jak to funguje? Tak jak je popsáno v bodu 4 tadyhle? http://www.root.cz/clanky/libreoffice-prvni-rok-na-svobode/nazory/398512/

MS Office plní potřeby profesionálů, což se třeba o tom Gimpu říci nedá. Nevím co máte na mysli s tím VBA. A časté změny ovládání? Pokud jsem si všimnul, tak jedna verze interface (menu a toolbary) se rozvíjela do verze 2003, a pak přišla změna. To mi nepřipadá jako časté změny ovládání.

Většina firem migruje opačným směrem: z Lotus Domino/Notes na Exchange/Outlook. S LibreOffice si to užijte. Pokud potřebujete cokoliv trochu pokročilého, nebo nějaké doplňky (použitelné kontingenční tabulky, faxování, integraci s DMS apod), rychle zjistíte, že tudy cesta nevede. Nehledě na to, že LibreOffice vám přinese problémy s interoperabilitou. Pánové totiž nejsou schopní OOXML slušně implementovat ani na základě dokumentace.

Až do verze 2003 to šlo. Pak se to měnilo každou verzi. Teda vypadá to podobně, ale mění se umístění jednotlivých prvků. Vzhledem k tomu, že ty verze byly dvě, tak vám to možná nepřijde tak často, ale mě jo. AFAIK ve verzi 2012 to má být zase nějak jinak.

Nevšiml jsem si, spíše se setkávám s migracemi pryč z Outlooku. Ale ty samozřejmě neohulí MS v reklamě, takže je možná akorát nevidíte. Třeba jako to udělala londýnská burza. Za velké slávy se přešlo na Windows, pak jim to několikrát spadlo a potom potichu přešli na Linux.

Nevím, co máte na mysli tím "použitelné kontingenční tabulky", ale my je používáme tak, jak to LO umí.

Na faxování už teď používáme RTF šablony a je klid. Donutit Word faxovat tak, jak chceme my, a ne jak to vymyslel nějaký chytrák v Redmondu, je totiž zřejmě nemožné.

DMS jsme nikdy nepoužívali, bylo s tím víc problémů než užitku. Ukázalo se, že je daleko jednodušší dokument rozdělit a po zpracování copy+paste složit.

Takže "kompletní změny ovládání" podle vás vypadají tak, že se přesune nějaká položka na jinou kartu? :)

S čím se vy osobně setkáváte, to není moc vypovídající. Vy okolo sebe například vidíte hromadou uživatelů desktopového Linuxu, i když ve skutečnosti tvoří téměř zanedbatelné procento uživatelů.

Pivot tables v OOo/LO jsou terčem stížností ohledně výkonu i features.

Faxování není o šablonách. Je o tom, že potřebujete z pracovního prostředí odesílat a přijímat faxy. V případě MS Office máte k dispozici řadu dobře integrovaných řešení. S OOo/LO je vaše situace daleko horší.
DMS není o zpracování dokumentu více uživateli. Je o centrálním skladování dokumentů, o verzování a schvalování. Například v právní nebo projektové kanceláři nemůžete na dotaz "kde jsou smlouvy k případu 12345" říct "na tom dělal Franta, tak já se ho zeptám, kam to ukládal" :). Sdílené disky fungují, můžete zatřídit dokumenty například ve stylu zákazník\případ\člo­věk\aktivita. Bohužel pokud potřebujete všechny dokumenty na kterých dělal Franta včera, nebo všechny aktivity prováděné pro zákazníka X, budete to značně obtížné. U DMS zadáte dotaz, a je hotovo.

Navic si lze v moznostech vybrat ukladani ve schvalenem standardu. To v M$ nelze.

To je samozřejmě nesmysl. MS Office 2010 ukládá data v souladu se standardem ISO/IEC 29500 (ano, jde o Transitional část specifikace, ale to na tom nic nemění). Navíc umí ukládat i do ODF, samozřejmě se ztrátou některých features, o čemž pochopitelně informuje.

Podpora ODF v MSO je hodně tristní. Pluginy od třetích stran poskytují daleko lepší výsledky.

To víte, MS to nejspíš psal podle specifikace ODF, a ne podle zdrojáků OOo ;)

To nevysvětluje, proč to správně nepřečte dokumenty v ISO ODF bez jakýchkoliv rozšíření.

Nečte správně ISO ODF dokumenty, nebo nečte správně to co OOo zapíše když vyberete jako formát ISO ODF? :)

Nečte správně ani ISO ODF dokumenty, které jsou z KWrite nebo AbiWordu.

...přičemž KWrite i AbiWord jsou napsané podle zdrojáků OOo...

Nevím, jak AbiWord, ale KWrite tak napsaný určitě není.

Kdo vám říkal, že se implementace ISO/IEC 29500 Transitional nedoporučuje? *Některé části* Part 4 se doporučuje neimplementovat. Samozřejmě část pro kompatibilitu s ECMA-376 1st edition by měla být implementována, pokud takové dokumenty chcete číst.

ODF 1.2 není standardizované. OASIS ani ECMA se nepočítá; kdyby se tyhle dvě organizace počítaly, k válce ODF vs OOXML by nikdy nedošlo.

Dokumenty psané OOo obsahují velkou spoustu věcí, které žádná verze ODF nepopisuje, a *nejsou* v souladu s ISO/IEC 26300.
Dokumenty psané MS Office jsou v souladu s ISO/IEC 29500 Transitional.

Celá aféra s OOXML navíc ukazuje jednu věc. Autoři OOo tvrdili, že s formáty MS Office není možné v OOo pořádně pracovat, protože není k dispozici dokumentace. Dnes je k dispozici dokumentace binárních (DOC, XLS) i XML-based (DOCX, XLSX) formátů. Přitom podpora XML-based formátů je snad ještě horší, než těch starých binárních. Problém zjevně není v dokumentaci - což jsem ostatně tvrdil už před lety.

ECMA-376 edition 1 není kompatibilní s ISO OOXML Transitional. Celá ISO OOXML Part 4 se navíc nedoporučuje implementovat, protože bude odebrána v budoucí verzi ISO OOXML. Ale pokud chcete číst data z MS Office, tak to holt implementovat musíte.

U OOo můžete zvolit, aby ukládalo dokumenty do ISO ODF 1.0 a potom to udělá. To, že ODF 1.2, do kterého ukládá OOo ve výchozím nastavení, obsahuje rozšíření, které ODF 1.0 nepopisuje, není v rozporu s tím standardem.

Problém není ani tak s dokumentací, jako s tím, že ten standard je splácaný dohromady, spoustu věcí implementuje několikrát a pokaždé jinak a naprosto ignoruje existující standardy, které mají přinejmenším stejné a často i lepší pokrytí toho, čeho se týkají. Převody mezi řešeními založeným na standardech a OOXML je potom velice složité.

ISO OOXML Transitional je kompatibilní s ECMA-376 edition 1, možná s nějakou nepodstatnou výjimkou.
Na tom se shodneme: pokud chcete číst data MS Office, ISO OOXML Part 4 implementovat musíte. Nevidím, proč by se implementace nedoporučovala. Vždyť v ISO OOXML Transitional existuje obrovská spousta dokumentů.

OOXML je vytýkáno, že například zarovnávání v buňce má jiné tagy, než v odstavci. Jenže buňka není odstavec, takže je to úplně jedno.
OOXML pochopitelně používá řadu existujících standardů, včetně XML :). Nicméně ISO má pro spoustu věcí víc standardů, není to nic proti ničemu.

Jedna z těch nepodstatných výjimek je zápis data a času, nic důležitého ;-)

Microsoft tu implementaci možná doporučuje, ale ISO ji nedoporučuje. Ale protože OOXML používá stejně jenom MS Office, které ale používá jenom Transitional verzi, tak je vlastně jedno, co tvrdí ISO. Celý ten standard je vlastně akorát cár papíru.

Není to jedno. Můžete jednoduše vykreslit buňku pomocí stejné rutiny, která vykresluje odstavec. Teda mohl byste, kdyby to nebylo OOXML. Jenže nejde jenom o zarovnání, rozdílné dokumenty zapisují totožné vlastnosti naprosto jinak, což jenom ukazuje, jaký bordel panuje při vývoji MS Office. Pak se nemůže nikdo divit, že OpenOffice (nebo i KOffice), které mají společné vykreslovací rutiny pro textové dokumenty, spread sheety i prezentace, musí mít spoustu hnusných obezliček, aby to vůbec zvládli vykreslit a zároveň ten dokument zvalidovat.

Ale některé nekonzistence v OOXML jsou ještě horší. Třeba atribut "rgb", který je ve skutečnosti ARGB, přičemž RGB se píše do atributu "color". Který inteligent v Microsoftu tohle vymyslel?

Řekněme nic co by programátor nezvládl.

Každý standard je cár papíru. BTW OOXML podporuje dlouhá řada SW, včetně OOo :)

Buňku těžko budete kreslit tak jako odstavec, protože mají úplně odlišné vlastnosti, a navíc jde o odlišné aplikace (Word vs Excel). Navíc ta kreslicí rutina nepracuje s XML, ale s binární reprezentací dokumentu. Pokud byste trval na jedné rutině, stačí si udělat triviální transformaci při načítání toho XML.

Není úplně jedno, jestli se atribut jmenuje rgb, argb, nebo třeba qwerty? OOXML má zpracovávat aplikace, a té je to fakt jedno. Programátor pro změnu píše podle dokumentace a ne podle názvu tagů. Podle mě hledáte problémy tam, kde žádné nejsou.

Možná by to zvládl, ale rozhodně není ISO OOXML Transitional a ECMA-376 edition 1 to samé.

Proč by ne, OOo i KOffice to tak dělají a jde to.. Samozřejmě není povinnost to tak udělat, ale proč mi OOXML hází klacky pod nohy, když to tak udělat chci? Otázkou je, proč bych to měl transformovat, když to klidně můžu vykreslovat podle DOM. Teda mohl bych, kdyby to nebylo OOXML.

Není to jedno. To rovnou Microsoft mohl zůstat u toho svýho binárního blobu a nesnažit se dělat, že OOXML je vlastně XML napsané někým, kdo umí alespoň trochu přemýšlet. Ale když se podíváte do dokumentace Win32 API, tak je to zřejmě nějaký zvyk v Microsoftu, pojmenovávat funkce a proměnné trochu jinak, než co dělají.

ISO OOXML Transitional a ECMA-376 edition 1 jsou prakticky totožné, to snad víte stejně jako já.

Buňka ve spreadsheetu a odstavec v dokumentu jsou naopak typicky odlišné objekty. Vykreslovat podle DOM samozřejmě můžete. Ten budete mít v paměti ve formě nějakého grafu, a je celkem nedůležité, jak při parsování toho XML budete překládat tagy.

Proč to není jedno? Jak jsem psal: uživateli je to jedno, a kdo píše implementaci, stejně jí musí psát podle *dokumentace*, ne podle názvu tagů.