Summary: | help.l.o search result links to other page than where the search string was found | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Lionel Elie Mamane <lionel> |
Component: | Documentation | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | normal | CC: | olivier.hallot, sdc.blanco |
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 97629 |
Description
Lionel Elie Mamane
2020-11-25 12:55:10 UTC
For information The top search box uses omindex from the Xapian project. https://xapian.org Relevant part of the update script: (...) omindex --follow --track-ctime \ --spelling ${s:+--stemmer="$s"} \ --db="$DESTDIR/${v}_${l}" \ --url="/$v/$l/" \ "$ROOTDIR/$v/$l" (...) The problem here seems to be that ref_pdf_export_general.xhp is a shared file and it determines whether it's Calc or Writer related based on the currently selected application in the Help web page. There's a switch statement in the file that displays this content only for Calc. <switch select="appl"><case select="CALC"> <h3 id="hd_id51574108224576">Whole sheet export</h3> <paragraph role="paragraph" id="par_id81574108602417">Export one sheet per page.</paragraph> </case></switch> What seems to be happening is: 1) omindex search for the string "whole sheet export" inside all XHP files and finds it ref_pdf_export_general.xhp 2) Then it creates the link for the user to access the page, but it assigns DbPAR=WRITER to the link 3) Because of the wrong DbPar, the searched contend is not shown to the user Maybe this happens because this is a shared file (located in text/shared/01/), the search system assigns it to be DbPar=WRITER as some sort of fallback. |