Re: [NTG-context] issues with \attachment when specifying name
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
___
Re: [NTG-context] attachments working again (issue with /EmbeddedFiles)
On 2/8/2020 12:32, Pablo Rodriguez wrote: On 2/8/20 1:45 PM, Peter Rolf wrote: [...] I attached the current code, so you and Rik are able to test it if you want (creating a new format is required). Best contact me off-list if you run into new problems. Hi Peter, the new version is fine for me. From what I see, /F is now set to 4 (print). Many thanks for your help, Pablo -- http://www.ousia.tk Not quite ready yet. When the hidden method is used, it passes the online validator[1], but fails VeraPDF[2] for clause 6.8-1. When visible, it fails the online validator stating that the appearance dictionary doesn't contain an entry, and fails VeraPDF for clauses 6.8-1 and 6.3.3-1. Oddly, the bookmarks do not appear either way under MkIV, and they do not appear when the attachment is visible under LMTX. The bookmarks do appear with a hidden attachment under LMTX. The results are generally better than before this updated lpdf-wid.lua. [1] https://www.pdf-online.com/osa/validate.aspx [2] Version 1.14.8, which I believe is the current version -- Rik ___ 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 ___
Re: [NTG-context] attachments working again (issue with /EmbeddedFiles)
On 2/8/20 1:45 PM, Peter Rolf wrote: > [...] > > I attached the current code, so you and Rik are able to test it if you > want (creating a new format is required). Best contact me off-list if > you run into new problems. Hi Peter, the new version is fine for me. From what I see, /F is now set to 4 (print). 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 ___
Re: [NTG-context] issues with \attachment when specifying name
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
___
Re: [NTG-context] attachments working again (issue with /EmbeddedFiles)
Am 07.02.2020 um 22:37 schrieb Hans Hagen:
> On 2/7/2020 9:55 PM, Pablo Rodriguez wrote:
>> On 2/7/20 9:19 PM, Rik Kabel wrote:
>>>
>>> On 2/7/2020 14:46, Pablo Rodriguez wrote:
many thanks for having fixed the issues with attachments (in latest
beta
from 2020.02.07 18:36). I haven’t tested attachments with PDF/A-3a.
>>> PDF/A-3a attachments still fail validation with the same issues.
>>
>> Hi Rik,
>>
>> it has way less issues, at least using verapdf-1.5.18 and the following
>> sample:
>>
>> \setuptagging[state=start]
>>
>> \setupbodyfont[30pt]
>>
>> \setupbackend
>> [format=PDF/A-3a,
>> intent=sRGB IEC61966-2.1,
>> profile={sRGB.icc,default_gray.icc},
>> level=0]
>>
>> \setupcolors[pagecolormodel=auto]
>>
>> \setupinteraction[state=start]
>> \starttext
>> \startTEXpage[offset=1em]
>> an attachment\attachment[file=xml-mkiv.pdf,
>> type={application/pdf}]
>> \stopTEXpage
>> \stoptext
>>
>> With "method=hidden" (no attachment annotation) it has no issue.
>>
>> Both issues are related to annotations in general:
>>
>> - If the flag annotation is present (/F key), it should be set to print
>> and disable everything else.
>> - Annotations need an appearance dictionary (unless their /Rect is one
>> and the same point, or /Popup or /Link annotations).
>>
>> Actual value of the annotation flag key is "/F null". I wonder whether
>> this is a bug (for having wanted to avoid the presence of /F at all).
>>
>> Otherwise, I don’t think that setting all embedded file annotations to
>> printable is a good default.
>>
>> Just in case it helps to the discussion,
> Peter is stepwise looking into all these issues but we decided to also
> see how that checking and standards evolve in cases where it's a
> confusing mess. And these 'appearance dicts' are an example of a mess.
> On the one hand there's predefined appearances and on the other hand
> enforced renderings which gives some chicken-egg issue. It smells a lot
> like bugs became features (standards) or 'acrobat behaviour' made the
> standard or ... (like the zero rect thing, which, given t e plenty of
> flags there are and verbosity there is in pdfm is pretty weird and
> actually can make viewers bark. Irr the current approach we follow is
> kind of a compromis.
>
> Now, of course we can play safe and *always* have some fake appearance
> (we could basically choose whatever funny shape we like as over time
> people will interpret hard codes symbols for attachments differently)
> and drop support for standardized renderings (that could adapt over time).
>
> So ... no changes etc till Peter gives his blessing as he is testing all
> this in the framework we've set up for it.
>
> Hans
>
As Hans stated, we are working on it and two of the three validation
problems are already solved (needs more testing though). The only
remaining problem is this
https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Parts-2-and-3-rules#rule-633-1
I attached the current code, so you and Rik are able to test it if you
want (creating a new format is required). Best contact me off-list if
you run into new problems.
Peter
lpdf-wid.7z
Description: Binary data
___
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
___
Re: [NTG-context] Fonts from various .otf to work with \bold, \emph, \bf, \bfa ...
Pablo Rodriguez schrieb am 07.02.2020 um 21:22:
On 2/7/20 8:34 AM, cont...@vivaldi.net wrote:
Hello Pablo,
thank you for showing the way; unfortunately, still something is
missing:
Hi Lukas,
I’m afraid you missed to install the fonts in ConTeXt.
- the resulting file uses LMRoman instead of WorkSans,
Otherwise, \definefontfamily won’t work (even if using
"tf={file:work-sans.light.otf}").
Do you have any problem installing fonts in ConTeXt? This would make
things easier.
- Note that all WorkSans files:
[...]
are placed in the same directory as the main source file. (I can zip
them and upload somewhere for testing purposes.)
The designer provides the latest version of the font on github without
the change in file name from your source.
https://github.com/weiweihuanghuang/Work-Sans
This was a feature already discussed in the past.
"\definefont[Test][file:your-font-file.otf]" should work, but I never
used this approach.
Works at the moment only when the fonts in a place where ConTeXt can
find them.
Wolfgang
___
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
___
[NTG-context] 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
___
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
___
Re: [NTG-context] attachments working again (issue with /EmbeddedFiles)
On 2/7/20 10:37 PM, Hans Hagen wrote: > Peter is stepwise looking into all these issues but we decided to also > see how that checking and standards evolve in cases where it's a > confusing mess. And these 'appearance dicts' are an example of a mess. > On the one hand there's predefined appearances and on the other hand > enforced renderings which gives some chicken-egg issue. It smells a lot > like bugs became features (standards) or 'acrobat behaviour' made the > standard or ... (like the zero rect thing, which, given t e plenty of > flags there are and verbosity there is in pdfm is pretty weird and > actually can make viewers bark. Irr the current approach we follow is > kind of a compromise. Just a comment on one of the issues. Maybe the simplest way to avoid the issues with the annotation flag is not including it at all. Once annotations have appearance dictionaries, Acrobat will print those ones with an annotation flag set to print. 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 ___
