[cairo] [PATCH] Enable links to image files in SVG backend

[Alexander Shulgin]

On Wed, Jan 20, 2010 at 22:34, Bill Spitzak <spitzak at gmail.com> wrote:
> I think the api should take a raw filename/uri with no encoding.

Then this means that SVG backend must always apply the %-encoding to
produce valid SVG output.  Now consider URI like this:

get_image?name=r%26b&size=100px

which is intended to be correctly parsed to a request with two
parameters: name="r&b" and size="100px".  If the client code doesn't
encode that '&' in "r&b" there's no way for it to generated the needed
request.  And if we blindly apply %-encoding to this URI, we'll break
it.

So we either need two MIME types: one for encoded URIs and the other
for raw ones, or we can only accept valid URIs.  With use of glib (or
ruby's URI.escape, etc.) this might be a non-problem, but do we really
need to force this on the client side?  I dunno.

I'm inclined towards having two types for another reason: we might use
CAIRO_MIME_TYPE_FILENAME for some future backends, whereas
CAIRO_MIME_TYPE_URI might be only needed by SVG backend.  We can also
consider only using CAIRO_MIME_TYPE_URI for SVG and don't look at
FILENAME in this backend at all.

> Reasons for
> this:
>
> 1. There might be other backends that do not want %-encoding. They may need
> a different encoding to put the filename in the result, and they sure don't
> want to decode it and reencode it! In particular they may want to physically
> open the source file and do something with it, such as attach it in a
> zip-encoded result. It would be a total pain to have to use a different api
> for this.

Yes, this is where CAIRO_MIME_TYPE_FILENAME fits nicely.  Just don't
look at CAIRO_MIME_TYPE_URI in your backend and document that you only
accept filenames.

> 2. The producers certainly do not want to have to %-encode the filename
> (though I suspect this is why you have two different apis).

I don't know what do you mean by "producers", but hopefully this is
answered elsewhere in my reply.

> 3. One of the two mime names chosen is suddenly impossible to set directly
> as the backend always converts it to the other.

What is "the backend"?  And why it ever needs to convert one to the other?

As it goes for currently proposed patch, the SVG backend prefers
client-encoded URI over raw filename, it never converts one to the
other.  And I doubt anyone can _usefully_ add both URI and filename
metadata to a single surface.

> I don't think you have put
> that name into the mime standard as "this name can never be used". So you
> are violating the standard.

I can hardly understand this.  We're kinda abusing MIME types for the
task, but I don't think it can be qualified as standard violation.

> 4. No part of the cairo api guarantees that the text being sent in the
> encoded api is actually legal.

Yep, but is there a problem?  We explicitly delegate responsibility
for correctness checks to the client code in this case.

> 5. Some backends can store % not followed by a hex digit unchanged. But
> callers can never take advantage of this.

No problem, just don't store it in CAIRO_MIME_TYPE_URI and you're
perfectly safe.

--
Regards,
Alex