Názory k článku
Wine 2.0 přináší podporu Microsoft Office 2013

Heh ... ono staci, kdyz sedej dva lidi u stejnych opic na jinym PC. Jeden udela jednostrankovej dokument, a druhej pak 1/2 dne resi, jak to vytisknout jinak nez na dve stranky.

Alternativne ti cesky opice nabidnou US formaty papiru, takze pak neustale resis, ze tiskarna vazne jinej format nez A4/A3 nema, a tudiz ani nevytiskne. Pokud mas obzlvastni kliku, tak vidis na obrazovce jednu stranku, tvrdi ti to ze tiskne jednu stranku, ale vyleze jich N +-∞ (videl sem treba takovy vystupy, ze to tisklo dokument postupne po 1px radcich per stranka).

Ad ono to nejde spravne ani medzi verziami officu kolko krat - dokážete popsat nějaký konkrétní scénář, jak způsobit aby dokument třeba z Wordu 2010 nešel otevřít ve Wordu 2013? Předpokladem je že máte na počítačích stejné fonty, a dokument nemá nastavenou compatibility option "Use printer metrics to lay out document" (která byla by default aktivní naposledy tuším ve Wordu 95).

Ad mnoho z tych formatov v podstate ani nie je file format, ale memory dump aplikacie prehnany serializerom a skonvertovany do kopky XML - upřímně netuším jak jinak než serializací do XML byste chtěl implementovat ukládání dokumentu do XML formátu. Těžko může aplikace interně pracovat přímo s XML. Síla formátů OOXML a ODF není ani tak v tom že je to XML, ale spíš v tom že jsou dokumentované, takže jejich implementace je snazší než u binárních formátů. Samozřejmě funkcionalita MS Office i LibreOffice je tak rozsáhlá, že implementace jejich formátu je i přes jejich dokumentaci řekněme netriviální úkol.

Let the flames begin!
http://ooxmlisdefectivebydesign.blogspot.cz/

Ne, touhle čas opravdu věnovat nebudu. Defective by design je ODF, které nepopisovalo pro spreadsheety tak zásadní věc, jako jsou vzorce. Jak potom chcete mluvit o formátu zajišťujícím interoperabilitu? Spreadsheet bez porozumění vzorců je dost na nic. A po ISO standardizaci ODF trvalo dalších 8.5 roku, než se do toho standardu ty vzorce dostaly. Takhle nehotový standard neměl být nikdy přijat.

Tovizjo lulane, ono je daleko lepsi vzorce prekladat ... a prelozeny je pochopitelne i ulozit. To pak mooc dobre funguje, kdyz chce nekdo otevrit vytvor z nemeckych opic v tech ceskych ...

ODF definuje od prvního ISO standardu vzorce pro tabulky ve wordprocessingu (pouze pár funkcí typu MIN, MAX, AVG), a samozřejmě ta definice byla oddělená od vzorců ve spreadsheetech. Předpokládám že ani ODF 1.2 nepoužívá ty samé vzorce pro spreadsheet a wordprocessing.

Ad navzdory Ribbonu pres pul vysky monitoru - ribbon u mě má 112 pixelů, a už od první verze se dá snadno schovávat. Doporučuji vám koupit si monitor s vertikálním rozlišením (výrazně) vyšším než 224 pixelů :D

Už jsem vám to psal mnohokrát, ale zřejmě je to potřeba zopakovat. Vzorce se v Excelu zadávají a zobrazují lokalizované, ale ukládají se vždy v angličtině. Pokud máte na sheetu nějakou chybějící funkci s cizojazyčným názvem, tak je to nejspíš makro, které má jen jedno jméno ve všech jazycích, a vy ho v souboru prostě nemáte.

Jinými slovy když si německý kolega vyrobí spreadsheet, napíše do něj vzorec SUMME(B5:C7) a soubor uloží, tak český kolega při otevření uvidí SUMA(B5:C7). V souboru bude zapsáno SUM(B5:C7).
Pokud německý kolega založí makro Kraftfahrzeug­Haftpflichtver­sicherungPreis, tak ho český kolega uvidí pod stejným názvem.
Pokud německý kolega založí makro Kraftfahrzeug­Haftpflichtver­sicherungPreis a pošle českému kolegovi soubor bez toho makra, tam český kolega uvidí neznámou funkci Kraftfahrzeug­Haftpflichtver­sicherungPreis.

Už je to jasné?

A BTW memory dumpem bylo myšleno např. toto:
http://www.robweir.com/blog/2006/10/bit-about-bit-with-bits.html

Autor tvrdí že používat bitmasky je špatné, protože je není možné validovat pomocí XSD a transformovat pomocí XSLT. Jako příklad uvádí strukturu tagLOCALESIGNATURE. Jde o nepovinnou součást popisu fontu. Ten popis se dá použít pro nalezení alternativního fontu, pokud originální není k dispozici. Z dokumentace je vidět, že první member struktury je DWORD lsUsb[4], což je 128-bitový bitfield. Každý ze 122 použitých bitů označuje jestli je ve fontu přítomný příslušný Unicode Range, a je to převzaté ze specifikace OpenType. Pomocí XSD na tom není co validovat. Autor by zřejmě místo jedné bitmasky použil 128 booleanů, které se typicky deserializují na int a nikoliv na bitové pole. Ostatní dva members jsou na tom velmi podobně.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318714(v=vs.85).aspx

Upozorňuji že ta informace ve formátu být musí nějak popsaná, protože jinak nebylo možné zapsat všechny informace, které obsahuje formát DOC. A formát pro word processing bez možnosti kompletně popsat dokument formátu DOC je mrtvý, jak je vidět třeba na tom že do převodu z DOC na ODF se nikdo nehrnul.

Navíc se autor mýlí když tvrdí, že bitmasky nelze transformovat pomocí XSLT. Už od XSLT 1.0 to jde.
http://stackoverflow.com/questions/26544577/how-to-use-bitwise-or-in-xslt

Nakonec mě pobavilo tohle: If I told you the “table style conditional formatting exception” had the value of 32, would that mean anything to you? Or would it send you hunting through a 6,000+ page specification in search for a meaning? ... A primary virtue of XML is that it is humanly readable. Wow. On chce implementovat formát tak že si prostě přečte schema definition a bude se podle jmen atributů dohadovat co mají znamenat, aby se nemusel koukat do dokumentace? No to je fakt síla, skoro se přestávám divit tomu jak vypadá (ne)podpora OOXML v LibreOffice. Navíc pokud považuje za výhodu XML to že je čitelné pro lidi, tak by měl nějakému uživateli rozbalit XML z dokumentu DOCX nebo ODT, a nechat ho těch pár MB přečíst. Chtěl bych slyšet následné hodnocení čitelnosti :)

http://r.ebay.com/6wcdT2