Názory k článku
Microsoft bude podporovat ODF

Proč by specifikace nemohla mít 6000 stran? "Plný" Office je holt komplexní kus SW. Je to pořád lepší, než mít napůl-specifikaci typu prvních verzí HTML, nebo ODF, na základě kterých v podstatě nelze implementovat interoperabilně.

TeX a odvozeniny považuji, díky absenci vizuálního interface, za nevyhovující.

> Proč by specifikace nemohla mít 6000 stran?

Zkusil jste ji přečíst?

Zřejmě proto, že programátoři, nehledě na to, kolik se jim zaplatí a kolik na tom stráví času, jsou jen lidé a řídit se takto rozsáhlým předpisem je nadlický úkol.

Lepší mít něco, co funguje všude stejně, než obludu, co nefunguje nikde a to ještě pokaždé jinak.

> TeX a odvozeniny považuji, díky absenci vizuálního interface, za nevyhovující.

http://kile.sourceforge.net/

Microsoft Word považuji, díky absenci základních typografických potřeb, jako nedělitelná mezera (to není totéž, jako pevná) či schopnosti renderovat text alespoň trochu hezky, za nevyhovující i na psaní popisků na krabice drahého softwaru.

Pro doplnění, zdá se vám například C jako málo interoperabilní? Běží v podstatě na čemkoliv a umožňuje psát rozsáhlé kusy software pro zcela odlišné platformy a přitom má pouhých 500 stran specifikace. To se dá naučit a dá se to přečíst asi za týden tak, aby člověk měl představu, o čem to celé je.

> Word ale neni sazeci software, jak jste si jiste vsiml. Stejne tak jako ze Office neni Word.

To byla jen reakce na velmi nepřátelskou poznámku označující TeX a v zásadě všechny sázecí systémy za "nevyhovující". Stejně tak, jako se někomu může TeX nelíbit, tak mě se nelíbí Word a jiné WYTYSINWYG editory, protože jsou prostě na některé věci neohrabané a slabé.

> A C snad nepopisuje zadny pokrocily format tj. spoustu ruzne funkcionality pro zpracovani nekolika zcela ruznymi aplikacemi, ze?

Ne, popisuje jazyk, kterým se má dát jednoduše vyjádřit libovolná věc, kterou počítač umí udělat. To mi přijde jako sakra víc, než formát uložení statických dat.

> C je nejaky obecny ramec - pravidla a veskerou funkconalitu tvori programator. Dokumentovy format musi popisovat vesklerou funkcionalitu. Co v nm neni, to neni mozne do dokumentu ulozit a nelze s tim v aplikaci pracovat.

Já si naopak myslím, že takový dokument je jen něco jako jazyk jak popsat nikoliv děj, ale stav. To, jak dobře s ním bude aplikace mluvit - jaké věci do toho bude umět uložit, je již na implementaci, ne na formátu. Formát má říkat, jak ten jazyk vypadá a jak se to má zobrazit, když je to již napsané.

> Ale jak se to ma zobrazit a co se s tim da delat je preci pro kancelarsky format ale naprosto zasadni pokud nam jde o interoperabilitu!

Ale to jsem přeci říkal! Že to má popsat, jak se má která věc zobrazit. Pokud to ale má 6000 stránek, tak je ten formát/jazyk buď velmi špatně navržen, nebo je příliš "High-Level". Podle mě by takový formát měl být jednoduchý, a složitější věci by se z toho měly skládá.

Pak by mělo být jednoduché udělat interpretter - zobrazovátko, již těžší by bylo ukládání - aplikace musí "vymyslet" jak ty složitější věci poskládat.

Ale stojím si za tím, že člověk (minimálně jeden v týmu) takovou specifikaci, pokud ji implementuje, musí přečíst a porozumět jí, což je u 6000 stránek dlouhého dokumentu dost nereálné. Stejně tak by si to měli přečíst ti lidé v komisi, kteří o tom hlasují. A alespoň kousek by si měl přečíst každý, kdo to podporuje, já zatím tvrdím, že 6000 stránek je značný problém, tak by mě zajímal nějaký protiargument, proč to nejde kratší.

člověk (minimálně jeden v týmu) takovou specifikaci, pokud ji implementuje, musí přečíst a porozumět jí -- nesmysl. Když budete implementovat ODF, také si ho musí někdo kompletně přečíst, včetně všech odkazovaných norem (a rekurzivně)?

Nevynechal, přemýšlel u toho popsání. Nebo to alespoň rozdělil na několik nezávislých termínů. A to vymyslet - když se vrátím třeba k TeXu - napsat tučný nápis je možné mnoha způsoby, které se ve výsledku zobrazí stejně. Stejně tak v C:

a = a * 2;

je zcela totéž jako

