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 ___________________________________________________________________________________
