5 ms·

> Last summer, Adobe killed their image exchange format "FXG". Edit: previously I had balked at this claim, but I'm wrong. While I can't find any official noti

> Last summer, Adobe killed their image exchange format "FXG". Edit: previously I had balked at this claim, but I'm wrong. While I can't find any official notice of its death, and it's still in use in Scene7 and somewhat supported in the open-sourced version of Flex, trawling message boards does indicate Adobe shying away from it in favor of SVG[1][2] and it's not supported in CS6 without an extension. Still, his problem with FXG (or a format like it) seems superficial. Yes, FXG defines links to other assets instead of combining them into one file, but to me, that's a feature, not a problem: I can them programmatically swap out assets easily by just manipulating the references within the file. It makes it really useful for generating customized assets on demand. In practice, it's like HTML for layered documents. We don't complain that HTML is broken because it links to images instead of including them, do we? If you don't like that you have to send a folder: zip it up and give it a custom extension if need be, a la browser extensions and Microsoft Office formats. [1]: http://mail-archives.apache.org/mod_mbox/flex-dev/201303.mbox/%3cCD676E04.4F26E%25aharui@adobe.com%3e http://mail-archives.apache.org/mod_mbox/flex-dev/201303.mbo... [2]: http://mail-archives.apache.org/mod_mbox/flex-dev/201303.mbox/%3cCD677E4B.4F299%25aharui@adobe.com%3e http://mail-archives.apache.org/mod_mbox/flex-dev/201303.mbo...

eridius 13y ago
We also don't typically use HTML as an interchange format between editors.
- eli 13y ago
  But that's because HTML has complicated and ambiguous rendering rules, not because everyone hates structured, human-readable index documents.
- itafroma 13y ago
  At its core, a layered document is a set of declarations about the constituent parts the document is made up. They link to other objects, like images and fonts. Whether you include everything the document links to into one container or let them hang out in a folder, it doesn't change how layered files are created or interacted with within editors or elsewhere. So to transmit web pages? Sure, we use HTML as an interchange format. You receive everything about the page to manipulate it, including the locations to where the images and other related files are. In other words, a layered document is not the same in kind as a JPEG or a GIF, which are flattened images. You need to be able to manipulate a layered document in the same way you could manipulate a Word document or an HTML file. Whether you use a plain text format like XML or a SQLite database, the end result is going to be the same: in a SQLite database, you could place the component images/fonts into the database as blobs, just as you could technically place the component images/fonts in an XML file as data URIs. But at least with XML, it's editable as plain text and doesn't require the component assets to be transmitted with the layout-defining file. I much prefer that over a format that dictates everything must be encapsulated within.
- justincormack 13y ago
  Well ePub is a zip file of HTML documents. So some people do.
  - eridius 13y ago
    Not really. Not only is EPUB not what I would consider an editor interchange document, but the HTML isn't even the format used for the "core" document file. An XML file with the .opf extension is the "core" file that describes how the EPUB works, and the HTML files are actually just content, analogous to the layer data in Gus's sqlite.
tjoff 13y ago
"We don't complain that HTML is broken because it links to images instead of including them, do we?" Actually, we do. Saving a webpage and getting tons of file is a nightmare while the IE approach of lumping them all together is just so sensible it's hard to imagine a universe where this isn't standard. Replacing resources is the special case. Sharing, moving or just storing an image isn't. Just get or write a tool that can replace the resources for you and you have completely satisfied the 0.001% as well.
- itafroma 13y ago
  Truth be told, you're the first person I've seen ever argue that HTML is a broken file format, particularly because it doesn't contain everything it links to. Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem. As I and others have mentioned throughout the comments here, the single index file—be it XML like FXG, HTML, or otherwise—and linking to assets within it is pretty common and standard approach to complex documents. Combining them by zipping them up is a trivial addition and, again, common way to solve the "but I don't like having multiple files to transfer" problem.
  - tjoff 13y ago
    "Combining them by zipping them up is a trivial addition..." That, seriously, 99% of the population will never, ever, accomplish in their entire lifetime. Instead, you get files without the resources. Instead, you get files with hard coded local links to C:\xxx. This of course works for HTML since most "regular people" never ever has to deal with either html files or its resources (but every time they do, it is sure to be a disaster). Images on the other hand is something that most people deal with in some way or another. It must be something that you can easily share or it will be pointless. It would be nice if you could actually add a caption to an image - without having to "destroy" the original by converting it to a png just so that you'd be sure that the recipient could handle it. Everything has its place. Resources work fine for html files if you are the creator, if you want to store a page for later use it is a disaster. I love the fact that the resources are separate from the document when I write use InDesign or LateX - such a relief from having to deal with word documents etc. At the same time those solutions make it completely inaccessible to most people I know, they are great for their isolated environment but disastrous for anything else. So, an image with resources... Might work well, terrific even, in your studio but if it is ever going to be used by the masses it is a dealbreaker. What if PDF only used linked resources, no one would even know what PDF was by now if that were the case. "Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem." You could of course do all that with single encapsulated file as well...