a *= 2;

(pokud je a proměnná, ne výraz).

Specifikace jen říká výsledek, ne jak zapsat to co zamýšlím.

Technická poznámka: program samozřejmě vždy interně udržuje data v binární formě. Výsledný XML je vždy dump nějaké binární struktury. Rozdíl je v tom, že XML je velmi ukecané, kdežto binární formát je velmi úsporný. Já si osobně myslím, že OOXML ani PDF nebude plně implementovat nikdo. Možná občas někdo vygeneruje fakturu v OOXML, případně z nějakého dokumentu vytěží data (obojí se dělá i bez XML), ale to je tak vše. RTF je také textové a popsané, a zdaleka přesto zdaleka není interpretováno vždy stejně.

OOXML a 6000 stran: Zkusil jste někdy sníst slona? Šlo by to špatně. Leda byste ho jedl po kouskách. Nejlépe ve více lidech. Podobně se dělají velké projekty. Každý dělá svůj kousek.

Kolik stran si myslíte, že mají jiné speficikace? Jen takový SQL 2003 (dotazovací jazyk) má 3800 stran. ODF má sice jen 738 stran, ale referuje řadu dalších dokumentů, a s nimi se také dostane na těžké tisíce; přitom ODF hromadu věcí nepopisuje, což je trestuhodné.

Kile je v kontextu kancelářského SW super vtip. Pokud se vám to, že TeX a odvozeniny považuji, díky absenci vizuálního interface, za nevyhovující, zdá "velmi nepřátelská poznámka", tak je to k zamyšlení. Nepřátelské to není ani k TeXu, ani k vám. Spíš to svědčí o tom, že si jedna vaše část uvědomuje, že mám pravdu, a druhá má potřebu křičet, protože je jí *TeX drahý ;)

Můžete
mi prosím řici, jaký je rozdíl mezi nedělitelnou a pevnou mezerou? Nejlépe prosím anglické termíny. V české se neorientuji. Co to znamená "rendrovat text trochu hezky"? To bude asi typografi
cký termín, který mi úplně utekl.

C je interoperabilní? A zkusil jste si přeložit třeba zdroják psaný pro Windows na Unixu? Navíc specifikace C sice má jen 550 stran, ale k psaní SW potřebujete ještě znát framework, který bude mít specifikaci velmi rozsáhlou (pokud je to slušný framework). Specifikace C# má 117 stran, ale už CLI (runtime environment) má 550 stran. A to ještě neumíme ani Hello World, protože nemáme specifikaci platformy. Ta se dodává na DVD ;)

Ale pokud to berete tak, že C má 500 stran, a to stačí, tak můžeme vydat specifikaci znakové sady ASCII. Ta bude mít jen pár desítek stránek. S tou pak můžete psát dokument v ODF nebo OOXML.

Ad "Lepší mít něco, co funguje všude stejně, než obludu, co nefunguje nikde a to ještě pokaždé jinak." - obludou je ODF. Hromadu věcí nespecifikuje (třeba ta profláklá absence vzorců), takže má velmi dobré předpoklady fungovat pokaždé jinak.

> Každý dělá svůj kousek.
Jenže, když se člověk podívá na slona, tak má alespoň dojem jak vypadá a není problém kousek vybrat. Neříkám, že tam musí být člověk, co si to pamatuje slovo od slova, ale musí mít přehled aby to rozdělil. Jinak vznikne chaos.

> ODF má sice jen 738 stran, ale referuje řadu dalších dokumentů, a s nimi se také dostane na těžké tisíce;

Ty ale už někdo může znát, někdo někdy implementoval, takže se to dá znovu použít. Minimálně se už přišlo na to, kde jsou s tím problémy, pokud to nějakou dobu přežilo a nebylo třeba nahradit a tak.

> C je interoperabilní? A zkusil jste si přeložit třeba zdroják psaný pro Windows na Unixu?

V C běžně píšu tak, aby to šlo přeložit kdekoliv, tedy pod normou Ansi C. Většinou to jsou výpočty, okénka píšu pod C++ nebo tak, ale dovolím si tvrdit, že by mé programy běžely na čemkoliv, od kalkulaček, přes PC (nehledě na platformě) až po sálové mainframy. Pokud chci použít nějakou specialitu lokálního prostředí, jako třeba solární panel kalkulačky, pak mi v tom samozřejmě nebude bránit a je to můj problém, že kde není solární panel kalkulačky, tam to nepoběží.

A pokud mě ta část na kreslení okýnek a používání tiskárny nezajímá, tak nemusím získat a číst další dokument.

> Můžete mi prosím řici, jaký je rozdíl mezi nedělitelnou a pevnou mezerou?

