[jira] [Resolved] (PDFBOX-3794) Problem in TextPosition implementation

["Tilman Hausherr (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PDFBOX-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tilman Hausherr resolved PDFBOX-3794.
-------------------------------------
       Resolution: Fixed
         Assignee: Tilman Hausherr
    Fix Version/s: 2.0.7

Done. Thanks for reporting this!

> Problem in TextPosition implementation
> --------------------------------------
>
>                 Key: PDFBOX-3794
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-3794
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Text extraction
>    Affects Versions: 2.0.6
>            Reporter: Miro Mannino
>            Assignee: Tilman Hausherr
>              Labels: easyfix
>             Fix For: 2.0.7
>
>
> In 2.0.3 there wasn't hashCode implemented in TextPosition, and for me that was fine. Same instance, same hashCode.
> In 2.0.6 the hashCode is now checking the fields values, which is reasonable. But, the hashCode in the same instance can have different results.
> The problem is in the `direction` field, which is -1.0 and initialised only when getDir is called the first time.
> For now as workaround, anytime (or just the first time) I need the textPosition's hashCode I call getDir before that. 
> Quick example:
> {code}
> Object getObjectFromTextPos(TextPosition textPos) {
>     textPos.getDir();
>     return someHashMap.get(textPos);
> }
> {code}
> I don't know the reason of the late assignment to direction, but if that is necessary, I would say that the hashCode should call getDir() instead of using the field.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org