[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [docbook-apps] Help needed testing CJK search support in webhelp
> Hello Denis, > Thanks for the feedback. Please see the comments inline. > > --Kasun > > Sent from my iPhone > > On 12 Aug 2010, at 07:48 AM, Denis Bradford <denis.bradford@verizon.net > > wrote: > >> I've installed and built the new package. It's beautiful! I saw a >> few issues: >> >> 1. Couldn't create Search tab: I assume the Search tab is supposed >> to appear somehow when I build the indexer. However, after >> following instructions and running both the webhelp build-indexer >> targets I got the TOC tab only. > > The purpose 'build-indexer' target is to compile the java source > that is used for indexing the content. For a end- user this target > is of less use, unless s/he plans to change java source. > Running only 'webhelp' target should create the search tab. But we > did made creating the search tab optional. Ie if user doesn't need > it, s/he can drop it. > It is done by a property in build.properties file called > exclude.search.from.webhelp. Setting this to true will drop the > search tab. > > But, I couldn't figure out the reason For your case, assuming you > didn't change that property. Can you please pastebin the ant webhelp > output as well? Now, I'm not away from my computer I will look in > further possible causes for your issue and will update list. > >> Here's the command output -- not sure if it's completely normal: >> >> $ ant build-indexer >> Buildfile: build.xml >> >> build-indexer: >> [mkdir] Created dir: ~/webhelp/indexer/lib/htmlsearch >> [javac] Compiling 9 source files to ~/webhelp/indexer/lib/ >> htmlsearch >> [javac] Note: ~/webhelp/indexer/src/com/nexwave/nquindexer/ >> IndexerTask.java uses unchecked or unsafe operations. >> [javac] Note: Recompile with -Xlint:unchecked for details. >> [jar] Building jar: ~/webhelp/indexer/lib/nw-cms.jar >> [delete] Deleting directory ~/webhelp-db4/indexer/lib/htmlsearch >> >> BUILD SUCCESSFUL > > This is normal, and this has no connection with the issue above. > >> >> >> 2. I looked at the Search tab on the online package (http://www.thingbag.net/docbook/gsoc2010/doc/content/ >> ). Verified that search results are synced with the TOC. However, >> noticed this glitch: >> >> When I enter a search query and click a link in the result, the >> target topic has a big, light blue input button with the letter H >> in it, just beside the top arrow nav button. The button appears on >> every Search target that I open, but is hidden when I open topics >> from the TOC instead of Search. > > It is removed now. That was a intermediatory thing. > >> >> 3. The source has indexterm elements but no index. You might >> consider adding an index element to the end of the book, just so >> the build generates an index. After, this is one of the advantages >> of WebHelp over DocBook Website! > > Index is already there, as the last link in TOC tab. Did you mean > that or adding a separate tab for index, along with 'contents' and > 'search' tabs? > >> >> I did verify that the TOC stays synced when I navigate using the >> index. >> (Exception: 'Web-based Help from DocBook XML Readme' has an index >> entry but no TOC link. Since this is the bookinfo component, I >> think WebHelp effectively syncs to the top of the TOC.) > > Ok. We missed that. I'll add an link to the bookinfo component. > >> >> Thanks so much for this work, Kasun, I hope this feedback is a >> little bit useful. > > Thanks to you as well for the great feedback! This will help us to > make webhelp better. And special thanks should go to my mentor, > David Cramer for his great support. > > Please point out further glitches you notice. > >> >> Denis >> >> P.S. While looking at WebHelp, it suddenly struck me that your >> frameless design makes implementing context-sensitive help a no- >> brainer. I remember all the work Jirka had to do to add support for >> application hooks in the htmlhelp stylesheets, because we had to go >> through the CHM browser's protocol. With WebHelp, F1 from any >> control just needs a simple URL link to an HTML page. That's a >> major selling point, IMO. > > Yes it is. With this Css-based approach, users will land on correct > URL when coming from search engine results, which is not the case if > framesets were used. > > Thanks, > --Kasun > > >> >> On 08/09/2010 10:04 AM, Cramer, David W (David) wrote: >>> Hi there, >>> >>> Kasun Gajasinghe has been hard at work this summer on the webhelp >>> GSoC >>> project and has implemented all the required features, including >>> stemming for English and German, highlighting of search results, and >>> tokenization for Asian (Chinese, Japanese, Korean) languages, >>> freeing >>> the output from the frameset, and automatic toc synching. >>> >>> You can see a demo of the results of his efforts and download it >>> to try >>> things out on your own content from here: >>> http://www.thingbag.net/docbook/gsoc2010/doc/content/ch02s01.html >>> >>> The instructions provide links to a version of the package for 4.x >>> and >>> 5.x documents. >>> >>> Feedback is welcome. Please let us know what bugs you find. In >>> particular, we need to test the CJK search support. If you have some >>> demo content in Chinese, Japanese, or Korean that you can share >>> with us >>> for testing, we’d appreciate it. I had planned to use the Chinese >>> version of DocBook, The Definitive Guide, but have had some trouble >>> getting my environment set up so it will build. >>> >>> We plan to provide instructions for adding stemming support for >>> other >>> non-CJK languages. For a number of languages >>> <http://www.thingbag.net/docbook/gsoc2010/doc/content/ >>> ch02s04.html>, all >>> that is required is to port the stemmer from Java to JavaScript so >>> that >>> it can be used on the client side. >>> >>> Thanks, >>> >>> David >>> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]