Udělejte si pokus. Vemte Word nebo něco takového, napište 2 nebo 3, někde dejte pevnou mezeru a zarovnejte do bloku. Všechny normální mezery změní trošku velikost (při velkých fontech je to obzvlášť vidět), zatímco pevná mezera si ponechá původní velikost. Nedělitelná mezera se jen nezalomí na konci řádku, ale velikost si upravuje taky.

> rendrovat text trochu hezky

To není termín, to je povzdech nad kvalitou. Když vidím ty toky co zanechává, jeden řádek mezery úplně sražené a jiný roztažené, parchanty a sirotky, tak je mi smutno.

> velmi nepřátelská poznámka

Nikoliv to, že je považujete. Považujte si co chcete za co chcete. Buď jste zcela nepochopil mínění původní poznámky, které mělo znamenat, že nepovažuju za dobré ani ODF, ani OpenXML a bylo by třeba zahodit _oboje_, nebo jste chtěl záměrně provokovat. A nechte prosím stranou moji psychologii a půlky, toto bych mohl taktéž považovat za osobní útok.

> Ad "Lepší mít něco,…

Očividně vzorce nepatří do toho "něco". Aspoň ten čistý text by to mohlo mít použitelný.

A kdybyste se mě ptal, jak bych takový standard dělal já, tak asi takto (vezmu si například textové dokumenty, neboť nad tím nechci strávit příliš mnoho času):

Rád bych využil již existující věci. Tak například, v TeXu se dá napsat cokoliv, jen to mnozí neumějí. Taktéž je to špatně parsovatelné aplikací -> vezmu nějakou podmnožinu řekněme LaTeXu (má již tabulky a podobně), ve které rozhodně nebudou věci jako definice maker.

Abych k tomu mohl dávat obrázky, tak je budu ukládat vedle a dovnitř dávat odkaz.

Stejně tak skripty, řekněme že vyberu třeba lua a dám tomu pár funkcí na manipulaci s textem (perl lidem podstrkovat nebudu).

A protože mi vznikl pěkný adresář a lidi by raději soubor, tak se to celé obalí nějakým tarem nebo zipem.

Odhadem to vyjde na takových <100 stránek, ten kdo to implementuje může použít existující věci a je to rozšířitelné (do toho adresáře se dají přidat další typy souborů).

Skoro si začínám říkat, že by se to dalo sepsat, udělat ukázková implementace a zkusit to standardizovat.

Každý dělá svůj kousek: k tomu nemusíte specifikaci přečíst. Stačí summary,. což je 178 stran. Nebo musíte přečíst 6000 stran, abyste věděl, že kapitolu 14 (DrawingML) bude implementovat tým Franty?

Odkazování na jiné dokumenty: aha, takže pokud by MS vydal 10 dokumentů, například DrawingML, SpreadsheetML, VML Drawing atd., bylo by to OK, protože by se to dalo zpracovávat zvlášť. Kdežto když jsou to kapitoly jedné specifikace, tak je to hrozně špatně, protože se to rozdělit nedá. Jinak pokud standard není úspěšný, tak se prostě nepoužívá. Takových kousků leží ladem hromada. Dále OOXML je výsledkem mnoha let vývoje Office aplikací, a má za sebou firmu, která vytvořila nejúspěšnější Office aplikace v historii. Tedy vše se již osvědčilo.

Vaše C zdrojáky možná běží po kompilaci na čemkoliv, většina programů ale ne. Interoperabilita C je velmi špatná. Navíc má tento jazyk celou řadu dalších problémů. Například ten, že lidé vždy dělají chyby (z definice). A C je na chyby velmi náchylné, a neupozorní na ně. Za všechny viz primitivní if (a=5), nebo profláklé bezpečnostní problémy při nesprávném použití strcpy. Můžete tvrdit, že programátor nesmí být idiot, jenže on v průměru udělá jednu chybu na 100 řádek, a nedá se s tím nic dělat :(

Ano, pevná mezera je pevná. To je bohužel omezení Wordu (a řady dalších aplikací). MS Word má orphans control. Tedy pokud si to člověk nevypnul. Stejně tak korektně řeší mezislovní mezery. Naopak mezery mezi písmeny se měnit nemají (lze to ale zapnout). pochopitelně podporuje kerning.

Pokud máte vyšší nároky na typografii, mohu doporučit MS Publisher. Tam nedělitená mezera běhá, jak má. Dá se použít pro pre-press (umí třeba dobré separace). Jen bych se osobně vyhnul používání těch připravených šablon, které jsou někdy dost děsné.

K velmi nepřátelské poznámce se těžko mohu vyjadřovat. Zvláště pokud takové vyjádření budete považovat za velmi nepřátelské ;). Nemáte nějaký problém?

