-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Suggestion] Reporting the byte location of images #161
Comments
Thank you @keto33 ! In pdfalto, you can choose to extract and process images (embedded bitmap and vector graphics) or not with the argument Grobid can extract or not images (called "assets"):
Using the byte location in the PDF as alternative seems a good idea for pdfalto! This could be used then by Grobid for example. I don't know if it can be portable and how exactly doing it, I will look at it. |
Thanks for your kind attention, @kermitt2 ! This actually should be done in xpdf rather than pdfalto itself. I am not a C++ expert, but I am a little bit familiar with xpdf, as I tweaked it for a project. Since images are stored as stream objects in PDF, xpdf fetches and writes them by I think the existing function of |
I have tested many PDF-to-text programs, and this one is the most robust. However, handling images is always a question since they are heavy objects and usually unnecessary. If I am correct, starting from version 0.7, GROBID dropped the option of extracting images.
I suggest adding an option to save the byte location of image elements instead of saving the image to disk. In this case, we can later read the image directly from the PDF file whenever needed instead of storing all images on the disk.
Implementing this feature should be trivial since the location and length of the image objects are already known to pdfalto.
The text was updated successfully, but these errors were encountered: