lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Sokolov <>
Subject Re: Highlighting text, do I seriously have to reimplement this from scratch?
Date Thu, 06 Feb 2014 13:15:37 GMT
On 2/6/2014 12:53 AM, Earl Hood wrote:
> On Tue, Feb 4, 2014 at 6:05 PM, Michael Sokolov wrote:
>> Thanks for the feedback.  I think it's difficult to know what to do about
>> attribute value highlighting in the general case - do you have any
>> suggestions?
> That is a challenging one since one has to know how attribute data will
> be transformed for rendering purposes.
> I do not know the workings of Lux, so I cannot provide any specific
> suggestions on what Lux can do.  I would need time to dive into it.
> However, one solution is to workaround the limitation by preprocessing
> the data in a form that is friendly to Lux (or at least the highligher).
> For example, if I have attribute data I know will be transformed into
> renderable content, I would transform it into element-style content,
> which should be more friendly for indexing and highlighting purposes.
Lux's XmlHighlighter wraps matching text in an XML element tag.  The 
name of the tag is configurable.  But it won't work for attribute values 
since XML doesn't allow "<" in an attribute value.  I think Olivier's 
suggestion of providing a callback is interesting; that way we can 
provide the user much greater control, and the "highlighter" can 
actually become more of a query-driven document-processing engine: you 
could imagine fairly complex document transformations driven by Lucene 
query matching.

I created to track that.  If 
anybody is interested in continuing this discussion, I'd suggest picking 
it up over on Lux's mailing list at since this seems a 
little off topic here.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message