Kdybyste psal specifikaci pro hladký text, nebylo by to tak složité. Jenže i tam se dnes snažíme, aby se výsledek dal parsovat XML parserem (což u TeXu není možné). Navíc potřebujeme podporu formulářů, read-only popisek, polí, tabulek, vzorců, vektorové grafiky, vazbu na externí zdroje dat atd.

> Odkazování na jiné dokumenty: aha, takže pokud by MS vydal 10 dokumentů, například DrawingML, SpreadsheetML, VML Drawing atd., bylo by to OK, protože by se to dalo zpracovávat zvlášť. Kdežto když jsou to kapitoly jedné specifikace, tak je to hrozně špatně, protože se to rozdělit nedá. Jinak pokud standard není úspěšný, tak se prostě nepoužívá. Takových kousků leží ladem hromada. Dále OOXML je výsledkem mnoha let vývoje Office aplikací, a má za sebou firmu, která vytvořila nejúspěšnější Office aplikace v historii. Tedy vše se již osvědčilo.

Za prvé, neříkám že by to bylo OK, ale rozhodně lepší. Takto to je monolit. Ze striktního hlediska nemůžu udělat jen textový procesor, neboť mi ty další kusy chybí.

> Pokud máte vyšší nároky na typografii, mohu doporučit MS Publisher.

Proč? Mě zcela vyhovuje to, že si můžu makra a podobně psát, jak se mi zachce a že na to můžu pustit libovolný nástroj na úpravu textu. Proč bych si kvůli tomu měl pořizovat Windows a ještě nějakou aplikaci k tomu?

> Nemáte nějaký problém?

Již jednou jsem vás slušně žádal, abyste si odpustil osobní útoky.

> aby se výsledek dal parsovat XML parserem (což u TeXu není možné)

Což je možná z toho důvodu, že autorům šlo o to, aby se to pohodlně psalo/četlo lidem, a ne strojům. Osobně preferuji tento přístup, neboť jsem člověk a ne stroj.

> Navíc potřebujeme podporu formulářů, read-only popisek, polí, tabulek, vzorců, vektorové grafiky, vazbu na externí zdroje dat atd.

A není to trochu overkill, mít to v základní verzi? Nebylo by třeba lepší udělat něco pro "normální použití" a nad to dát extended věci, jako jsou zdroje dat a vzorce? Kolik lidí z těch co znáte v MS office dělá něco jiného než že píše text?

Striktně řečeno můžete implementovat WordprocessingML, a vynechat PresentationML. Předpokládám, že převodník z DOCX do ODF udělá přesně tohle. Podobně můžete udělat Unicode font, který má latinku a azbuku, ale nemá arabštinu.

Makra jsou super. Tedy trochu jiná makra. V MS Publisheru není problém pomocí maker ve VBA udělat připojení k DB, tahat z ní data, a na základě toho třeba vyrábět dokumenty. MS Office je vůbec zajímavá platforma.

S těmi osobními útoky máte problém vy. Pouze se vás zcela slušně ptám, jestli nemáte problém, když poznámku "TeX a odvozeniny považuji, díky absenci vizuálního interface, za nevyhovující" považujete za velmi nepřátelskou poznámku (aka osobní útok). Ale to fakt nevede. Slibuji, že vám už *TeX nebudu pomlouvat, abyste neměl (neoprávněný) dojem, že na vás útočím.

ODF i OOXML jsou tu proto, aby je četly stroje. Uživatel má WYSIWYG interface, bez kterého aplikaci odmítne (viz osud... no, raději nic).

Těžko mít jako standardní Office formát něco, co nedokáže popsat dnešní dokumenty. Z podstaty XML ale můžete ignorovat věci, kterým nerozumíte, a pořád z dokumentu něco dostanete. Jinak lidé používají MS Office třeba tak, že do Wordu vloží sheet z Excelu, list prezentace z PowerPointu, graf, nebo cokoliv jiného. Řada firem má templaty, které sahají do DB, DMS, atd. Těžko to ale uvidíte, jestli píšete v C a *TeXu. Stejně tak účetní bude těžko mít představu, jak se píše pro signálové procesory.

Ještě bych upozornil na WordSetter, který se často používá jako podpora pro sazbu ve Wordu.

http://www.editorium.com/14000.htm

100 človekorokov programátorskej je běžný rozsah většího projektu. Sun má na OpenOffice 60 lidí. Chcete takový formát, který zvládne jeden člověk implementovat za měsíc? Super, ale ten bude pro Office naprosto nevhodný.

kuakua "z oci", sorry :/

Bohužel na PPC, Sparc apod není komfortní prostředí, nejsou aplikace, a vyvíjí daleko obtížněji, než pro Win32/.NET. Své věco bez problému otevřu na Windows 2000. Ty jsem léta provozoval na Pentiu 233MHz s 32MB RAM (pravda, používat na něm Visual Studio/C++ bylo nešťastné).