eridius 13y ago

We also don't typically use HTML as an interchange format between editors.

eli 13y ago
But that's because HTML has complicated and ambiguous rendering rules, not because everyone hates structured, human-readable index documents.
itafroma 13y ago
At its core, a layered document is a set of declarations about the constituent parts the document is made up. They link to other objects, like images and fonts. Whether you include everything the document links to into one container or let them hang out in a folder, it doesn't change how layered files are created or interacted with within editors or elsewhere. So to transmit web pages? Sure, we use HTML as an interchange format. You receive everything about the page to manipulate it, including the locations to where the images and other related files are. In other words, a layered document is not the same in kind as a JPEG or a GIF, which are flattened images. You need to be able to manipulate a layered document in the same way you could manipulate a Word document or an HTML file. Whether you use a plain text format like XML or a SQLite database, the end result is going to be the same: in a SQLite database, you could place the component images/fonts into the database as blobs, just as you could technically place the component images/fonts in an XML file as data URIs. But at least with XML, it's editable as plain text and doesn't require the component assets to be transmitted with the layout-defining file. I much prefer that over a format that dictates everything must be encapsulated within.
justincormack 13y ago
Well ePub is a zip file of HTML documents. So some people do.
- eridius 13y ago
  Not really. Not only is EPUB not what I would consider an editor interchange document, but the HTML isn't even the format used for the "core" document file. An XML file with the .opf extension is the "core" file that describes how the EPUB works, and the HTML files are actually just content, analogous to the layer data in Gus's sqlite.

tjoff 13y ago

"We don't complain that HTML is broken because it links to images instead of including them, do we?" Actually, we do. Saving a webpage and getting tons of file is a nightmare while the IE approach of lumping them all together is just so sensible it's hard to imagine a universe where this isn't standard. Replacing resources is the special case. Sharing, moving or just storing an image isn't. Just get or write a tool that can replace the resources for you and you have completely satisfied the 0.001% as well.

itafroma 13y ago
Truth be told, you're the first person I've seen ever argue that HTML is a broken file format, particularly because it doesn't contain everything it links to. Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem. As I and others have mentioned throughout the comments here, the single index file—be it XML like FXG, HTML, or otherwise—and linking to assets within it is pretty common and standard approach to complex documents. Combining them by zipping them up is a trivial addition and, again, common way to solve the "but I don't like having multiple files to transfer" problem.
- tjoff 13y ago
  "Combining them by zipping them up is a trivial addition..." That, seriously, 99% of the population will never, ever, accomplish in their entire lifetime. Instead, you get files without the resources. Instead, you get files with hard coded local links to C:\xxx. This of course works for HTML since most "regular people" never ever has to deal with either html files or its resources (but every time they do, it is sure to be a disaster). Images on the other hand is something that most people deal with in some way or another. It must be something that you can easily share or it will be pointless. It would be nice if you could actually add a caption to an image - without having to "destroy" the original by converting it to a png just so that you'd be sure that the recipient could handle it. Everything has its place. Resources work fine for html files if you are the creator, if you want to store a page for later use it is a disaster. I love the fact that the resources are separate from the document when I write use InDesign or LateX - such a relief from having to deal with word documents etc. At the same time those solutions make it completely inaccessible to most people I know, they are great for their isolated environment but disastrous for anything else. So, an image with resources... Might work well, terrific even, in your studio but if it is ever going to be used by the masses it is a dealbreaker. What if PDF only used linked resources, no one would even know what PDF was by now if that were the case. "Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem." You could of course do all that with single encapsulated file as well...