Open faceless2 opened 2 years ago
Incidentally I tried the first suggestion, the splitting of ArrayOfFields
into ArrayOfFieldsAndWidgets
, and it tested well against some valid forms combining combined and uncombined fields, and fields with name hierarchies.
EDIT 20201001 - the one complexity is Parent
in AnnotWidget
- if it contains FT
, we also need to allow Field
as an option for Parent
Another followup on this:
Field
places restrictions on Ff
- [fn:Eval(fn:BitsClear(4,32))]
. But this is an intermediate type - it must have an entry in the Kids array which is a FieldNNN
, and any restrictions on the Flags are checked there. So I don't think this restriction should be here.
At the very least on this one, even if none of the above changes are applied:
AnnotWidget Parent should go from Field
to [FieldTx,FieldBtnPush,FieldBtnCheckbox,FieldBtnRadio,FieldChoice,fn:SinceVersion(1.3,FieldSig),Field]
- otherwise Parent cannot be a terminal field, which is clearly not right.
On reflection this is an aspect of our implementation not the model.
I'm starting to work on this.
Just did some tidy up and referencing of all Annot*.tsv
.
This issue still pops up regularly in the tests, as Field and AnnotWidget have different permitted entries. One of the solutions would be to have a separate type for the merged Field+Widget dictionary. This would lead in fact to the following new types:
AnnotWidgetField, AnnotWidgetFieldTx, AnnotWidgetFieldCh, AnnotWidgetFieldBtn, AnnotWidgetFieldSig
This looks a bit weird, but I don't immediately see any other nicer solutions.
Just as an update, the latest version of veraPDF-based Arlington app implements the above suggestion when doing the conversion of the .tsv files to the veraPDF Arlington profile. Seems to work as expected
https://software.verapdf.org/develop/arlington/1.25/verapdf-arlington-1.25.236-installer.zip
It was inevitable this was going to come up at some point.
First, I'm assuming a processing model which means a node in the PDF can be of more than one type. Traverse to a combined field+widget from
Fields
? It's validated as Field. Traverse from aPage
? It's also validated as a Widget. Everything below assumes that model, if that's not how you do it I guess you can ignore the whole thing.Currently there are 3 types,
Field
(an untyped field with noFT
),FieldNNN
(a typed field withFT
) andAnnotWidget
. And there is a single type for a list of these items,ArrayOfFields
which is used for bothFields
in the Form andKids
in the Fields. It's a list of:[FieldTx,FieldBtn,FieldCh,FieldSig,Field,AnnotWidget]
- I'm ignoring the predicate for FieldSig.This means that we have the following allowed behaviour:
Fields
array that references a widget that has no field (either combined or as a parent)Field
with noFT
, or belong to no field at all.Fields
array can point to elements with aParent
Parent
andKids
arraysKids
I think all of those are disallowed (happy to justify if required), so here's a proposal to remedy this.
To fix the first two issues you could split
ArrayOfFields
intoArrayOfFieldsOrWidgets
. Your types then look likeThe last issues can be done with some magic in your SpecialCase field - we need to check
Kids
because the rules for Fields are:
and for Widgets:
I think we can represent all that with an
fn:Eval
that looks like this (expanded to make it a bit more legible):It's using
/Subtype/Widget
as the test for "is a widget", which is not quite right, and I've also just inventedfn:InArray
, and presumed that==null
is the same as "field is not there" - which probably isn't the case. However I think the logic is correct.Finally, as an alternative if you don't want to go crazy with the special case field, I think we could capture the same logic by splitting
FieldTx
into lots of subtypes egFieldTxNonTerminal
,FieldTxTerminal
,FieldTxTerminalCombined
etc, with the same for the other field types. It's a more declarative but explodes the number of types.Sorry, that's a rough one to start the day with.