Bankomaty? Neběží jich většina na Windows Embedded? ;)

Ano, v MSVS (co to proboha je?) si člověk na programátora jen hraje. Pravý tvrďák píše účto v ASM za pomoci VI, protože si umí spočítat náklady a cenu času, že? :))

MS si vytváří vlastní standardy? Ano. A kdo ne? Když žádný standard neexistuje, nebo není pro daný účel vhodný, tak se buď implementuje něco úplně nového, nebo se nějaký standard použije přiohne. Jak byste to dělal vy?

MS si standardy přiohýbá i když jsou pro daný účel vhodné. Viz klasický případ ISO latin 2 vs win1250.

8859-2 je code page, která je pro grafické systémy nevhodná. Neobsahuje typografické uvozovky, a řadu dalších důležitých znaků. MS si tedy ohnul 8859-1 na ANSI 1252, a přidal si potřebné znaky. Bohužel některé ty přidané znaky (třeba š aka 's' s hackem) jsou v 8859-2 na jiné pozici, takže následná ANSI 1250 je od 8859-2 v pár znacích odlišná. Ale jistě to byl zlý záměr MS, jak zničit východní Evropu ;)

Co je to za blbost? OOXML verze 1 se mi válí na disku, je volně ke stažení. Jednak od ECMA, a pak zřejmě i draft od ISO.

http://www.ecma-international.org/publications/standards/Ecma-376.htm

Podle vás je nejlepší formát, který sice neumí to, co je potřeba (kompatibilita se stávajícími dokumenty, vzorce v souborech tabulkového kalkulátoru apod), ale zato je "kvalitní"? V čem je ODF tak kvalitní? V tom, že je specifikace neúplná, a proto krátká? No jestli je to jediná výhoda, tak to není nic moc ;)

Současné soubory DOC se dají převést do RTF, a to bezeztrátově (s výjimkou maker). Když si MS usmyslí, že v příští verzi dokumenty neotevřu, tak zůstanu u současné verze, a trh nabídne pokračování cesty. Obdobně když si Oracle (IBM, Corel, Adobe) usmyslí, že na příští verzi jeho RDBMS (Lotus Domino, Draw, Photoshop) nebude možné upgradovat (otevírat datové soubory předchozích verzí), podřízne si větev. Proč by to asi tak dotyční dělali?

Hovorím o DOC, nie ooxml. Hovorím, že nemá zmysel porovnávať DOC s ODF, pretože NIET ČO porovnávať.

Pokiaľ ide o ODF vs OOXML, Ty si zase myslíš, že lepší je taký štandard, ktorý je síce prakticky neimplementovateľný (nielen kvôli rozsahu, ale kvôli odkazovaniu na vonkajšie neznáme zdroje typu "urob to ako word95")? Taký, ktorý v podstate úplne pozná a teda môže implementovať len jedna firma? Taký, ktorý porušuje množstvo ustanovených štandardov? Taká, ktorú keď sa Ti aj podarí implementovať, čelíš patentovej žalobe?

Podľa mňa je lepší ODF, na ktorom niekoľko rokov pracovala skupina vedúcich firiem, takže je výsledkom širokého pripomienkovania. ODF dodržuje platné štandardy, implementovať sa dá celkom dobre (už ho podporuje aspoň tucet programov). ODF sa bude ďalej rozširovať podľa požiadaviek a zachová spätnú kompatibilitu.

Prevod do M$ RTF nič nerieši, lebo M$ si aj RTF priohol podľa seba a napchal tam funkcie z Wordu. Export do HTML má podobný problém, lebo HTML od M$ má len málo spoločného s medzinárodnou normou.

DOC lze psát i číst s pomocí Wordu. Není problém z vnější aplikace Word skriptovat: vytvořit dokument ze šablony, nasázet do něj data, vytisknout, vyexportovat (třeba do textového RTF), uložit, data vytěžit. Už to je celkem dost. A na základě smlouvy s MS lze získat více (což se pár výrobcům SW podařilo).

OOXML zjevně implementovat lze, důkazem budiž MS Office. Rozsah OOXML je podobný, jako u OpenOffice po započtení odkazovaných dokumentů, tedy pokud se použije stejně velké písmo a řádkování :). OOXML není závislé na věcech typu "urob to ako word95". Tyto věci jsou tam pro zpětnou kompatibilitu, a ostatním výrobcům se doporučuje je ignorovat (viz specifikace OOXML). Není pravda, že OOXML může implementovat jen jedna firma. Není pravda, že OOXML porušuje standardy. Nejvýše zavádí jiné, což je smyslem standardu ;). ODF naopak používá třeba SVG, které nikdo plně neimplementuje (a ani OpenOffice ho nepoužívá). Není pravda, že implementace OOXML je důvodem k patentové žalobě. Tolik k FUDu. V mých komentářích za poslední 3 dny je pár fakt a dotazů o ODF, na které zřejmě nemůže nikdo pořádně reagovat. Například to, že ODF řadu věcí nepopisuje, a OpenOffice (coby jediná funkční implementace ODF, která není jen hračkou) produkuje dokumenty obsahující řadu věcí, které v ODF nejsou vůbec popsané.

