No mě by teda upřímně zajímalo. Jakou cennovou politiku pro Linux co se týče MS Office nasadí. Protože pokud se nemýlím, tak základní balík MS Office kupovaný spolu s novým počítačem a windows stojí něco okolo ~2500kč a to v případě Linuxu jaksi tato podmínka odpadá. Takže kolik ten balík bude stát? ~7000Kč box verze? To snad ne. ~3700kč jako "legalizační" verze? no Tak to nevím jestli jim někdo koupí, když tu je relativně slušný LibreOffice a jiné "Office".
Mě by nepřekvapilo, kdybychom se toho dočkali. Ale kvalita bude katastrofální. Bude to padat a řada věcí nebude podporovaná. Prostě jako u většiny MS software, kde je třeba formálně vykázat, že produkt je multiplatformní, splňuje nějaké standardy a podobně. V praxi se ale na ničem jiném než Windows pořádně provozovat nedá a standardy jsou přiohnuté tak, aby to s jiným softwarem nefungovalo. Takhle to Microsoft dělá desítky let a nemá důvod tu strategii měnit.
Cena může být stejná jako v případě Office pro Macy (přibližně od 2500 do 5000 Kč). Že je to mnohonásobně víc než u konkurenčního software od Apple nikoho v Microsoftu netrápí. Dominantní pozici na trhu jim zajišťuje to, že jiní výrobci ani po mnoha letech snažení nejsou schopní plně podporovat formáty Microsoftu.
Můžu se jenom zeptat, co brání ostatním výrobcům v implementaci dokumentovaných formátů DOC/XLS/PPT, a standardizovaných formátů DOCX/XLSX/PPTX? Podle mě je to primárně nedostatek zdrojů na provedení plné implementace, a samozřejmě technické rozdíly mezi office produkty různých výrobců.
A preco mu TOLKO ROKOV trvalo vobec implementovat vlastny bastl? Preco 2007 ani 2010 nepodporuje strict? A preco OOXML z Office 2007 obsahuje binarne hovna - http://fsfe.org/activities/os/msooxml-interoperability.en.html?
Formáty MS Office byly standardizovány původně pod ECMA jako ECMA-376 v prosinci 2006. Při ISO standardizaci došlo ke změnám, a výsledný standard ISO/IEC 29500:2008 byl schválen v listopadu 2008. Office 2007 asi těžko mohl umět OOXML Strict, když byl vydaný dříve, než vyšel standard. Office 2010 umí OOXML Strict číst, ale nikoliv zapisovat. To sice není ideální, ale pořád jde o standardní OOXML.
Ta "binární hovna" co jste linkoval jsou nastavení tiskárny. To je uživatelská věc, která rendrování dokumentu nijak neovlivňuje. Navíc je klidně možné, že jsou tam jen pro implementaci kompatibility s Wordem 95, kde layout záležel na metrice fontů u zvolené tiskárny, což tehdy mělo velmi dobré technické důvody.
Teď se budu ptát já. Proč proboha Sun dával ke standardizaci ODF bez takových "drobností" jako jsou vzorce? Kdyby jim šlo o interoperabilitu, byl by ODF kompletním popisem souborového formátu. Samozřejmě pokud šlo Sunu jen o protlačení zákazníky do té doby ignorovaným StarOffice/OOo argumentem "my máme standard", a o interoperabilitu jim nikdy nešlo, tak by to mělo smysl :)
Dále proč StarOffice i OOo píšou do dokumentů spoustu věcí, které v žádném standardu nejsou popsané? Zkuste si někdy rozbalit ODF dokument zapsaný pomocí OOo, vedle toho dát ISO/IEC 26300:2006/Amd 1:2012, a budete se divit, co všechno ten standard nepopisuje.
A proč v tom ISO standardu dodnes nejsou ani ty vzorce? To fakt neměli autoři ODF za 7(!) let čas specifikaci dopsat a prohnat ISO standardizací?
ANO! To bude ten nedostatek zdrojů... Nedostatek zdrojů na implementování standardu, který má >6000 stránek. Není to trochu moc?:-) To vypadá trošku jako snaha vyhnout se jiným implementacím.. Mimochodem, četl jsem, že tam ani není uveden macro jazyk, takže můžeme ještě přidat kompletní implementaci .NET pro kompatibilitu. To už není mezinárodní otevřený standard, že? Aha, viď..
Formát souboru musí být schopen podchytit veškeré konstrukce, které lze do dokumentu uložit, a slušně je popsat. U velkého balíku typu MS Office to není jednoduché. ODF je o trochu kratší než OOXML, ale jednak ne o moc, a potom řadu věcí vůbec nepopisuje. Nejsou to jen vzorce. OOo píše do dokumentů například nastavení tiskárny, o kterém ODF vůbec nemluví. Takových věcí co v ODF chybějí jsou... stovky až tisíce stran :)
Makro jazyk není součástí OOXML. Objektový model je věcí aplikace, nikoliv souborového formátu. Nakonec HTML také nepopisuje JavaScript. Jo a ještě detail: makra MS Office jsou ve VBA, nikoliv v .NETu.
Zkusme konkrétní věc. Excel (a OOXML) umožňuje formátovat buňku tak, že se její barva v závislosti na číselné hodnotě buňky pohybuje na barevné škále. Tohle lze implementovat i v OOo/LO, ale udělali to až v LO 4.0. Proč to tak podle vás je? Příliš komplikovaná dokumentace, nebo nedostatek zdrojů pro vývoj a rozdíly v technickém řešení obou produktů? Podobných příkladů je velká spousta.
*konkrétně je to 6764/1135 (přibližně 6x) delší! (ve stránkách; ISO/IEC 29500 vs. OASIS OpenDocument v1.2). Mimochodem, v1.2 už definuje vzorce... Vyžádalo si to asi 250 stran.. Fíha! Už jen 20 takových a tyhle standardy jsou stejně dlouhé.
Mohlo by se tedy zdát, že se MS nesnažil o to, udělat standard jednoduchý (tzn. implementovatelný i někým jiným), ale naopak složitý. K těm barevným škálám.. Neřekl bych, že to, že jsme je v LO neměli je nedostatkem vývoje: spíš tím, že to nikdo nepotřebuje.
Celkem změn LO-3-6 až LO-4-0 (řádky +-): 3311697
Změn týkajících se cond. formátování: 2163 (zdaleka ne jen barvičky)..
Jo... Takže určitě na to chyběly HR :-)
Ano, formát ODF 1.2 definuje vzorce. Až od od října 2011(!), a neprošel ISO standardizací, takže se dost možná bude ještě měnit.
Už vám někdo řek, že počet stránek závisí na velikosti fontu, velikosti okrajů stránky apod.? Ten rozdíl ve skutečnosti není tak velký. OOXML je pochopitelně složitější specifikace, protože toho popisuje více a podrobněji.
Takže autoři OOo/LO implementují záměrně jen části standardu s tím, že zbytek vlastně nikdo nepotřebuje, a s množstvím prostředků na vývoj to nijak nesouvisí? No to je mi zajímavé zjištění. Jistě to potěší všechny ty uživatele, kterým OOo/LO při importu mrší dokumenty MS Office.
Binární formáty DOC/XLS nebyly stavěné pro přenositelnost mezi různými aplikacemi. Ono totiž ukládat dokument do textového XML, a to pak komprimovat, má značné nároky na výkon. Formáty DOC/XLS jsou technicky celkem pěkné. Stojí nad OLE Compound File, a je to vlastně malý FS. Samozřejmě pro interoperabilitu to není ideální, pokud nemáte korektní implementaci OLE Compound File.
Řekněme podobný "bordel", jaký třeba ODF nebo OOXML tahá v ZIP souboru, který je přejmenovaný na .odf nebo .docx. Jenom je to v binární formě, takže je to celé daleko rychlejší a úspornější.
Když mluvíte o "bordelu" Registry, tak mi osobně přijde dobré mít jednu konfigurační databázi, která je řádově rychlejší než konfiguráky (zvlášť při zápisu), umožňuje přístup z více aplikací najednou, je transakční, umožňuje automatické zálohy (Last Known Good Configuration), a má jeden formát (ve srovnání s ini files se sekcemi, bez sekcí, xml files, tím formátem se závorkami co používá Oracle, tím se složenými závorkami, s escapováním a bez escapování atd.)