[NTG-context] Using \pdfnames and friends.

Paul Isambert zappathustra at free.fr
Tue Jan 25 21:32:16 CET 2011

Le 25/01/2011 17:26, Hans Hagen a écrit :
> On 25-1-2011 2:35, Paul Isambert wrote:
>> Answering myself: I should use:
>> \ctxlua{lpdf.addtonames("EmbeddedFiles", lpdf.reference(22))
>> \ctxlua{lpdf.addtocatalog("PageMode", lpdf.constant("UseOutlines"))}
>> (Apparently I can't do that directly with \pdfbackendsetname/catalog,
>> the second argument is taken as a string.)
>> I hope that's the correct answer and not a hack.
> There are mechanisms for embedding files, like
>   backends.codeinjections.embedfile(filename)
> However, a nametree is not constructed (as with forms these are not 
> mandate, but with forms they are better be there due to 
> initialization). Anyhow, I added this now:
> local function flushembeddedfiles()
>     if next(filestreams) then
>         local e = pdfarray()
>         for name, reference in next, filestreams do
>             if reference then
>                 e[#e+1] = pdfstring(name)
>                 e[#e+1] = reference -- already a reference
>             else
>                 -- we can issue a message
>             end
>         end
> lpdf.addtonames("EmbeddedFiles",pdfreference(pdfflushobject(pdfdictionary{ 
> Names = e })))
>     end
> end
> lpdf.registerdocumentfinalizer(flushembeddedfiles,"embeddedfiles")
> As with most of these things, it's best to use the interface and not 
> push things in the file directly as it might render existing 
> functionality ineffective. Examples are color related resources.
> In a similar fashion Pagemode is not to be set directly. There is
>   \setupinteractionscreen
> for this (with a low level lua setupcanvas variant). As some of the 
> parameters influence each other they are dealt with at another moment. 
> Also, some of the parameters are ignored or overloaded when a chosen 
> pdf/x standard has rules that concern them.

Thank you very much for your answers, Luigi, Aditya, and Hans.

Actually, I'm finishing up a package with PDF support. As usual, I 
wanted it to work with all formats. I suspected it wouldn't be very 
interesting for ConTeXt, since you probably have all you need, but I 
thought if it works for plain it'll work for ConTeXt. I also suspected 
conflicts might arise, though, and what Hans says convinces me I'd 
better drop support for ConTeXt, because at best it'll just add an 
interface on top of the existing one, and at worst it'll break things up 
(not to mention the extra coding for me). I'll provide the wrapper file 
for ConTeXt anyway, because who knows, but I won't make any special 
effort nor cause trouble.

Thanks again,

More information about the ntg-context mailing list