Samozřejmě, že RTF obsahuje nové funkce Wordu (viz MS specifikace RTF). Jak má asi Word exportovat beze ztráty do formátu, který neumí features, které Word umí? To by mě fakt zajímalo. Nebo má MS z wordu odstranit věci, které neumí OpenOffice, AbiWord, KWord a ostatní, aby jim také dal šanci? :)) Export do HTML má MS ve dvou formách. Plná forma ukládá (téměř) veškeré features Wordu, i když nejdou v HTML zobrazit. Při importu takového HTML ve Wordu dostane člověk skoro původní dokument, což klasické HTML neumí (ale je to žádoucí). Filtrované HTML tyto informace neobsahuje.

to jsem zapomněl říci. Vaše výroky byly zákeřně směšné. Ne tvoje, protože si netykáme. Nevím, kde plebs tenhle zvyk berou. Na pivo spolu nechodíme.

Tykanie je súčasťou netikety už asi 30 rokov. Mimochodom, vykanie je aristokratický prežitok.

Tykání bylo součástí netikety v době, kdy se počítače týkaly pár lidí na MIT. Zkuste si napsat email s žádostí o informace k bankovnímu úvěru, a tykejte v něm. Pak si to přečtěte. Vykání je v češtině základní způsob oslovování osob, se kterými člověk nemá bližší vztah. Samozřejmě nevím, jak to máte na Slovensku ;)

To mě zajímá. Jak takový Gnumeric (podřadný tabulkový kalkulátor) importuje a exportuje ODF, když ODF vůbec nepopisuje vzorce pro spreadsheet aplikace? ;)

Autoři ODF, tedy Sun, se se svým (ne)zastoupením na trhu Office snaží říkat, jaké features vlastně uživatelé potřebují? No to není špatný vtip :). Jinak ODF vyjma absence vzorců nepopisuje ani řadu jiných důležitých věcí, viz weby k tématu. "Elegantní" je také to, že pro implementaci ODF je nutné implementovat Javu (Java objekty jsou v ODF popsány jako nativní). Moc pěkné. Se specifikací Javy se jistě ODF nedostane na 6000 stran :)

Ano, OOXML je komplexnější. Mimo jiné umožňuje převést stávající dokumenty beze ztrát. To je věcí formátu. Například formát plain text neumožňuje převést dokument typu ODF beze ztrát, protože neumí vlastnosti stránky (a řadu dalších věcí). Podobně ODF některé features prostě nemá.

OOXML není dokonalá specifikace, ale svému účelu může sloužit celkem dobře. ODF nikoliv, protože postrádá features, které jsou v praxi zásadní.

"OOXML s jediným elementom <asinword95>, ktorý vo vnútri obsahuje binárne údaje" je nepodařený pokus o vtip? Tagy typu <asinword95> jsou věcí zpětné kompatibility, a můžete je ignorovat. V takovém případě budete mít dokument vyrendrovaný lehce odlišně, nicméně čitelný bude. Pokud ho chcete vidět vždy správně, použijte MS Office ;)

Se specifikací Javy se jistě ODF nedostane na 6000 stran :)

Az na takú drobnosť, ze špecifikaciu Javy uz niekto implementoval, a to dokonca viackrát, takže si môžem vybrať, ktorý hotový produkt JDK (Sun, IBM, Bea, ...) a pre akú platformu (Windows, Solaris, AIX, Linux, ... ) použijem. Špecifikáciu Javy čítať nemusím.

Mimo jiné umožňuje převést stávající dokumenty beze ztrát.

Skúsim zopakovať, čo som už povedal : Prevod formátov dokumentov NIE JE zaležitosť formátu ale konverzných programov. A teda kvalita prevodu závisí od kvality konverzného programu. Takže ak použijem XSLT a vyťahám z ODF/OOXML texty bez elementov dostanem síce čistý texťák ( == urobil som konverziu ), ale čítať sa to nebude dať == kvalita prevodu je mizerná, a pritom sa dali rozumne zvýrazniť nadpisy, odseky, číslovanie ...

ODF nikoliv, protože postrádá features, které jsou v praxi zásadní.

Ktoré sú to tie v praxi zasadne funkcie ?

