lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Roth <>
Subject Re: PDF writer
Date Fri, 21 Oct 2016 13:58:00 GMT
Hi Shawn,

Thanks for the thoughtful response on middleware and the solr philosophy.
You are correct and I intend to handle this outside of Solr. This inquiry
was me doing some forethought on a distant project. When I see an
XSLTResponseWriter the jump-to-conclusions part of my brain jumps to PDF.
The separation you are describing is very logical.

At this point I intend to make use of an XSLTresponse to produce formatting
objects that I will process at a later point in the application. Or maybe I
won't. Solr isn't my upstream source. The data is relational, but my
indexes are in solr. I could always process the upstream relational data to
produce my PDF reports.


On Wed, Oct 19, 2016 at 10:53 AM, Shawn Heisey <> wrote:

> On 10/17/2016 8:01 AM, Matthew Roth wrote:
> > Is there a documented or preferred path to have a PDF response writer?
> > I am using solr 5.3.x for an internal project. I have an XSL-FO
> > transformation that I am able to return via the XSLT response writer.
> > Is there a documented way to produce a PDF via solr? Alternatively, I
> > was thinking of passing the response through an eXist-db instance [0]
> > we have running. However, a pdf response writer would be ideal.
> Solr responses are designed to be processed by a program making a search
> query, not read by an end user.  Solr is middleware.  There are multiple
> formats (json, xml, javabin) because we do not know what kind of program
> will consume the response.
> PDF is an end-user format for display and print, not a middleware
> response format.  Creating content like that is best handled by other
> pieces of software, not Solr.
> For best results that fit your needs perfectly, that software is likely
> to be something you write yourself.  The Solr project has absolutely no
> idea how you will define your schema, or how you would like the data in
> a Solr response transformed, integrated, and formatted in a PDF.
> Designing the feature you want would be something best handled as an
> software project separate from Solr.  The software would take a Solr
> response and turn it into a PDF.  It doesn't fit into Solr's core usage,
> so making it a part of Solr is not a good fit and unlikely to happen.
> No matter where the development for a general feature like that happens,
> it would likely take weeks or months of work just to reach alpha
> quality.  After that, it would take weeks or months of additional work
> to reach release quality ... and even then it probably wouldn't produce
> the exact results you want without extensive and complicated
> configuration.  Handling complicated configuration is itself very
> complicated, which is one reason why development would take so long.
> Thanks,
> Shawn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message