2009/9/29 Bob Jamison <ishmalius@...400...>:
On 9/29/2009 1:00 AM, Jon A. Cruz wrote:
Hi,
Just wanted to point out that technically URI classes are not usable for our assets.
For example, it is tempting to use an URI to resolve an asset to the base document path. The problem is that a URI according to the RFC's is not usable for file paths. Glib and friends properly implement URI, therefore we can't use them for files.
We can, and in fact we must in order to support editing directly on network shares (GIO). The convention used by absolutely everyone is to use the file:/// scheme for local files.
In the future we can probably use IRI's or our own classes for references and assets, etc. However URI's are not usable.
The only difference between URIs and IRIs is the set of allowed characters. You can use Unicode characters in IRIs without escaping them, but you can use Unicode characters in URIs as well, you just need to escape their UTF-8 representation with %xx. http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier
But I'm kinda pro URIs. Yes, the URI API as stated in the W3C doc does not have a getNativePath() method as far as I know. However, Java's runtime, XML2, and other libs -do- include such a call, and it is quite useful. I think it has become a defacto requirement.
Seconded. URIs might not be originally intended for file paths but it is a de-facto standard to use the file:/// URI scheme for local paths. It is even used in the clipboard in GTK.
The case that you mention, an asset pointing back to the owner doc. Is that feasible, or even promised anywhere?
SVG provides mechanisms to embed the necessary data (e.g. images) in the SVG itself, so I don't see why we need this.
And when you JAR the directory into an archive, the META-INF directory and manifest are already ready to go.
This is something we needed for collaboration, too.
Multipage as well. But we should also fix embedding data in SVG (the data URI). For example, pasted and imported images should be embedded in the document by default. There must be a separate option to embed a link to the image, and there must be a clear distinction between those two concepts.
Regards, Krzysztof