Tagy typu <asinword95> jsou věcí zpětné kompatibility, a můžete je ignorovat.

Ako asi bude vyzerať algoritmus pre konverziu DOC Word 95 do OOXML ?

1. vytvor hlavičku OOXML
2. otvor element <asinword95>
3. skopíruj obsah DOC na výstup
4. zatvor element </asinword95>
5. vytvor pätičku OOXML

Vyhovuje to špecifikácii ? ANO, takže takýto dokument veselo rozposielam do celého sveta. Avšak niekto sa rozhodne implementovať iba povinné elementy z OOXML, a teda <asinword95> bude ignorovať. Výsledok je jasný, uživateľ neuvidí NIČ, hoci dokument je korektný.

Vo všeobecnosti platí, že špecifikácie by nemali obsahovať voliteľné časti, pretože potom sa jeden tvorca SW rozhodne zahrnúť vlastnosti A,B,C, druhý tvorca vlastnosti A,D,E. Obaja implementovali podľa špecifikácie, napriek tomu sú ich implementácie nekompatibilné a teda používateľ zostal nútený používať SW od daného výrobcu a spolupráca s uživaťelom konkurenčného SW nie je možná.

Pokud ho chcete vidět vždy správně, použijte MS Office ;)

• Ale ja nemôžem používať MS Office, pretože neexistuje pre moju platformu/procesor.
• Ale ja nemôžem používať MS Office, pretože si ho nemôžem dovoliť kúpiť
• Ale ja nechcem používať MS Office , mne vyhovuje .... ( OOffice.org, ABIWord, KWord, ... každý si doplní čo chce ...).

Napriek tomu to musím korektne vidieť, pretože je to dokument, ktorý vyprodukovala vláda / daňový úrad / sociálna poisťovňa / polícia / súd ... a ak nebudem vedieť čo po mne tieto štátne orgány chcú, tak mi hrozí pokuta alebo až väzenie.

Specifikaci OOXML už také někdo implementoval. Analogicky jí číst nemusíte ;). Dále takové DrawML lze také immplementovat zvlášť, a není k tomu třeba číst celou specifikaci OOXML. No a nakonec - nepovažuji za vhodné, aby implementace Office MUSELA nutně mít Javu.

Konverze: asi si nerozumíme. Převod mezi formáty samozřejmě musí provést nějaká aplikace. Nicméně pokud formát A umí například vlastnost antsBlack (Black Dashed Line Animation; Specifies that this text shall be surrounded by an animated black dashed line border), a formát B ho nemá, tak je to smůla, protože konverzi nelze provést beze ztráty. Tedy to na konci záleží na formátech, ne(jen) na aplikaci. No a pokud ODF neumí beze ztráty vlastností popsat dokumenty, které jsou dnes ve velkém množství ve firmách, těžko do ODF něco převádět. antsBlack je samozřejmě jen příklad, ODF neumí popsat ani řadu jiných věcí.

<asinword95>: Nedělejte tu z toho komedii pro teenagery. Žádný tag asinword95 neexistuje. Existuje třeba tag autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing, je trochu rozepsáno), který je označen jako deprecated, a doporučuje se ho neimplementovat (tedy ignorovat). Další podobné jsou adjustLineHeightInTable, alignTablesRowByRow, allowSpaceOfSameStyleInTable, applyBreakingRules, autofitToFirstFixedWidthCell atd.

ODF naopak moc nepopisuje. Řada věcí popsána stylem "contains application specific settings", apod. Navíc i OpenOffice do svých dokumentů cpe řadu věcí, které v ODF vůbec nejsou popsané (což je dobrý humor, když je ODF standardizovaným výcucem formátu OpenOffice). Příkladem budiž AutoCalculate, CurrentDatabaseCommandType, HasSheetTabs, IsLabelDocument, IsKernAsianPunctuation, PrintBlackFonts, ShowZeroValues, UpdateFromTemplate a mnoho dalších. Jinými slovy ODF není dostačující ani k implementaci tabulkového kalkulátoru (neumí vzorce), ani k dekódování dokumentů OpenOffice. Abych přečetl dokument OpenOffice, budu muset implementovat ODF, plus louskat zdrojáky OpenOffice, abych zjistil, co ten který tag má dělat (přičtěme k ODF pár milionů řádek zdrojáku, a pár let jejich louskání).

Viděl jste vůbec specifikaci OOXML či ODF, když jsme u toho? A co byste říkal tomu, kdyby MS "otevřel" své formáty DOC/XLS (či DOCX/PPTX) tak, že by například nebylo popsané, co dělají funkce u tabulkového kalkulátoru?

