[cairo] Clickable links in PDF? Metadata?

[Adrian Johnson]

On 04/07/15 02:07, David Kastrup wrote:
> 
> Hi,
> 
> I'm currently taking a look at the suitability of using Cairo for the
> rendering purposes of GNU LilyPond <URL:http://www.lilypond.org>.
> Hardly surprising, print output is pretty much a priority.
> 
> There are a few loose ends for which I see nothing in the
> documentation.  With regard to PDF production, I cannot find the
> following two items:
> 
> a) clickable links

There have been several requests for this in the past.

> b) document metadata

And this too.

> c) interfacing with the PDF production

I'm not sure what this means.

> 
> While one can write out (sub-)surfaces via a streaming interface, it is
> not clear whether one can assemble a single PDF file from multiple
> surfaces such that resources are only present once, and how one would
> otherwise organize the PDF output such that user-defined elements can be
> spliced in.  If c) was reasonably available and powerful, the other
> points could be implemented as user-defined extensions.

The PDF backend will embed only one copy of a source surface if you use
CAIRO_MIME_TYPE_UNIQUE_ID.

> Even if it seems like overkill to render every item with a clickable
> link in a surface of its own.
> 
> There is also stuff like "attaching files" to a PDF (not as important).
> It may be that this works with the MIME data extensions already.
> 
> Any further information about this stuff?  Present state, plans,
> problems, possible interfaces/APIs, timelines, openness to third-party
> contributions?

The main issue with adding support for non graphical PDF features is
that there is a lot of stuff in section 12, 13, and 14 of ISO32000. How
much of it should we support? It will significantly increase the size of
the API. Those providing cairo bindings don't want to see an explosion
in the size of the API.

There are a couple of possible solutions. One would be to only support a
very limited subset of the document management features. Links and
metadata would fall in this category. The problem is there will always
be someone who wants one more little feature and so the API keeps growing.

Another approach would be provide an API for inserting PDF dictionaries
that can be used by an external library to support most of the document
management features. I have not investigated this concept in sufficient
detail to determine if it is feasible.

The second option has been on my TODO list for about 5 or 6 years but I
never found the the time to progress it. Contributions are welcome since
it is clear I am unlikely complete it. I suggest proposing an API first.

> 
> Oh, it also seems like surface types are hardcoded.  It might make sense
> to let the user define a surface of his/her own by providing hooks for
> _everything_.  For a vector-based format like PDF, this might be
> reasonably straightforward and consequently a somewhat doable way of
> getting a surface able to do everything that is required for a
> particular application.
> 
> Thanks for any pointers/thoughts!
>