Open XML SDK uvolněno pod licencí Apache 2.0 (diskuse)

[gsnak]

It's a trap!

[Peter Fodrek]

Nejak prehane rychla reakcia na spravu europskej komisie

Open source hindered by OOXML incompatibilities Submitted by Gijs Hillenius on June 23, 2014

The mixing of outdated and incompatible versions of OOXML, an XML document format, is hindering implementation in open source office alternatives, according to a study published on the Open Source Observatory and Repository (OSOR) today.

The study quotes several leading developers involved in Apache OpenOffice and Libre Office, two well-known open source office suite alternatives. For example, Svante Schubert, one of the veteran engineers from OpenOffice who is working on the interoperability of office suites, says: "You can develop an OOXML-compliant implementation, covering all the mandatory OOXML features, but this implementation will very likely not be compatible with the majority of the OOXML documents that are out there." https://joinup.ec.europa.eu/community/osor/news/open-source-hindered-ooxml-incompatibilities

To totiz zavana, ze by EU mohla OOXML zakazat ako format v EU, keby to MS neurobil

OSOR je totiz projektom DIGITu

Európska komisia GRS Generálne riaditeľstvo pre informatiku (DIGIT) http://ec.europa.eu/dgs/informatics/contact/index_sk.htm

Directorate-General for Informatics (DIGIT) http://ec.europa.eu/dgs/informatics/contact/index_en.htm

dgs- su nieco ako ministerstva EU

joinup, ktory to napisal je web DIGIT pre projhekty OSOR, SEMIC a ePractice..

[xvasek]

Bylo by dobré balíkům, které neumí zpracovat korektně formátovné OOXML, nějakým způsobem odebrat možnost honosit se tím, že formát jimi produkovaných / zpracovávaných dat je otevřený. Tím by počet OOXML (a věřím, že i ODF) komaptibilních balíků klesnul na nulu a my bychom přišli na to, že vlastně potřebujeme úplně jiný a mnohem jednodušší standard. Celé by se to restartovalo a třeba by vznikl formát dokumentu, který nevyžaduje k rozumné implementaci tým desítek lidí na několik let. No krásný sen...

[Peter Fodrek]

ono by hlavne nebol potrebny stanadrd

ISO/IEC TR 29166:2011 Information technology -- Document description and processing languages -- Guidelines for translation between ISO/IEC 26300 and ISO/IEC 29500 document formats

Edition: 1 (Monolingual) ICS: 35.240.30; 35.060 Status: Published Stage: 60.60 (2011-12-07) TC/SC: ISO/IEC JTC 1/SC 34 Number of Pages: 156 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=45245

Mat ISO stanadrd na vzajomnu konverziu ODF a OOXML je ozaj luxus.

[chrono]

To, či je niečo kompatibilné záleží od toho, čo myslíš tým spracovávaním. Ak len prevod OOXML/ODF dokumentu na nejakú interpretáciu v pamäti, tak to tak zlé zase nebude. Ak do toho zahŕňaš aj následné zobrazovanie, tak to už môže byť problém (a tam nijako nepomôže ani Open XML SDK).

[potato]

Formát doumentu je jednoduchá záležitost.

OOXML nepředepisuje jednoznačný algoritmus, jak dokument pixel-perfect vyrenderovat (a to ani když by všecha ta bílá místa ve specifikaci byla zaplněna). Takže ho různé implementace mohou platně vyrenderovat různě -- a někdy mohou stačit drobné odchylky v hintingu, aby se všechno posunulo.

Neznám žádný rozšířený systém (rozšířenost je zapotřebí, aby bylo renderování skutečně vystaveno široké škále podmínek), který by současně

(a) měl více nezávislých implementací

(b) umožňoval komplexní editovatelné dokumenty

(c) renderoval vždy všechno stejně.

Dvě z těch podmínek lze splnit (za příčetných předpokladů) snadno:

a+b = ODT, OOXML, DocBook, ... nebo klidně i HTML

a+c = PostScript, PDF, ...

b+c = TeX, ...

Splnění všech tří podmínek je samozřejmě možné. Ale cenou za to je, že výsledek je jednak velmi dobře navržený a specifikovaný (spousta práce) a druhak zcela stabilní. Druhá vlastnost je vážnou překážkou prosazení v praxi, protože potírá diferenciaci implementací, vydávání nových ‚lepších‘ verzí, etc. Takže případ a+b+c skončí v nejlepším případě jako b+c, tedy TeX, s jedinou relevantní implementací, která pak de facto formát definuje namísto formálního standardu.

[j]

Otazka je, jestli nekdo a+b+c potrebuje. Predevsim podminka c je podle me zcela nesmyslna. Na to abych si dokument precet opravdu nepotrebuju aby byl na pixel stejny jako u tvurce. Je samozrejme vhodne, aby se totalne nerozpad. Pokud potrebuju dokument u cile tisknout (a tudiz potrebuju to c) tak je mi zase jedno, ze je obecne trebas needitovatelny ...

Proste mi to prijde, jako ze se vymejsli lopata, kterou pujde hazet pisek i voda stejne dobre.

[Erbureth]

Pokud se v dokumentu něco špatně posune, tak to může vést k jeho totální nečitelnosti.

[:::]

Pokud posunuti neceho muze zpusobit "totalni necitelnost" tak je v tom formatu/kreslicim algoritmu neco velice spatne navrzene...

[victor8]

Ono uplne staci, ze tetuska na urade ktora vyrastala na pisacich strojoch spravi formular vo worde, ktory poodsadzuje medzerami...

Staci odchylka 1px v nejakom znaku, a z celeho formulara je... vieme co.

[Pavel Stárek]

Nemusí být. Ale stačí se jen podívat na různé konfigurace fontconfigu napříč distribucemi, různé verze freetype (ta úplně free s nezepnutými patentovanými technologiemi, pak ta se zapnutými a pak třeba verze s infinality patchem) - každá z nich "kreslí" jinak. A pak opravdu stačí že se něco "nakreslí" o pixel vedle a tím se to celé rozes..re. Ale může nás uklidnit, že to samé se děje i ve světě Windows napříč různými verzemi MSO a MS Windows.

A jak tu někdo poznamenával, že PDF by mohlo zabezpečit stejné vykreslení mezi platformami, tak ani to nebývá pravda. Pokud se do PDFka nevloží například písma, která byla použita při tvorbě výstupu, tak se na cílovém stroji použije nějaké náhradní písmo a rozsype se to rovněž.

[xvasek]

a+b+c potřebujeme, tečka. Mohla by se do toho vložit EU a vymyslet nějaký jednoduchý euxml standard, který by vyžadovala dodržovat pro lokálně prodávané balíky, když už tady máme ten socialismus.