Re: issues with \attachment when specifying name

[Pablo Rodriguez <oinos@gmx.es>]

On 2/8/20 1:46 PM, Peter Rolf wrote:
>
> Hi Pablo,
>
> my first thought was: how can you rename something that isn't showing up
> (as text) in the PDF anywhere?
> On a second thought this makes sense, if you want to hide the original
> file name in the PDF code. Shouldn't be to hard to make this work even
> for hidden attachments.

Hi Peter,

I need to do that to rename from something very similar to these ones:

   x:\crap-from-scanner\20200208180001.pdf
   x:\crap-from-scanner\gen-sign-mdf003.pdf

to something more meaningful, such as:

  01-flyer.pdf
  02-booklet.pdf

Or even:

  01-flyer_[SHA512SUM here].pdf
  02-booklet_[SHA512SUM here].pdf

The name key allows to reuse names from somewhere else, and also to
order the files using counters. Both automatically and without having to
mess with the files themselves (https://blog.ousia.tk/0005/ contains an
example).

In that cases, renaming actual files could be both undesirable and a lot
of work.

It is mainly a question of consistency. Also across applications.
Consider the following sample:

    \setupinteraction[state=start]
    \starttext
    \startTEXpage[offset=1em]
    attachment\attachment[file=xml-mkiv.pdf,
        type={application/pdf},
        %~ method=hidden,
        name=01-manual,
        flags=]
    \stopTEXpage
    \stoptext

In Evince, the annotation has the title xml-mkiv (without the
extension), but it opens a 01-manual.pdf document.

Acroread displays the filename fine, but it displays the title
annotation as xml-mkiv.

In both cases, removing the extension to refer to a filename may
introduce further issues (mupdf-gl displays xml-mkiv as author).

With "method=hidden", SumatraPDF displays the filename as xml-mkiv.pdf.

And other PDF viewers might behave differently.

We may complain that PDF viewers are crappy, but ConTeXt is providing
filename info in three different ways (and viewers are taking legitimate
information).

After all, if the name key is there, it should behave properly. It
should ignore values from the file option when the name option is
specified, and it shouldn’t remove the extension when the attachment has
been renamed (this leads to potential user confusion).

> But it can also be argued that this feature gives the user a false sense
> of security. Any attachment with metadata may contain additional
> information that makes the prior name change useless.
> And in the end the author of the document is responsible for it. In my
> opinion renaming a file before embedding it, is acceptable in this
> security context. But maybe I'm wrong here...

I’m not a fan of exposing directories when I have to attach files to
automatically-generated PDF documents.

But the main issue here is functionality for both the one who generates
the document and the one that receives it.

Many thanks for your help,

Pablo
--
http://www.ousia.tk
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________