Nemůžete použít MS Office, protože platforma? Použijte jinou platformu (Windows, MacOS, nějakou emulaci). Nebo chcete nárokovat, že jakákoliv platforma musí povinně umožňovat číst dokumenty státní správy? BeOS, AmigaOS, ZX Spectrum? Asi ne. Opravdu si nemůžete dovolit MS Office za 3000 Kč? Tak použijte Word Viewer (pro Windows, nebo ho můžete běžet v emulaci), je zdarma. Nevyhovuje vám MS Office? Řešte si tedy situaci ve své režii (třeba zkuste import v OpenOffice). Dokumenty můžete od státní správy vždy získat ve více formátech, například na papíře. Když nemám peníze na připojení k inetu, tak si také musím vyhlášku přečíst na radnici na vývěsní desce (ano, to existuje).

Specifikaci OOXML už také někdo implementoval. Analogicky jí číst nemusíte ;).

• Koľko je tých implementácii ?
• Na koľkých platformách to beží ?
• Kde nájdem zdrojáky k referenčnej implementácii alebo ľubovoľnej inej implementácii ?

Použijte jinou platformu (Windows, MacOS, nějakou emulaci).

Nemám Windows ani MacOS. Nepoznám emuláciu ktorá by umožnovala beh Windows aplikácii bez licencie Windows. A to som si nie istý, či prevádzkou Windows programov pod emuláciou neporušujem licenčné pravidlá.

Nebo chcete nárokovat, že jakákoliv platforma musí povinně umožňovat číst dokumenty státní správy?

Nie. Chcem aby na akejkoľvek platforme (existujúcej alebo budúcej) bolo možné v rozumnom čase vytvoriť program na čítanie takýchto dokumentov. Chcem, aby ma štátna správa ( na prevádzku ktorej prispievam nemalou sumou vo forme daní ), nenútila zvyšovať zisky jednej konkrétnej komerčnej firmy.

Opravdu si nemůžete dovolit MS Office za 3000 Kč? Tak použijte Word Viewer (pro Windows, nebo ho můžete běžet v emulaci), je zdarma.

Môžem si dovoliť MS Office, ale 3000Kč viem investovať aj rozumnejšie. Navyše na beh MS Office potrebujem Windows, čo je ďalších 1500Kč za OEM ( licenciu Windows potrebujem aj pre emuláciu ). Oveľa väčšími nákladmi na prevádzku, je však čas potrebný na údržbu ďalšieho systému ( záplatovanie, vírová ochrana, .... )

Implementací OOXML (MSO 2007) po světě běhá více, než instalací Linuxu. Běží na Intel IA64, AMD x86-64, Intel x86, PowerPC. Referenční implementaaci? Vy chcete, aby za vás ten Office někdo napsal? ;) Ale možná když se s MS dohodnete na penězích...

Nevyznám se v emulátorech Windows, ale "cizí" implementace Win32 nepotřebuje licenci od původního autora. Rovněž jsem nestudoval licenční smlouvu Office. Vy ano?

Aha, chcete číst dokumenty kdekoliv. Když pomineme technické a licenční problémy (můj telefon nezvládne OOXML ani ODF; pro iPhone a řadu dalších zařízení nic nenapíšu, protože je platforma uzavřená), tak těžko tvrdit, že je to nějaký nárok. Opakuji, že od státní správy můžete dokument dostat na papíře, k čemuž nemusíte mít Windows, Office, připojení k inetu, ani počítač. Boty a oblečení jsou ale doporučené i když přijdete na úřad ;)

Když jsme u té rozumně krátké implementace, jak budete implementovat ODF, když v řadě případů budete mít ve specifikaci pouze něco typu "application specific"? Podle čeho budete interpretovat třeba formula="oooc:=AVERAGE([.A1:.A4])", když to není nikde popsané? Navíc jediný SW, který produkuje ODF, a není to úplná hračka, je OpenOffice. Podle čeho budete implementovat třeba věci z ooo:configuration settings? Namátkou UpdateFromTemplate, nebo PrinterSetup, což je BLOB, uložený v BASE64? A nevyčítal jste před pár dny ty BLOBy formátu OOXML (onen neexistující BLOB asInWord95)? ;)

Náklady na provoz Windows/Office jsou ve skutečnosti celkem nízké. Není totiž nutné řešit triviality typu rozchození WiFi, grafické karty či 3D akcelerace, není třeba se učit skriptovat bash, ovládat vi, ani znát umístění a obsah konfiguráků. Při otevření běžně používaných souborů (třeba ceníku produktů Novellu, který vystaují na webu pouze v XLS :)) se nic nehroutí. Když chce člověk účtovat, vést základní školu, vést projekt, restauraci či hotel, napsat skladbu, nebo použít třeba DMS, alternativy se mu prodraží tak, že se oči protočí.