https://support.microsoft.com/en-us/office/differences-betwe...
The list was only a few lines the last time I looked years ago, so maybe they're actually trying to make a complete list.
[edit: but I will grant that almost anything is better than attempting to parse useful content from PDF.]
In fairness though this a really good point.
I expect that whatever tooling the USPTO uses can probably just ignore those things. They're extracting metadata, not actually rendering it.
edit: ninja'd.
[1] https://github.com/jsvine/pdfplumber/blob/stable/pdfplumber/...
[2] https://trepo.tuni.fi/bitstream/handle/123456789/21520/Nurmi...
A 6000-page spec and attributes that specify if the data is tabular data based on various properties (be it columns and rows or just plain text with start and stop pointers) and then may or may not render it visually as a table is error prone, even on first-party implementations (first-party desktop versions within Windows vary, as wel as on macOS, Android, iOS and their web offering).
If there was one simple data structure describing the table and all other aspects being optional, then yes, a XML based format is easier than OCR. But that's not the case I was pointing at.
Not really, or at least not all that specialized. You need:
a: a pdf-to-raster-image converter (ie any working PDF viewer, plus maybe the X server it talks to)
b: a reasonably decent OCR system capable of scanning tables (definitely nontrivial, but hardly "highly specialized" since things other than PDFs display data in tables).
I wrote DDEX parsers in the past and I wish it never existed...