* issues with \attachment when specifying name @ 2020-02-08 8:31 Pablo Rodriguez 2020-02-08 12:46 ` Peter Rolf 0 siblings, 1 reply; 3+ messages in thread From: Pablo Rodriguez @ 2020-02-08 8:31 UTC (permalink / raw) To: mailing list for ConTeXt users 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 ___________________________________________________________________________________ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: issues with \attachment when specifying name 2020-02-08 8:31 issues with \attachment when specifying name Pablo Rodriguez @ 2020-02-08 12:46 ` Peter Rolf 2020-02-08 21:14 ` Pablo Rodriguez 0 siblings, 1 reply; 3+ messages in thread From: Peter Rolf @ 2020-02-08 12:46 UTC (permalink / raw) To: ntg-context 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 ___________________________________________________________________________________ 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 ___________________________________________________________________________________ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: issues with \attachment when specifying name 2020-02-08 12:46 ` Peter Rolf @ 2020-02-08 21:14 ` Pablo Rodriguez 0 siblings, 0 replies; 3+ messages in thread From: Pablo Rodriguez @ 2020-02-08 21:14 UTC (permalink / raw) To: mailing list for ConTeXt users 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 ___________________________________________________________________________________ ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-08 21:14 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-08 8:31 issues with \attachment when specifying name Pablo Rodriguez 2020-02-08 12:46 ` Peter Rolf 2020-02-08 21:14 ` Pablo Rodriguez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).