Seems we are encountering same problem. (thread: bug of highlighter/SimpleSpanFragmenter, returned longer fragment than expected?) When debugging, your fragmenter is SimpleSpanFragmenter? isNewFragment() returns true due to below logic? boolean isNewFrag = offsetAtt.endOffset() >= (fragmentSize * currentNumFrags) <---------true && (textSize - offsetAtt.endOffset()) >= (fragmentSize >>> 1); <----------FALSE
I am pursuing input from the community instead of changing/maintaining code by myself. Best regards, Duke If not now, when? If not me, who? On Fri, Aug 7, 2015 at 1:25 AM, Robert Alexander <roba...@gmail.com> wrote: > Hey everyone, > > I ran into an issue with the standard highlighter in 4.10.4 and was hoping > that someone could help. I'm attempting to fragment a result based on a > SpanNearQuery. If the words in the query are next to each other, the > fragmenter will often return one large result containing the entire > document. If the words are farther apart, it returns fragmetns of the > expected size. > > I have included an example here in a gist link. The sample creates an index > in RAM and adds a single document. If I search for "ken" within 3 of "lay", > I see the problem. If I search for "ken" within 3 of "office", the problem > goes away. If you debug with the lucene source, you'll see that it seems as > if textFragmenter.isNewFragmetn() never returns true (although I understand > that this is the user group and not the dev group so this may be of limited > use). > > Are there known issues with the standard highlighter and SpanNear queries? > I am only using the old highlighter because the FVH doesn't appear to > handle SpanNear queries at all. > > Thanks for the help, > > Rob > > Sample Gist: https://gist.github.com/robalex/97a005f4ee23c71c48f6 >