Re: attachments working again (issue with /EmbeddedFiles)

[Peter Rolf <indiego@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 3377 bytes --]

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


[-- Attachment #2: lpdf-wid.7z --]
[-- Type: application/octet-stream, Size: 7139 bytes --]

[-- Attachment #3: Type: text/plain, Size: 493 bytes --]

___________________________________________________________________________________
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
___________________________________________________________________________________