Today, it's not exactly the code that was bad. For some time, a government agency had been collecting information from users using fillable PDF forms. The user would submit the form, and then a data entry clerk would copy the text from the form into a database. This, of course, raised the question: why was someone manually riding the copy/paste button?

Sally was tasked with automating this. The data is already in a digital format, so it should be easy to use a PDF library to parse out the entered data and insert it into the database. And it almost was.

Sally shares with us, not code, but the output of her program which scanned the fields, looking for their names:

FieldType: Text
FieldName: T5ZA1
FieldNameAlt: T5ZA1
FieldFlags: 25165824
FieldJustification: Left
FieldMaxLength: 3
---
FieldType: Text
FieldName: T5ZA2
FieldNameAlt: T5ZA2
FieldFlags: 25165824
FieldJustification: Left
FieldMaxLength: 2
---
FieldType: Text
FieldName: T5ZA3
FieldNameAlt: T5ZA3
FieldFlags: 25165824
FieldJustification: Left
FieldMaxLength: 4

I could go on, Sally certainly shared many more examples, but you can get the gist. The names were all cryptic five character blobs. They all start with T5Z, and followed by "letternumber": A3, B9, C2, etc. It has the vibe of being autogenerated; someone just never considered that they might want clear names for the fields, and just let their editor autonumber them, but that has one counterpoint to it: the letter "O" is never used. T5ZN9 is followed by T5ZP1.

Sally was left scratching her head. Of course, she was going to have to write some sort of lookup that would convert the PDF's field names into database field names, but she expected that the PDF would provide at least some sort of guidance on that front.

I really enjoy that the alt-text for every field is also the field name, which is a clear accessibility "win".

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.