Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 6.1.1
-
Fix Version/s: 6.2
-
Component/s: Core/Rendering
-
Labels:None
-
Environment:All
-
Support Case References:Support Case #13775 - https://icesoft.my.salesforce.com/5007000001awxjz
Description
For example, searching for "Table" comes up with no results where it is clearly in the PDF content multiple times.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The PDF has a strange style of encoding. It uses a negative font size as well as text scale which I think is causing our text extraction code to incorrectly interpret spaces between characters. I've made a small tweak to the font engine and the words are correctly spaced for searching but there is still an issue with the location of the highlight box. The highlight box is slightly off center with respect to the underlying text.
This might take a while to figure out as this affects how we fundamentally layout and draw text.
Can you provide me some additional technical information regarding this pdf document (exact font size, text scale?). I'll work with our customer in order to send bug report to software manufacturer (WS-CAD software) - of course without any ETA for an answer, but it would be best to correct this on their side. Thanks.
Right now, i've created some workaround for this kind of files, by extracting page text and then removing all white spaces and searching through this. I'm only using this for headless search. Of course with this workaround i can only search continuous text, but right now it's all I can do.
Are your searches only being done in a headless environment or is that just for your work around? The fix I have for the font engine fixes the search algorithm but here are still some issues with painting the search highlight in the correct location.
Automatic search is done in headless mode. We are using it for finding and mapping items from system structure to pages on generated documentation. But of course we have integrated swing viewer for this documentation and our customer can search this document manually using GUI interface. The headless search is a primary concern for us. If the highlight location is somewhat spatial translated I think customer can live with it.
Anyway, if you could provide me some example data from PDF structure, which are "wrong" (e.g. negative font size) I can raise an issue on WS-CAD site and ask them to correct the document.
A very unique PDF that has a text layout that we haven't seen or no one has taken notices. When creating the bounding box we always he assume box should be create with the x,y at the lower left but in the instance of this pdf the font size is negative which creates right to left layout which is then mirrored by the current gs transform. The problem with the layout is that we create the bounding box incorrectly and everything goes sideways from there.
I've added some code to detect the negative layout and thus we create the correct bound. Everything works as expected afterwards.
Marking as fixed.
Maybe you can at first analyze what the real reason for not searching is. It could be corrected during PDF generation, but we had to know what is the real reason for this issue.