5 ms·

If you're going to propose an standard for graphs and figures, please make it SVG. It's hard to find tools for editing PDF that would support text and graphics,

If you're going to propose an standard for graphs and figures, please make it SVG. It's hard to find tools for editing PDF that would support text and graphics, and PowerPoint exists only as a proprietary closed format.

emodendroket 9y ago
False. http://www.ecma-international.org/publications/standards/Ecma-376.htm http://www.ecma-international.org/publications/standards/Ecm...
- TuringTest 9y ago
  What does that link intend to prove? The Office Open XML standard relies heavily on hidden implementation details of the Microsoft Office software suite.
  - emodendroket 9y ago
    "The specification is inadequate to imitate Office" is a different claim from "it only exists as a proprietary, closed format."
    - TuringTest 9y ago
      From what I've heard, the MS Office applications do not even entirely comply with the published specification. So OOXML is still not a definition of the format with which PowerPoint stores its files.
      - emodendroket 9y ago
        So they're just like every other standard on the Web, basically.
        TuringTest 9y ago
        Other standards, and web standards in particular, tend to have several open source implementations to guarantee that it's possible to build tools that support it without being the reference implementation. OOXML has no such thing, and the reference implementation is closed source, so it's basically impossible to replicate in any practical sense.
        emodendroket 9y ago
        There aren't several implementations of Office Open XML formats in open source projects? I don't think that's accurate.
        TuringTest 9y ago
        Not fully compatible with PowerPoint, no. That's why I said the PowerPoint format is proprietary; it's impossible to build a working interoperable tool, because either parts of its format remain secret and do not follow the published standard, or the format itself makes references to hidden implementation details.
        emodendroket 9y ago
        For most purposes I think that's basically academic.
        TuringTest 9y ago
        Having an open source tool that can open files created on PowerPoint without them becoming horribly mangled, or vice versa, is a very realistic concern. Microsoft Office is well known for being extremely difficult to make its file formats portable beyond the very basic layout features.
      - nobodyorother 9y ago
        The spec isn't actually self-consistent, so it's not clear that it can ever actually be implemented: http://www.groklaw.net/article.php?story=20080328090328998 http://www.groklaw.net/article.php?story=20080328090328998 http://www.consortiuminfo.org/standardsblog/article.php?story=20070117145745854 http://www.consortiuminfo.org/standardsblog/article.php?stor...
        emodendroket 9y ago
        Your source claims the spec contradicts previous adapted ISO standards, not that it contradicts itself (which is what I assume you mean by it not being self-consistent). It does, however, raise the issue of bits like legacy compatibility for Word 97 behavior and scripts not being documented.
        nobodyorother 9y ago
        Well, no, it is self-inconsistent in places [0]. However, as you mention, those are probably minor points compared to how it contradicts existing standards, like the Gregorian calendar [1], date representation, and language codes. 0: http://www.groklaw.net/articlebasic.php?story=20070123071154671#Internal_inconsistencies:_the_w:sz_element http://www.groklaw.net/articlebasic.php?story=20070123071154... 1: http://www.groklaw.net/articlebasic.php?story=20070123071154671#Ecma_376_contradicts_numerous_international_standards http://www.groklaw.net/articlebasic.php?story=20070123071154...
        emodendroket 9y ago
        Those are annoyances and give increased complexity. They are not, as you described earlier, inconsistencies that make the spec impossible to implement.
convolvatron 9y ago
unfortunately, since svg is a web standard, it can reference external objects that severely limits its adoption with people that spend all their days defending the idea of 'attack surface'. so google draw uses svg, and exports svg, but won't import svg. github won't inline svgs in md, etc i don't personally like the svg design, its got a lot of weird corners and has the usual screwy relationship with the DOM. but having a fully neutral vector format would be such a massive win, by all means svgs if you can get it more widely adopted...maybe some sort of sanitized/sandboxed svg subset. postscript should have been that format, but they were so focussed on driving rasterization that they made any kind of other interpretation (i.e. editing) impossible.

emodendroket 9y ago

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

TuringTest 9y ago
What does that link intend to prove? The Office Open XML standard relies heavily on hidden implementation details of the Microsoft Office software suite.
- emodendroket 9y ago
  "The specification is inadequate to imitate Office" is a different claim from "it only exists as a proprietary, closed format."
  - TuringTest 9y ago
    From what I've heard, the MS Office applications do not even entirely comply with the published specification. So OOXML is still not a definition of the format with which PowerPoint stores its files.
    - emodendroket 9y ago
      So they're just like every other standard on the Web, basically.
      - TuringTest 9y ago
        Other standards, and web standards in particular, tend to have several open source implementations to guarantee that it's possible to build tools that support it without being the reference implementation. OOXML has no such thing, and the reference implementation is closed source, so it's basically impossible to replicate in any practical sense.
        emodendroket 9y ago
        There aren't several implementations of Office Open XML formats in open source projects? I don't think that's accurate.
        TuringTest 9y ago
        Not fully compatible with PowerPoint, no. That's why I said the PowerPoint format is proprietary; it's impossible to build a working interoperable tool, because either parts of its format remain secret and do not follow the published standard, or the format itself makes references to hidden implementation details.
        emodendroket 9y ago
        For most purposes I think that's basically academic.
        TuringTest 9y ago
        Having an open source tool that can open files created on PowerPoint without them becoming horribly mangled, or vice versa, is a very realistic concern. Microsoft Office is well known for being extremely difficult to make its file formats portable beyond the very basic layout features.
    - nobodyorother 9y ago
      The spec isn't actually self-consistent, so it's not clear that it can ever actually be implemented: http://www.groklaw.net/article.php?story=20080328090328998 http://www.groklaw.net/article.php?story=20080328090328998 http://www.consortiuminfo.org/standardsblog/article.php?story=20070117145745854 http://www.consortiuminfo.org/standardsblog/article.php?stor...
      - emodendroket 9y ago
        Your source claims the spec contradicts previous adapted ISO standards, not that it contradicts itself (which is what I assume you mean by it not being self-consistent). It does, however, raise the issue of bits like legacy compatibility for Word 97 behavior and scripts not being documented.
        nobodyorother 9y ago
        Well, no, it is self-inconsistent in places [0]. However, as you mention, those are probably minor points compared to how it contradicts existing standards, like the Gregorian calendar [1], date representation, and language codes. 0: http://www.groklaw.net/articlebasic.php?story=20070123071154671#Internal_inconsistencies:_the_w:sz_element http://www.groklaw.net/articlebasic.php?story=20070123071154... 1: http://www.groklaw.net/articlebasic.php?story=20070123071154671#Ecma_376_contradicts_numerous_international_standards http://www.groklaw.net/articlebasic.php?story=20070123071154...
        emodendroket 9y ago
        Those are annoyances and give increased complexity. They are not, as you described earlier, inconsistencies that make the spec impossible to implement.

convolvatron 9y ago

unfortunately, since svg is a web standard, it can reference external objects that severely limits its adoption with people that spend all their days defending the idea of 'attack surface'. so google draw uses svg, and exports svg, but won't import svg. github won't inline svgs in md, etc i don't personally like the svg design, its got a lot of weird corners and has the usual screwy relationship with the DOM. but having a fully neutral vector format would be such a massive win, by all means svgs if you can get it more widely adopted...maybe some sort of sanitized/sandboxed svg subset. postscript should have been that format, but they were so focussed on driving rasterization that they made any kind of other interpretation (i.e. editing) impossible.