Add link tags for pdfs

[mcfedr]

Interested to see if people think this is a reasonable implementation.

I went with as simple as possible based off https://www.cairographics.org/manual/cairo-Tags-and-Links.html#link

I know its not standard api, but there isn't one for this in canvas, and as was mentioned in the linked issue the project should be open to such an addition.

Fixes #2044

• Have you updated CHANGELOG.md?

[zbjornson]

This is sort of like addHitRegion() (RIP) or the proposed HitRegionSet (whatwg/html#3407).

If we add a non-standard API (generally avoided), we should make sure it covers all foreseeable use cases to avoid having to add another non-standard API in the future. In this case, we might want to (prepare to) expose the full Cairo API for tags (i.e. support specifying an array of rects as the hit region).

+0 from me.

[mcfedr]

This is sort of like addHitRegion() (RIP) or the proposed HitRegionSet (whatwg/html#3407).

These proposals seem to mostly be dead or nearly dead, I think the best thing would just to avoid being close to them in any naming

If we add a non-standard API (generally avoided), we should make sure it covers all foreseeable use cases to avoid having to add another non-standard API in the future

I agree, I think would be good to be able to support the different tag types that cairo can support.

cairo_tag_begin

I see a couple of options

• api like in cairo, that takes two strings, tag_name and attributes - then this simple use case is a bit harder, as the user has to provide the tag name 'Link' and the uri=... attributes

• provide some sort of conversion of the attributes from an object into the format expected by cairo, this would be more work now

• maybe we assume that second param can be an object in the future, but for now take a string, and assume that its a uri

• if we want the use to provide the tag name, i.e. "Link" do we want to expose the const CAIRO_TAG_LINK as a const on Context2d - but that would be more non-standard API surface.

I've be very happy to adjust this implementation to something that can work along these lines

[mcfedr]

@zbjornson I've made some changes to make it simple for this API to be extended in the future.

I've kept only support for Link with uri, and leave it as a task for someone who needs it to add support for more types, but with the object based config for tag, this should be simple to do.

I've also added escaping and check for ascii.

[mcfedr]

@chearon would you review this?

[chearon]

Yes, sorry for the long wait. I finally found time today to read the Cairo documentation and the PDF specs. I agree with @zbjornson that we should plan for all of the abilities that PDF structure gives us, so the current changes are in the right direction.

However, I think we should do a thin abstraction here. It's ever-so-slightly more performant not to have users put things into JS objects, only to serialize it and have Cairo deserialize it again. It will also make the implementation dead simple. It's less ergonomic when you're specifying rects or destinations, but those uses should both be pretty rare. We should be reporting CAIRO_STATUS_TAG_ERROR at some point, which helps.

So the API would look more like:

ctx.beginTag("Link"); // or "Link", "rect=[0, 0, 100, 10] uri='https://cairographics.org'"
ctx.fillText("Cairo!", 0, 0);
ctx.endTag();

And if you want to define PDF structure:

ctx.beginTag("H1");
ctx.fillText("Cairo!", 0, 0);
ctx.endTag();

I don't mind being so tied to Cairo because if we were to switch it out (which will probably never happen) there would be other breaking changes anyways.

Thoughts?