Die verlinkte Plattform stellt doch nur ein Web-Frontend für OCR dar - das ist nichts was man auf der Konsole/Kommandozeile nicht auch selbst machen könnte. Hierfür einen Web-Service zu nutzen halte ich für unnötig, die Datenschutzimplikationen (man gibt ja die Texte ggf. aus der Hand und füllt schlimmstenfalls irgendwelche fremden Datenbanken)für problematisch.
Wieso aber sollte man aber eine Google-Pdf, die bereits (wahrscheinlich mit derselben OCR-Engine Tesseract) erkannt ist nochmal durch die Texterkennung schicken? Tesseract ist in meinem Workaround bisher kommerziellen Lösungen (Abby) unterlegen (keine Verwendung statistischer Sprachmodelle), aber der derzeit einzige mir bekannte Weg, kostenneutral OCR auf Frakturschrift zu machen.

Gute Erfahrungen habe ich gemacht, indem ich die unsäglich riesenhaften Repositoriums-Scans aus den Digitalisierungszentren/ Online-Angeboten von Bibliotheken (farbige JPGs/PDFs von s/w Büchern, je etwa 150 MB pro Band) per Stapelverarbeitung mit etwas Scharf-/Weichzeichner und ein paar Filtern zu s/w-Bildern gewandelt und diese durch die OCR geschickt habe. Die Fehlerquote in der Erkennung sank dadurch von 1-2% auf unter 0,1% (i.e. 1-2 Fehler auf 2 A4 Normseiten) und ist damit besser als das in den Repositorien selbst Gebotene. Dort laufen die produktiven Systeme meist auf Visual Library - Systemen, die proprietär (früher Microsoft-Ökosystem, IIS; jetzt VLs, etwas selbstgebautes) und schwerlich evaluierbar sind. Für die Qualitäten dieser Erfassung sei auf die vielen Blogposts von KG verwiesen, die in epischer Breite schildern, was alles nicht zu finden ist, obwohl es "augenscheinlich" auf der Seite steht.

Sollte das Ausgangsmaterial aus dem Kopierer stammen (und der Scanoperator nicht so fit sein (schwarze Ränder, Buchfalz etc.)), empfiehlt sich zusätzlich das von Jens Gulden vor 9 Jahren(!) geschriebene und nach wie vor unerreichte unpaper.