OOXML samozřejmě je standard, konkrétně ISO/IEC 29500. Naopak u ODF je zásadním problémem to, že dokumenty ve skutečnosti psané například balíkem OpenOffice obsahují spoustu věcí, které v žádném standardu popsané nejsou. Navíc například vzorce ve spreadsheetech nadále nemají ISO standard (v OOXML jsou vzorce v ISO standardu více než 5 let). Výsledkem je situace, kdy jedinou použitelnou dokumentací formátu ODF je zdroják OpenOffice. A dnes aby se jeden ještě ptal, jestli jde o zdroják OpenOffice nebo LibreOffice.
Cim to je, ze Vase prispevky su casto jednostranne prospesne pre MS produkty? Zeby dalsi plateny diskuter (tak, ako u nas su zaplavovane diskusie brigadnikmi zo SMERu)? Skoda.
Aby som vyvazil Vas jednostranny prispevok: V OOXML su perly ako renderAsWord95, k comu dokumentacia je jedine zdrojak Wordu 95, ktory nie je dostupny. Schvalovaci proces OOXML sprevadzali perly ako ze to schvalovalo ministerstvo podohospodarstva, apod. Oba formaty maju svoje muchy.
V OOXML su perly ako renderAsWord95 - to si pletete s autoSpaceLikeWord95 :). Tyhle věci jsou nutné pro převod starých dokumentů MS Office do nových formátů beze změny vzhledu. A samozřejmě jsou v ISO normě popsané. Koukněte na chapter 14.7.3.4:
autoSpaceLikeWord95 (Incorrectly Adjust Text Spacing for Specific Unicode Ranges)
This element specifies adjustments (detailed below) which should be applied to the spacing between adjoining regions of non-ideographic and ideographic text when the autoSpaceDE (Part 1, §17.3.1.2) and autoSpaceDN (Part 1, §17.3.1.3) elements have a value of true (or equivalent). This algorithm typically results in the following...
Jistě se navíc shodneme, že ve srovnání s tím, že ODF nemá ani dnes standard popisující vzorce ve spreadsheetech, jde o naprostou prkotinu.
Schvalovaci proces OOXML sprevadzali perly... jako že se společnosti Sun a IBM snažily zneužít standardizační proces, zabránit konkurenci v získání ISO standardu a v kombinaci s lobbingem za zákony nařizující "otevřené standardy" tak netržně protlačit nikým nechtěný OOo do státní správy. Jo, to bylo svinstvo nejvyššího řádu. A tak jako si Sun a IBM zaplatili lobbisty na prosazování legislativy, MS zase pozval do schvalovacího procesu své partnery, včetně malých firem (BTW alespoň za to nemusel platit).
Jsem zvědavý, kdy se standardizační proces úplně zhroutí, protože firmy jako Sun a IBM přenesly konkurenční boj na pole standardizace. Řekněme že MS zablokuje standardizaci HTML5 a VP9 u ISO, Google pak zablokuje něco dalšího MS, a standardy půjdou do háje jen proto, že si pár blbů vybralo za kolbiště standardizační komisi namísto trhu.
Nakonec IT průmysl už podobnou botu jednou udělal. V devadesátých letech si lidé z Netscepe a Opery začali vyřizovat účty s MS u soudu místo na trhu. Milton Friedman celkem správně poznamenal, že tím IT průmysl pozval vládu a regulaci do oboru IT, a že celý průmysl bude ještě litovat.
http://www.cato.org/sites/cato.org/files/serials/files/policy-report/1999/3/friedman.html
Schvalovaci proces OOXML byl jedna velka saskarna kdyz se ms snazil standardizovat to co mel v office a kdyz mu to neproslo tak jak to bylo tak to roky bojkotoval. Jeste office 2010 ten standard nepodporovali podle ty sileny dokumentace a buh vi jestli sou na tom novejsi lip... Naprosto zbytecnej standard kterej by mel skoncit nekde na smetisti dejin jako velkej omyl.
To je samozřejmě nesmysl. Původní standard byl ECMA-376, schválený v roce 2006. Office 2007 podporovaly přesně tenhle formát. U ISO byla standardizovaná další verze (ISO/IEC 29500) zahrnující připomínky, a to v roce 2008. Asi nečekáte, že Office 2007 bude podporovat formát z roku 2008. Office 2010 podporoval ECMA-376, ISO/IEC 29500 Transitional, a pro čtení ISO/IEC 29500 Strict. Office 2013 podporuje ISO/IEC 29500 Strict. Jinými slovy nikde nevidím žádný problém.
Samozřejmě formát XXOML měl skončit na smetišti dějin, všichni měli používat podřadný OpenOffice s nedovařeným ODF (vzorce jsou popsány slovy "vendor specific", asi jim nikdo mimo výrobce office balíku nemusí rozumět), a státní správu k tomu měla donutit legislativa. Naštěstí Sunu a IBM tenhle plán nevyšel.
BTW všimněte si, že například ty vzorce ve spreadsheetech (plus digitální podpis obsahu a další věci) neměla první ISO verze ODF z roku 2006, neumí je verze 1.1 z roku 2012(!), a verze 1.2, která je konečně zavádí, není standardizovaná dodnes(!). ODF Alliance prostě není schopná dostat ODF standard do použitelné fáze ani po osmi letech. Plus ODF samozřejmě neumožňuje popsat beze ztráty existující Office dokumenty, a podle všeho se to nikdy nenaučí. Ale jinak jsou v ODF Alliance ti správní hoši, kteří by měli všem říkat, v jakém mají psát dokumenty :D
Office 2007 nemohly dost dobře podporovat ISO standard vzešlý z formátů MSO, když došlo ve standardizačním procesu ke změnám. A že Office 2010 neuměl psát ISO OOXML Strict, ale jen Transitional? Mohlo by to jít rychleji, ale podle mě to ničemu nevadí. Důležitá je přece interoperabilita, a tu bohatě zajišťuje i ISO OOXML Transitional. Mimochodem několik schémat najdete i ve specifikaci ODF.
Předpokládám ale, že když OO/LO implementuje font embedding až po sedmi letech po schválení specifikace u ISO (resp. osmi letech po schválení u OASIS), tak je to naprosto v poho. A když se do specifikace ODF dostane tak základní a zásadní věc, jako je popis vzorců ve spreadsheetech, až po šesti letech, a to ještě ne v ISO standardu (tam to možná bude po osmi letech), tak je to taky v poho. BTW když se budete nudit, můžete si v obou případech spočítat verze OOo, OO a LO :)
Takže problém je jenom na straně zákazníka. Kupodivu si myslí, že když si zaplatí za licenci na program, tak mu ten produkt nějakým způsobem kompenzuje náklady. A navíc zcela evidentně nechápe, že 10% té ceny je za implementaci ztráty dat z předchozích vezí a nějak není štond pochopit, že není možnost, jak tuhle vychytávku vyjmout i z faktury, i z aplikací! No co, je to nejslabší článek, tak to příště zkuste bez zákazníka.
Ne, mluvím o M$. Kdysi jsem ty vaše slavný Office používal, ještě ve škole. Po tom, co několikrát nešlo otevřít dokument vytvořený den předem ze stejnýho disku, na který byl uložen při poslední editai, jsem si raděj koupil licenci na "602 Office Suite", nebo jak se to jmenovalo. A ze dne na den bylo po problémech.
By the way, před týdnem jsem něco měnil v jednom asi 12 let starým souboru. Až po jeho editaci jsem si při ukládání všiml, že je ještě z Ooo 1.x - zeptal se totiž, jestli ho chci ponechat, nebo hodit do ODT. U M$ se verze souboru pozná už při otevírání, někdy ještě před otevřením.
Logika říká:
kancelářský balík se používá v kanceláři -> kancelář je pracoviště -> ztráta dat a problémy s ním ovlivní pracovní proces -> stres pro zaměstnance -> zdravotní problémy;
M$ mění formáty dat, UI atd. jak na běžícím pásu -> potřeba dalích nákladů na školení, konverze dat, jejich zálohování, instalace konvertorů formátu atd.
Shrnuto: M$O zaměstnavatel platí 4x - za licenci, za prostoje (školení, údržba), na ušlým zisku a na léčení zaměstnanců. Nabídka je to víc než výhodná.
Pěkný příběh ze školy.
MS Office samozřejmě otevírá staré dokumenty v pohodě, a pokud použijete nějakou funkci kterou stará verze aplikace neumí, tak se vás při uložení zeptá.
MS datové formáty mění celkem zřídka. Já pamatuji formáty DOC/XLS v ANSI verzi, přechod na Unicode verzi těch formátů, a pak přechod na DOCX/XLSX verzi. Konverze dat není nutná, protože funguje zpětná kompatibilita. UI Office se mění minimálně, jedinou výjimkou za pár desítek let je přechod na ribbon. Konvertor formátů je potřeba jen pro starý Office, aby otevřel dokumenty nového Office.
Logika říká, že když máte dokumenty MS Office, a OpenOffice/LibreOffice je není schopný otevřít beze ztrát (i když jsou to důkladně zdokumentované formáty), tak je to nepoužitelné. Navíc je OO/LO funkčně o mnoho let pozadu. I když možná s OO/LO můžeme ušetřit ve státní správě: OO/LO se používá v kanceláři -> kancelář je pracoviště -> nemožnost otevřít staré dokumenty, nekompatibilita se zbytkem světa a slabý výkon aplikací zastaví pracovní proces -> zaměstnanci spáchají sebevraždu -> sníží se počet úředníků -> budou nižší daně :D
Cooooooo ???? Tomuto snad neveria uz asi ani male deti. Tie M$-grcy nevedia otvorit svoje vlastne formaty ani same po sebe, kolega potreboval daco zo svojej phd prace 5 rokov starej, otvoril vsetko zmrvene, rovnice, obrazky ... este stastie, ze mal vygenerovane nejake pdf, prepisovali sme to cez ocr znova - ale uz do Tex-u ... S 10 rokov starym dokumentom (odborny text) v OpenOffice sa da pracovat aj v LibreOffice bez akychkolvek problemov ... najprv si to vyskusaj a potom tu trieskaj wolowiny ....
Ahoj mudrlant a kde v tom tvojom standartizacom procese su fonty? Preco nemozeme fonty calibri distribuovat mimo produkty MS alebo bez instalacie niektoreho z nich. Tu mala zakrocit EU a jednoducho zakazat nonfree fonty v dokumentoch lebo obmedzuju konkurenciu a su hlavny dovod nespolahlivej konverzie dokumentov z formatov MS. Toto je jasne monopolne spravanie a treba ho zastavit.
Embedding fontů je popsaný v kapitole 15.2.11 (Embedded Package Part). Fonty mohou být přiloženéve formě, která vylučuje jejich použití jinde než při rendrování dokumentu; většinou ale nejsou přiložené vůbec. Nicméně vyjma jména fontu obahuje dokument i informace potřebné pro substituci.
Ehm, v čem podle vás spočívá to "monopolne spravanie"? MS si nechal fonty, včetně Calibri, vytvořit od renomovaných designerů. Jde o *velmi* kvalitní práci, a předpokládám, že licenční podmínky MS nedovolují jejich volné šíření. Naopak pokud by EU přikazovala soukromé firmě licenci k fontům, šlo by o zásadní zásah do sféry, která státu nepřísluší.
Co s tím můžete udělat? Totéž co MS. V Adobe si licencovali od Linotype font Times Roman, a použili ho jako Core PostScript font. MS ho pochopitelně nemohl používat. Proto si u Monotype licencoval Times New Roman. Ten má kompatibilní metriku, tzn. stejné proporce znaků, což umožňuje fonty zaměnit. Jsou tam samozřejmě rozdíly (nejviditelnější je lehce odlišné pojetí číslice 5 a písmene z), ale metrika je kompatibilní, a laik si ničeho nevšimne.
BTW jak podle vás licencované fonty omezují konkurenci? Naopak jí prospívají, protože máme více fontů, za které se platí, takže mají autoři kvalitních fontů z čeho žít.
FYI společnost Google vydala free font Carlito, který má metriku kompatibilní s Calibri. Možná nebude dosahovat typografických kvalit Calibri, ale pro daný účel by vám mohl stačit. Podobně je to s ostatními fonty. Alternativně si můžete licencovat nějaké kvalitní fonty s kompatibilní metrikou - jistě se na trhu něco najde.
Normálně, můžu vložit dokument jako sekci (v případě textu) a stane se součástí dokumentu. U vzorce, spreadsheetu, ... to vložím jako objekt a je to. Interně se ODF chová jako zazipovaný adresář, kam se to nakopíruje. Není s tím žádný problém.
Zvěrstva jako schování spreadsheetu pod ikonu jsem nezkoušel, mám z toho kopřivku a doufám, že to M$ vyhodí. Není nad to, když máme interně daný standard pro výrobní dokumentaci - formát pdf a nějaký trdlo vloží do dokumentu ve Wordu spreadsheet jako ikonu, aby si ulehčil práci... :(
Mimoto, AOO/LO mají u objektů jednu krásnou vlastnost. Po kliknutí pravým tlačítkem a výběru "přidat popisek" se objekt vloží do rámce a k tomu popisek jako "Tabulka 2.2 ...". Popisek je tak s objektem napevno svázaný, narozdíl od toho vašeho bastlu, kde je to extra řádek textu a přizměně formátování stránky uletí kdoví kam... A pokud u obrázku v M$O zapnu Obtékání textu, nejde popisek pro sychr vložit vůbec...
Jak jste si mohl všimnout ve threadu diskuse, řeč byla o embeddingu fontů. Ve Wordu můžete při ukládání dokumentu zvolit volbu Embed fonts in the file, takže příjemce uvidí dokument s původními fonty, i pokud je na počítači nemá nainstalované. Pokud jsem vím, v ODF tohle není.
Ohledně popisků: kupodivu :) v MS Wordu kliknete na objekt, pak na kartě References vyberete Insert Caption, a je hotovo. Samozřejmě to lze udělat rychleji přes kontextové menu: vyberete objekt, stisknete menu key (ta klávesa co zobrazí kontextové menu), a pak klávesu N. A mimochodem můžete nastavit AutoCaption při vkládání nových objektů.
V ODF specifikaci je to od verze 1.0 Implementace v LibreOffice je od verze 4.1
https://wiki.documentfoundation.org/ReleaseNotes/4.1
Hezky. Sekci 14.6 specifikace jsem četl, ale nenapadlo mě, že font embedding je popsaný jen v referovaném CSS2. Jinak je pěkné, že se autorům LO podařilo po sedmi letech od vydání specifikace implementovat i tuhle část. Trochu bych se obával, jestli je legální fonty přikládat (MS je z toho důvodu přikládá způsobem který vylučuje jejich použití mimo aplikaci), ale jinak OK.
Ja nevim, co mas porad proti LO. Ja to nikdy nepotreboval. Kdyz chci aby neco vypadalo pekne, nepouziju na to office. LO umi vse co potrebuju a na pouzivani je pro me mnohem prijemnejsi. MS Office treba neumi otevrit dokument ve dvou oknech(dost uzitecne treba pro tabulky s vice listy), nebo dva dokumenty se stejnym jmenem. To jsou moje denodenni problemy.
Je klidně možné, že něco potřebujete právě vy. Nicméně se asi shodneme, že to nemá velkou vypovídací hodnotu.
Excel umí více oken: v Excelu karta View, New Window. Vyjma toho je možné použít free panes (nechat například první řádek stále zobrazený), a rozdělit okno na několik nezávisle scrollujících regionů (View/Split).
Word pokud vím umí otevřít dva soubory stejného jména odjakživa. U Excelu si můžete prostě pustit dvě instance. FYI Excel 2013 spustíte v nové instanci tak, že při spouštění přidržíte stisknutou klávesou Alt.
Jinak typografická kvalita dokumentů MS Office se sice pomalu, ale zato trvale zlepšuje. Publisher je na tom velmi dobře s podporou OpenType, a Word už také podporuje řadu features.
View->new window otevre jenom nove MDI okno, ne desktopove okno, co bych mohl dat na jiny monitor. Regiony mi moc nepomuzou, na dvou monitorech se to proste pouzivat neda. Otevreni dokumentu stejneho jmena pres Alt funguje(diky za tip), ale porad je to takove tezkopadne, protoze ten soubor musim znovu hledat.
Tyhle veci bych ale nemusel resit, kdyby poradne fungovalo sdileni a nesesypalo se to v 9 pripadech z 10.
Priznam se, ze ani s jednim kancelarskym balikem moc neumim, ale na tech par ukonu co obcas musim udelat bych radsi sahnul po LO.
View/New Window mi v Office 2013 otevírá plná okna, která lze umístit na jiný monitor. U MDI aplikací (například Office 2003, pokud si vzpomínám) to můžete udělat leda tak, že aplikaci zvětšíte na oba monitory, a změníte velikost MDI oken.
Soubor samozřejmě nemusíte znovu hledat. Ve Windows Exploreru, ale i v dialogu File/Open a File/Save, můžete použít Alt+D pro přechod na "address bar"; zároveň to cestu vybete (selection). Pak stačí ji přes Ctrl+C zkopírovat, přejít do jiné aplikace, a tam ji obdobně vložit. Vložení lze provést i přes políčko jména souborů (normálně Ctrl+V, ENTER), což se hodí v aplikacích, které používají nějakou prastarou verzi File dialogu bez "address baru".
Další tip je kopírování lokace souboru. Ve Windows Exploreru, ale i v dialogu File/Open a File/Save, vyberete položku, stisknete se shiftem pravou myš a vyberete z kontextového menu Copy as path. Samozřejmě je to rychlejší z klávesnice: položku vybrat a stisknout Shift+<menu key>, A.
A pro inspiraci ještě jeden kousek: můžete přetáhnout z Windows Exploreru soubor nebo adresář na command line; vloží to na command line cestu. Bohužel to z bezpečnostních důvodů nefunguje pokud shell běží v jiném kontextu (typicky pod adminem); pak se používá vkládání cesty z clipboardu.
Když použijete pár podobných triků, dá se v GUI (i v kombinaci GUI-CLI) pracovat velmi efektivně.
Pokud vám LO vyhovuje, nic proti. Nakonec ta nulová cena je příjemná. Pro mě by to ale z mnoha důvodů nefungovalo, a podobně ani pro většinu pokročilých uživatelů MS Office. MS Office mám i na soukromých strojích - je to levné.
Tak styly apod. nejak zvladam, to jsou obecne principy uzitecne vsude. Nejake hotkeys ve windows jsou pro me ale ztrata casu, kdyz 95% casu travim v Linuxu. Za poslednich 10 let jsem ale vse co muselo nejak vypadat psal v TeXu. V Officech delam jenom z donuceni. Kdyz mam proste editovat office dokument, musim pouzit office. Zkratka kdyz mam k necemu odpor, tak se mi to spatne uci.
Trochu ste prekrutil moj prispevok. Ja nikde nespominam embeded fonty. Ja hovorim, ze predvoleny font v MS produkte pouzivanom pre pracu s ooxml je proprietarny co logicky popiera moznost vyuzitia pre otvoreny standard. To, ze si ho MS objednal mna vobec nezaujima, kedze teraz ho jednoducho niesom schopny pouzit v inom OS nez od MS bez instalacie dalsich produktov, cim sa vytvara zavislost a tym padom aj monopol. Tiez ma nezaujima, ze google robi pracu za M$ a uvolnil font s rovnakou metrikov, za co ho M$ asi nepochvali a neprekvapili by ma ani sudne tahanice o jeho obmedzenie. A ako proprietarne fonty obmedzuju konkurenciu. No jednoducho monopolizovanim dokumentu, kedze dokument je v podstate nezobrazitelny v opensource editore napriek tomu, ze pouziva otvoreny standard, co je proti filozofii tychto standardov. EU mala hlavne protestovat proti prednastaveniu calibri fontu v produktoch M$. Zo strany M$ to jeho zavedenim vnimam ako pokus o obmedzovanie opensource konkurencie.
Váš názor mi připadá zvrácený. XML formáty jsou tu proto, aby je mohl kdokoliv číst. Pokud je chcete rendrovat, můžete použít fonty přiložené v dokumentu (pokud tam jsou), nebo použít shodné či podobé fonty. Jak je seženete, to je přece vaše věc.
dokument je v podstate nezobrazitelny v opensource editore - proč? Jak jsem psal, fonty mohou být přiložené v dokumentu. Když tam nejsou, můžete si napsat nebo licencovat vlastní fonty se stejnou metrikou, úplně stejně, jako jste si napsal parser toho OOXML.
O tom vobec nebol moj prispevok. Skusil ste sa aspon zamysliet nad podstatou problemu, ktory som popisoval? Ja sa stazujem na to, ze v MS produkte je ako prednastaveny font proprietarny. Kedze MS dobre vie ze 99.9% ludi su BFU a lenivy si ho zmenit na nejaky iny tak potom dochadza k problemom s konverziou. Embedded font vam pri konverzii nepomoze lebo ho legalne nemozete pouzit. Pouzitie je legalne iba pre zobrazovanie prip. upravu originalu.
Podstata problému je v tom, že fonty obecně nejsou free, protože vyrobit typograficky kvalitní font je dost drahé. Státní správa klidně může interně přikázat používání volně šiřitelných fontů, pokud chce (a pokud na to mají zaměstnanci oči a žaludek). Soukromým osobám to ale asi těžko přikážete.
MS embedded fonty můžete použít, pokud to umíte, protože umožňují Editable Embedding. Určitě je můžete použít, pokud dokumenty OOXML přímo otevíráte, a nejspíš i pokud provádíte konverzi (ale to konzultujte s právníkem, ne se mnou). Jak jsem už psal, licencování fontů je obecně vaše věc. Můžete si je legálně licencovat, nebo použít volně šiřitelné font se stejnou metrikou.
Osobně nevidím žádnou monopolní praktiku v tom, že MS dává v ceně Windows a MS Office kvalitní fonty.
Teď jste si tedy pěkně naběhl! OOXML je tak úžasný standard, že i vlastní různé verze Office od Mrkvochvostu mají problém si jej navzájem přečíst (LOL, LOL, LOL).
Mimochodem, u nás to často funguje tak, že když přijde nějaký nešťastník, že mu nejde novější formát ".doc" oteřít ve starší veri MSOffice, tak mu jej pomocí LibreOffice v klidu otevřeme a zkonvertujeme do formátu ".ods". A je šťastný jak blecha, že nemusí utratit tisíce Kč za nový MS-Office (ani jej ukrást s rizikem nachytání malware) :-D.
To je samozřejmě nesmysl. MS Office má vynikající zpětnou kompatibilitu. Pochopitelně ve starších verzích SW nemůžete otevřít to co bylo napsané v nových. Na to je potřeba konvertor, který se do MS Office dá zdarma doinstalovat. Pokud tohle u vás nevíte, tak to hovoří za vše.
"To je samozřejmě nesmysl. MS Office má vynikající zpětnou kompatibilitu."
Laele, takto lhát můžeš jen lidem, kteří s MS Office nikdy nepracovali. Těch možná mezi čtenáři Roota bude hodně, ale pořád je tu také hodně nás, kteří musí s MS Office dělat alespoň v práci. No a my se tomuto tvrzení můžeme jen trpce zasmát.
A já se mohu vesele zasmát lidem s fiktivními problémy :). Zatím jsem viděl problémy jen pokud cílový počítač neměl stejné fonty jako zdrojový (a fonty nebyly přiloženy v dokumentu), NEBO nějaký expert nastavit layout podle tiskárny (ten se naposledy používal ve Wordu 95), NEBO byl dokument poškozený (lahůdkou jsou DOC dokumenty psané v OpenOffice, ovšem většinou lze provést repair - pokud víte že existuje).
On je spis uplne blbej, si mysli ze mu google pomuze, kdyz tu bude pet slavu na ty M$ sragory, ktery casto neotevrou ani soubor ze stejny verze.
A kdo nekdy oteviral neco v excelu, co melo byt jedinej vzorec ... tak jiste s radosti potvrdi, jak je to uzasnej zazitek, kdyz vam vas zahranicni kolega posle neco, kde sou vzorce ... nemecky nebo kdyz s nim resite, jak ma otevrit ten vas ... kde sou cesky. Tohle muze napadnout jen podobny magory jako delaj u M$.
S tím Excelem je to pěkný argument. Má jedinou chybu: vzorce se zobrazují vždy v jazyce, ve kterém běží Excel (naštěstí se někde na MS webu do českého dají stáhnout anglické názvy funkcí, jinak je to na zabití). Pokud vidíte funkce v jiném jazyce, tak jsou to user-defined funkce, psané ve VBA (a dost možná ta makra v tom souboru ani nemáte). U user-defined funkcí samozřejmě platí, že s jakým jménem si je napíšete, takovým jsou zobrazené.
Pokud kolegovi sedícímu před německým Excelem diktujete po telefonu vzorec, tak mu "kupodivu" české názvy funkcí fungovat nebudou (s výjimkou těch user-defined, pokud jste byl prase a pojmenoval je česky). A "kupovidu" ani nebudou fungovat instrukce jako "now click on Soubor, then Uložit" :D. Většina mezinárodních firem to řeší tak, že má všechen SW v angličtině. Jestli to tak u vás nemáte, tak se budete muset naučit, jak se německy řekne součet. Jistě to bude něco libozvučného, obdoba českého součethodnotzdevýßlovněuvedených :D
S tímhle problém není. Standardní funkce se překládají. Neplatí ovšem pro pluginy, tam se občas najde některý, který má vzájemně nekompatibilní jazykové mutace. Ale to je chyba autora pluginu(ů), respektive příliš agresivního překladatele v kombinaci s "překládáme všechny stringy".
Kde býval problém je nastavení jazykových zvyklostí. Na mém PC jsem měl desetinnou tečku a jako oddělovač záznamu čárku. Na PC mého nadřízeného některé soubory vykazovaly chyby, protože on měl desetinnou čárku a oddělovač záznamů středník. Problém byl s MS Excel 2003 a jen u některých souborů, respektive u některých vzorců. Verze 2010 již tuto chybu nevykazuje.
Soubory si vyměňujeme se zákazníky a dodavateli z celého světa a jediný problém je, když někdo místo tabulky pošle obrázek. To je pak na ránu po tlamě. A pak samozřejmě rozsypaný čaj z Číny, ale to tak asi vypadat má.
Word i Excel 2010 samozřejmě otevře soubory Office 2003. Jděte k Office 2003, založte si ty soubory a otevřete je v Office 2010. Pak sem přijďte zpátky, a sypejte si popel na hlavu.
Pokud vám nejde otevřít jeden konkrétní dokument, tak je nejspíš poškozený (případně jde o nepovedený export z OpenOffice). Při otevírání souboru přes File/Open můžete místo tlačítka Open vybrat Open and Repair.
Ty si spis v tom svym vymletym mozecku vykydej ... protoze tyhle problemy resi miliony lidi dnes a denne. Mam tu tak par tisic xls souboru, ve kterych sou mimo jiny query do databaze ... a dobre polovina z nich je v 2k10 castecne nebo zcela nefunkcni. Pritom velmi casto nekde o zadny vychcanosti - proste jen blba kontyngencni tabulka nad selectem. A presto to nefunguje. Takze neblabol.
Funkcionalita linků do DB záleží na spoustě věcí, včetně DB driverů, DNS atd. Proto za spousty situací ty linky do DB nemusí fungovat ani na jiném stroji se stejnou verzí Excelu. Pokud (a pouze pokud) vyloučíte, že jde o nějaký takový problém, lze mluvit o problému se zpětnou kompatibilitou Excelu.
Mimochodem než budete psát něco dalšího, tak si pod formem přečtěte pravidla pro diskutující, body 1 a 2, a zkuste se jich držet.
Nikdo neudělal nic špatně. Záleží to na nastavení Regional Settings na konkrétním počítači. To samé datum můžete být podle Regional Settings zobrazeno jako "31.12.2013" (CZ), "31/12/2013" (UK), "12/31/2013" (US) apod.
Samozřejmě si můžete nastavit custom format. Doporučuji formát 2013-12-31 (formatting string je yyyy-mm-dd), protože je to podle ISO 8601, píše se to logicky od největší jednotky po nejmenší, a rozumí tomu všichni. U custom formátů pozor, abyste omylem nepoužil jako oddělovač data například desetinný oddělovač, protože na českém počítači můžete snadno dostat 31,12,2013 :). Chce se to kouknout na help.
http://office.microsoft.com/en-001/excel-help/format-a-date-the-way-you-want-HA102809474.aspx
http://office.microsoft.com/en-001/excel-help/create-a-custom-number-format-HP010342372.aspx
Nepisete pravdu. Asi sa ohanate ODF 1.2, ktora ale standardizovana je pod OASIS organizaciou od roku 2011. Ano zatial nie ISO ale po tom co predviedol MS pri OOXML uz ani neverim, ze bude prijaty. Dalej aj ODF 1.0 obsahuje popis zapisu formul avsak vo verzii 1.2 bol prijaty standard, ktory ho rozsiruje a spresnuje. Btw. v case prijatia ODF 1.1 nemal OOXML ziadnu specifikaciu pre formule takze porovnavate hrusky s jablkami.
Proč by přijetí standardu OOXML mělo nějak bránit přijetí další verze standardu ODF? Jediný problém může být v tom že Sun už neexistuje, Oracle coby jeho nástupce o office business nemá zájem, a IBM na to kašle, takže může celé ODF umřít na nezájem zúčastněných.
Ad v case prijatia ODF 1.1 nemal OOXML ziadnu specifikaciu pre formule - co si to vymýšlíte za nesmysly? Mám před sebou původní ECMA-376 z roku 2006, a kapitola 3.17.7 (Predefined Function Definitions) funkce popisuje. FYI ta kapitola je poměrně podrobná, má 283 stran.
A také tu mám OASIS PDF 1.0. Vzorce jsou "popsané" v kapitole 6.7.6 (Formula), a říká se tam pouze následující: The formula should start with a namespace prefix hat indicates the syntax and semantic used within the formula. Vyjma toho je tam ještě vyjmenovaných (bez popisu) deset funkcí pro pivot tables. Jo, to asi chtělo nepatrně upřesnit :D. V OASIS ODF 1.1 je to beze změny (ISO verze nemám).
Az na to se ODF format nevytvara IBM ani oracle ale OASIS, do ktoreho su tieto spolocnosti zapojene ale niesu jedine.
Ohladom standardizacie mam prave obavy, ze kedze uz existuje hyper dokonaly standard ooxml, na ktory si ms neda sahnut, tak uz nebude potrebne pracovat na zdokonalovani ODF. Zatial sa mi moje obavy potvrdzuju ale snad sa len mylim. Ak nie, tak novy ODF uz ako ISO norma nebude.
Co sa tyka formul z roku 2005-2006, tak tie, podla vtedajsich diskusii, boli minimalne problematicke: sourceforge.net/mailarchive/forum.php?thread_name=436F9F71.10506%40dwheeler.com&forum_name=openformula-discuss
OASIS formát ODF nevytváří; OASIS ho standardizuje a připravuje k "opravdové" ISO standardizaci. Má k tomu nejspíš nějakou pracovní skupinu, kterou vedli Sun a IBM, plus je tam někdo podpořil.
Takže záměrem autorů ODF nebylo standardizovat datový formát OpenOffice pro možné použití v jiných aplikacích, ale monopolizovat si office formáty? Moc pěkně.
Ten link je mrtvý, 404.
Standard to neni a nikdy nebyl, neexistuje zadna implementace toho, co si M$ protlacil jako "pseudo standard". Ani jedna verze office NEUMI a nikdy neumela ulozit dokument, ktery by tomu odpovidal.
Navic jak bylo receno vejs, ruzne verze opic jsou vzajemne zcela nesluciltene (a to samo mluvi o ukladani do tohle formatu) a kupodivu... daleko lip si s timhel M$ formatem poradi trebas libre office.
Narozdil od toho, libovolna verze/fork OO (tedy i LO) umi ulozit dokument presne v souladu se standardem open document - staci si to vybrat.
Takze se hosane snazis zbytecne, ale toto je dlouhe roky zdokumentovany stav veci. Navic v pripade open dokumentu se pracuje na standardizaci dalsi verze.
Co to zase vymýšlíte za bludy? Jak jsem už psal, Office 2010 píše ISO OOXML Transitional a umí číst ISO OOXML Strict. Office 2013 píše ISO OOXML Strict.
Přehled verzí MS Office a podpory základních formátů (DOC/XLS, Open XML Transitional, Open XML Strict, ODF 1.1, ODF 1.2, PDF) najdete třeba tady:
http://blogs.office.com/b/office-next/archive/2012/08/13/the-new-office-expands-file-format-options.aspx
Jak už jsem psal, MS Office mají naopak skvělou zpětnou kompatibilitu, a částečnou dopřednou kompatibilitu. Nicméně můžete tvrzení o nekompatibilitě doložit i jinak, než úporným tvrzením. Mám tu Office 2010 a 2013. Zkuste mi říct, jakým způsobem ukázat tu nekompatibilitu. Když jsou ty verze zcela nekompatibilní, jistě nebudete mít větší problém to ukázat.
libovolna verze/fork OO (tedy i LO) umi ulozit dokument presne v souladu se standardem open document - 1. Není to default, takže to nikdo nedělá. 2. Zkuste se podívat na výsledný dokument, vezměte si k tomu specifikaci. Zjistíte že spoustu věcí podle ISO standardu nelze interpretovat (třeba ty vzorce), a navíc OOo píše do dokumentu spoustu věcí, které žádný standard nepopisuje.