You can make an all-in-one HTML if you make an .adoc page that uses "include" macros to pull in all the pages you want in the all-in-one HTML page. This is exactly how the PDF is generated, and one of the steps of the build process builds a data file that has all the pages in the proper hierarchy. We would not want to re-use the PDF specifically, but the data file that is built could be included in another file that is designed for an HTML page. It would be a massive page, however. Nice for browser-based "find", but not search.
The thing that makes the title index does have support for adding page bodies to it for a keyword lookup, but I have no idea what the performance implications of that would be. And, it's not search. We still need search - none of these alternatives are search. It would be a shame IMO to spend cycles figuring out how to make an all-in-one HTML file or some other stopgap when someone could simply spend the same energy figuring out how to integrate search. Cassandra On Fri, Jun 16, 2017 at 12:30 AM, Jan Høydahl <jan....@cominvent.com> wrote: >> find it easier to use if it's all in one > > Does the Jekyll thing have an option to generate an All-in-one HTML version > of the guide too? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > >> 14. jun. 2017 kl. 21.53 skrev Erick Erickson <erickerick...@gmail.com>: >> >> David: >> >> I have the PDF version of every release b/c I often need to search >> specific versions and/or find it easier to use if it's all in one >> doc.... >> >> FWIW, >> Erick >> >> On Wed, Jun 14, 2017 at 10:59 AM, Cassandra Targett >> <casstarg...@gmail.com> wrote: >>> I'm *really* glad people are finding it a positive change. >>> >>> We definitely need to have it searchable, but someone needs to work on >>> making it happen: https://issues.apache.org/jira/browse/SOLR-10299. >>> >>> On Wed, Jun 14, 2017 at 10:49 AM, David Smiley <david.w.smi...@gmail.com> >>> wrote: >>>> Thanks to Cassandra and Hoss indeed! >>>> >>>> Is there going to be search of the ref guide somehow? If it's searchable >>>> somewhere else then we could at least refer users there. Quick title access >>>> is working at least. >>>> >>>> On Wed, May 31, 2017 at 11:01 AM Jan Høydahl <jan....@cominvent.com> wrote: >>>>> >>>>> Agree, Erick. The new guide is amazing! >>>>> >>>>> Steve, could we perhaps have a change-history.adoc as part of the refguide >>>>> itself, so every (major) change to the guide would add a line on that >>>>> page? >>>>> Benefit is that it would follow the guide, whether in HTML or PDF format. >>>>> >>>>> Another option is to just keep it lightweight and do some kind of GIT >>>>> magic as part of refGuide release process to select all commits since last >>>>> release that include adoc changes, and then pull the commit messages from >>>>> those and generate a release-notes file. We could also include in that >>>>> file >>>>> a git diff that could be used as an aid for people when reviewing/voting >>>>> for >>>>> a ref-guide release, i.e. one place to double check that no weird edits >>>>> have >>>>> sneaked in since last release… >>>>> >>>>> -- >>>>> Jan Høydahl, search solution architect >>>>> Cominvent AS - www.cominvent.com >>>>> >>>>>> 30. mai 2017 kl. 20.37 skrev Steve Rowe <sar...@gmail.com>: >>>>>> >>>>>> >>>>>>> On May 30, 2017, at 2:04 PM, Erick Erickson <erickerick...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> 4> I don't think minor edits require a JIRA, larger ones maybe. Pretty >>>>>>> much just like the CWiki I suppose. >>>>>> >>>>>> One more thing I ran into while making the changes on SOLR-10758: >>>>>> >>>>>> 5> I included a new "Ref Guide” section under the 6.6 release in >>>>>> solr/CHANGES.txt, but this was premature, since: a) the ref guide >>>>>> release is >>>>>> still separate from the code release, so solr/CHANGES.txt isn’t the right >>>>>> place (yet); and b) even after we make the ref guide release part of the >>>>>> code release, it’s not clear that ref guide change notes belong in >>>>>> solr/CHANGES.txt, since e.g. javadocs-only changes never get mentioned >>>>>> there. (Personally I think there should eventually be some form of >>>>>> CHANGES-like release notes for the ref guide.) >>>>>> >>>>>> (I haven’t reverted my “Ref Guide” section addition to solr/CHANGES.txt >>>>>> because there is a 6.6 RC vote underway, and if it succeeds reversion >>>>>> will >>>>>> be pointless.) >>>>>> >>>>>> -- >>>>>> Steve >>>>>> www.lucidworks.com >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>> >>>> -- >>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>>> http://www.solrenterprisesearchserver.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
