Export to Searchable PDF [120628290]

Assigned

Feature Request

Status Update

No update yet.

Description

ja...@gmail.com

created issue #1

Dec 7, 2018 10:16AM

Please describe your requested enhancement. Good feature requests will solve common problems or enable new use cases.

What you would like to accomplish:

Google's OCR API returns a json back when you upload a pdf. The JSON is the only export format. A PDF export option will be great and this is what commercial OCRs like abbyy offer. A textual extraction loses original pdf's formatting and text positioning information. Exporting to PDF will help me use the pdf for further processing such as converting it to another format/ editing the pdf.

How this might work:

A pdf export will help position Google OCR as a fully capable commercial offering. Currently, the accuracy of text extraction is on par or sometimes even better than other commercial offerings, but the export to text/json only can greatly add to the API.

If applicable, reasons why alternative solutions are not sufficient:

The information in json is not enough for me to build a pdf from scratch because vital information such as font formatting is already lost in the process of Google OCR.

Other information (workarounds you have tried, documentation consulted, etc):
I've tried different parameters in Google OCR, such as using TEXT_EXTRACTION, but it jumbles the order of the document text.

Comments

ja...@gmail.com <ja...@gmail.com> #2Dec 7, 2018 10:18AM

I have informed our engineering team of this feature request. There is currently no ETA for its implementation.

A current workaround would be to check the returned "boundingPoly" [1] "vertices" for the returned "textAnnotations". If the calculated rectangle's heights > widths, than your image is sideways.

[1]

https://cloud.google.com/vision/reference/rest/v1/images/annotate#boundingpoly

ji...@google.com <ji...@google.com> #3Dec 8, 2018 02:54AM

Assigned to ji...@google.com.

I also need this problem solved :)

ja...@gmail.com <ja...@gmail.com> #4Dec 8, 2018 03:28PM

same :D

711.pdf

1.9 MB

View

Download

abbyy_711.pdf

1.1 MB

View

Download

ji...@google.com <ji...@google.com> #5Dec 11, 2018 12:52AM

ja...@gmail.com <ja...@gmail.com> #6Dec 13, 2018 02:49PM

ji...@google.com <ji...@google.com> #7Dec 14, 2018 12:29AM

Reassigned to gc...@google.com.

This needs more attention. It's not just a display issue as described in the report. The co-ordinates returned in 'boundingPoly' are incorrect if the image was taken on a phone. All the x points should be y and vice versa.

The workaround does not make sense as "boundingPoly" [1] "vertices" for "textAnnotations" does not indicate the image dimensions - it indicates the dimensions of the relevant text block inside the image.

mb...@gmail.com <mb...@gmail.com> #8Sep 26, 2019 02:50PM

ki...@gmail.com <ki...@gmail.com> #9Nov 19, 2019 03:53AM

Would be great if this could be implemented.

lu...@gmail.com <lu...@gmail.com> #10Nov 19, 2019 06:13AM

Message last modified on Nov 19, 2019 06:14AM

vi...@gmail.com <vi...@gmail.com> #11Nov 22, 2019 11:34AM

vi...@gmail.com <vi...@gmail.com> #12Mar 11, 2020 01:56PM

oc...@gmail.com <oc...@gmail.com> #13May 27, 2020 07:30PM

+1.

aa...@scious.io <aa...@scious.io> #14Jul 16, 2020 03:22AM

The rotation information should already be available, basically the order of the bounding box vertices encode that rotation information:

https://cloud.google.com/vision/docs/reference/rest/v1/images/annotate#block

Could you please test and see if that works for your case?

Message last modified on Jul 16, 2020 03:38AM

lu...@gmail.com <lu...@gmail.com> #15Jul 16, 2020 03:33PM

Each bounding box on the page can have a different orientation, so it can be frustrating to figure out.

ne...@bergmann-infotech.de <ne...@bergmann-infotech.de> #16Jul 21, 2020 06:33AM

mi...@mcfile.com.br <mi...@mcfile.com.br> #17Jul 22, 2020 03:06PM

"A current workaround would be to check the returned "boundingPoly" [1] "vertices" for the returned "textAnnotations". If the calculated rectangle's heights > widths, than your image is sideways. " - The proposed workaround does not work if the image needs to be rotated at 180 degrees. Any ETA after 2y and 1 day?

an...@gmail.com <an...@gmail.com> #18Aug 4, 2020 12:56PM

vd...@gmail.com <vd...@gmail.com> #19Aug 15, 2020 04:08AM

zy...@gmail.com <zy...@gmail.com> #20Sep 20, 2020 09:28AM

mo...@gmail.com <mo...@gmail.com> #21Sep 29, 2020 02:54PM

ca...@gmail.com <ca...@gmail.com> #22Mar 11, 2021 02:03AM

Any ETA after such long time.

mo...@gmail.com <mo...@gmail.com> #23Jul 7, 2021 03:22PM

We just prioritized this work and tentatively aiming for August for releasing various OCR improvements including orientation detection.

ac...@gmail.com <ac...@gmail.com> #24Dec 29, 2021 09:36AM

Great stuff, really good to hear, this will have some really useful applications!

m....@gmail.com <m....@gmail.com> #25Apr 9, 2022 01:19AM

Just to gather some details, this feature request is for *page* level orientation information? Like a enum UP DOWN LEFT RIGHT. Is orientation also desired for individual blocks, paragraphs, words, symbols, etc?

Also, this new orientation info will only apply to the DOCUMENT_TEXT_DETECTION feature.

al...@gmail.com <al...@gmail.com> #26Jun 16, 2022 09:56PM

Comment has been deleted.

Message last modified on Jun 16, 2022 10:05PM

na...@gmail.com <na...@gmail.com> #27Jul 27, 2022 10:44AM

I think there should be an option field where you can decide if the orientation should also be given for individual blocks, words etc.

ga...@gmail.com <ga...@gmail.com> #28Jan 25, 2023 02:27PM

Ideally we would have word-level information around rotation as well

sg...@gmail.com <sg...@gmail.com> #29May 26, 2023 09:09PM

Great to hear that this feature will be added in the near future!

ja...@gmail.com <ja...@gmail.com> #30May 26, 2023 11:03PM

+1 please!

si...@google.com <si...@google.com> Jun 6, 2023 03:45AM

Reassigned to si...@google.com.

si...@google.com <si...@google.com> Jun 9, 2023 06:03AM

Reassigned to gc...@google.com.

IssueTracker