News for hackers. Stuff that matters.

A comment on USPTO to add surcharge on non-DOCX patent applications in 2023. Parent comment

Re:USPTO to add surcharge on non-DOCX patent applications in... by molsongolden on Friday August 26, 2022 @01:54PM (#32610672)
Was just about to post this. Unzipping DOCX and parsing XML is much easier than accurately processing PDF submissions.
[ Parent | on HN ]
Re:USPTO to add surcharge on non-DOCX patent applications in... by 0x457 on Friday August 26, 2022 @07:27PM (#32613931)
Why not make yet another XML standard for patents and generate PDFs from it?
[ Parent | on HN ]
Re:USPTO to add surcharge on non-DOCX patent applications in... by moistly on Friday August 26, 2022 @10:56PM (#32615191)
Or just use Docbook and the standard, open pipelines for publication to print and web.
[ Parent | on HN ]
Re:USPTO to add surcharge on non-DOCX patent applications in... by 0x457 on Saturday August 27, 2022 @08:26PM (#32624580)
I was saying it half-sarcastically because of how many "universal" XML standards are out there and how useless they are.

I wrote DDEX parsers in the past and I wish it never existed...

[ Parent | on HN ]
Re:USPTO to add surcharge on non-DOCX patent applications in... by oneplane on Friday August 26, 2022 @03:39PM (#32611840)
OCR has come a long way, so much that visually interpreting a PDF is about as error-prom as parsing XML output from Microsoft in non-microsoft software.
[ Parent | on HN ]
Re:USPTO to add surcharge on non-DOCX patent applications in... by programmarchy on Friday August 26, 2022 @04:58PM (#32612691)
Try extracting tabular data from a PDF! With XML it's trivial, but for PDF you need highly specialized software packages to do this. One of the best, pdfplumber, is largely based [1] on a Master's thesis titled Algorithmic Extraction of Data in Tables in PDF Documents [2].

[1] https://github.com/jsvine/pdfplumber/blob/stable/pdfplumber/...

[2] https://trepo.tuni.fi/bitstream/handle/123456789/21520/Nurmi...

[ Parent | on HN ]
Re:USPTO to add surcharge on non-DOCX patent applications in... by oneplane on Friday August 26, 2022 @08:17PM (#32614268)
This was mostly aimed at the various ways the XML document may or may not conform to any number of XSD types. What we 'see' as a table might not be described and stored as a table in the same way in XML. And with XML I mean whatever XML office (the one from microsoft) generates.

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.

[ Parent | on HN ]
Re:USPTO to add surcharge on non-DOCX patent applications in... by a1369209993 on Friday August 26, 2022 @09:12PM (#32614564)
> for PDF you need highly specialized software packages to do this.

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).

[ Parent | on HN ]