1) Once the font resource problem was identified it became clear the EL based search wasn't robust enough. A move to using our content parser to parse the content stream was uses and then would could look at the graphicsState object to derive font name, font, size and colour. This appears to be work well across our test set.

2) when moving into a field for edit, and then a loss of focus causes the content stream to be regenerated. In the sample we are working with hex strings and in particular 4-byte character codes. The marker is FFEF but when we convert the hex value to regular string there was a bug where the marker was also being copied.

3) Generally speaking a widget will have a content stream as well as field dictionary value. The content of the content stream represents the content value. The are cases where there is field dictionary value and a null content stream and the viewer must generate a content stream. In this particular there is a field dictionary value and a partial content stream that does not represent the value. This is a bit of a issue we generally only regenerate a content stream on a change event not on initialization. Detecting this difference is also tricky.

Fairly large commit to address the various issues listed above. When widgets are rendered the first time we rebuild the content stream to make sure it matches the values stored in the value store in the annotation.

Marking as closed for for now.

The client sent one more example that has several text fields that don't appear to be editable. After a little debugging the fields have now content stream and the default appearance is set with a font size of zero. So the text is editable but one can't see it.

I've update the parser take into account that a zero size is possible and correct for it.