issues with \attachment when specifying name
Hi Peter, here you have a minimal sample with file name changed inside the attachment command: \setupinteraction[state=start] \starttext an attachment\attachment[file=secret-name.pdf, type={application/pdf}, %~ method=hidden, name=other-name] \stoptext If method is hidden (no annotation), /EmbeddedFiles doesn’t honor the "name" option. If method is normal (generating an annotation), /T in /FileAttachment doesn’t "honor the "name" option. Would it be possible that both cases contain the value from the name "option" instead of file? Many thanks for checking this, Pablo -- http://www.ousia.tk
Am 08.02.2020 um 09:31 schrieb Pablo Rodriguez:
Hi Peter,
here you have a minimal sample with file name changed inside the attachment command:
\setupinteraction[state=start] \starttext an attachment\attachment[file=secret-name.pdf, type={application/pdf}, %~ method=hidden, name=other-name] \stoptext
If method is hidden (no annotation), /EmbeddedFiles doesn’t honor the "name" option.
If method is normal (generating an annotation), /T in /FileAttachment doesn’t "honor the "name" option.
Would it be possible that both cases contain the value from the name "option" instead of file?
Many thanks for checking this,
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 ___________________________________________________________________________________
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. 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... Peter
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
participants (2)
-
Pablo Rodriguez -
Peter Rolf