30 March 2026

If these Advanced Idiots are supposed to improve productivity then they have a LONG way to go. I have been playing with areas of the bitweaver framework which have been broken for some time and endeavouring to replace the gaps with more modern alternatives. One area has been the displaying of pdfs in the gallery system. Originally this was provided by a flash based option but when that was killed off, and the browsers took over displaying them directly, the display within a page has been missing. I'd played with a couple of options but not got anything stable working, but in the last few days I buckled down and concentrated on filling the gap. The obvious choice is pdf.js given that it works across all browsers, and essentially I'm using it anyway in firefox. Using it from a cdn should have just worked, but gave warnings about translations and trying to install a local copy resulted in 600Mb of node.js stuff swamping the core code base. Having got perhaps too used to simply cloning the github project, eventually downloading the stable 5.6.205 package gave a smaller footprint, although I did need to take the newer 'fluent' file for en-gb to go with it. The cdn copy at cdnjs.com is back at 5.4.149 which perhaps explains the initial problems. Adding to the fun, access to the pdf file itself had a little bug but that at least was easy to fix. Currently I do finally have a pdf viewer embedded in the bitweaver page.

One of the reasons for wanting to get this sorted is to restore the search facility that bitweaver provides in the background, but while I could identify which pdf contained a search term, getting the generic viewer to do more than simply highlight it took a couple of abortive days with Claude. Not totally wasted time as I now have a much better appreciation of how to debug the javascript in firefox, but much of what was being documented actually worked at all! I have a large list of extra code which was intended to solve the simple problem of putting the search term in the find bar of the viewer so that the previous/next buttons worked. I had specifically asked about passing this in the pdf.js code but that path was avoided, however a github pdf.js issues described a fix that sounded perfect. The only problem was it's code is 9 years old and trying to find out how to apply it was not easy. Eventually I found that 'if ('search' in params)' is now 'if (params.has("search"))' on line 1250 of the viewer.mjs file. Another bit of fun since my nginx setup would not allow .mjs files to run ;) . But the next question is just what do I add to emulate the old example. This actually turned out to be easier than anticipated and the new code is.

if (params.has("search")) {
    const query = params.get("search").replaceAll('"', ""),
        phrase = params.get("phrase") === "true";
	if (query) {
		PDFViewerApplication.findBar.open();
		PDFViewerApplication.findBar.findField.value = query;
	}
    this.eventBus.dispatch("findfromurlhash", {
        source: this,
        query: phrase ? query : query.match(/S+/g)
    });
}

I am considering if there should be a highlight param that just highlight but does not open the find bar, but at least I am now in control, and the bitweaver highlight param opens pdf files with the same highlighting as other directly generated content.

The NEXT step is to get uploading pdf's to automatically populate the liberty content object's data field with the pdf's text layer. It's working perfectly when I update existing pdf's, but I need a slightly different hack to allow that to happen on initial upload. That and getting bitweaver to actually index the pages with the search module. All the parts are there, and hopefully without AI assistance I'll get it sorted quicker!