Adrien, Sending the HTML to the browser is easy. Writing the reports in PDF directly requires a complete rewrite of the report output code that's hardwired to generate HTML using basic scheme text output, plus replacing the javascript-based charts solution with some other library that generates PostScript vector graphics (https://graphviz.org <https://graphvizorg/> comes to mind). That's a pretty big rewrite, probably a solid year of work for an experienced developer with lots of available time and assuming that there's a suitable library to abstract generating the PDF boilerplate.
The reason using the web browser to display the html loses the transaction/account links is because they're implemented using a callback function that we can register with WebKitWebViewGtk. That goes away when the browser isn't part of GnuCash. It's not impossible, of course: It should be possible to embed a bit of javascript that calls back to GnuCash on a (new) socket listener that would do the linked action. Regards, John Ralls > On Nov 19, 2023, at 21:32, Adrien Monteleone <adrien.montele...@lusfiber.net> > wrote: > > Thank you for the explanation John. I seem to recall a bit of that from an > older discussion. > > While it seems there is no ideal all-in-one solution, might two of your last > three suggestions be doable or is each one a serious pile of work on its own? > > That is: > > *Send the HTML/JS/CSS to the default browser > *Write reports directly to PDF > > The drill-down links I think get lost either way, and maybe that is > unacceptable, but View, Print, PDF export, and get charts. (The writing to > PDF would just be for export) > > And I'm not quite following the loss of drill-down links on the first option. > Certainly, I can open a local HTML file in my browser and it can contain > links to local resources. Is there a way to expose a URI to a GnuCash > transaction or other resource that might work? Or is the fact that it has to > leave 'GTK land' for 'native land' in the browser and back in such a case the > problem? Or is it that targeting anything within the data file is the > tricky/impossible part? (I admit, while I've used local HTML to access local > files, I've never tried to access only a portion of a file or even a marker > in a file) > > Apologies if my lack of understanding the guts of it all is noise. > > Regards, > Adrien > > On 11/19/23 11:20 PM, john wrote: >> The reason for selecting WebKitGtk is the Gtk: It had WebKitWebView and was >> supported in most distros and Mingw. >> The Mozilla team seem to have stopped maintaining their embedding facility >> around 2015 and it is apparently badly bit-rotted. >> Blink is Chromium's rendering engine so that's the same as Sherlock's >> suggested CEF, i.e. Chromium Embedded Framework. It supports Gtk only on >> Linux; on macOS and Windows it build to the native toolkits, so we'd have to >> hack the build to provide Gtk3 on macOS and Windows. There's no mention of >> support for MinGW, so that might not be possible. The level of effort needed >> both to get and keep the ports working might make it impractical even if it >> is possible, but the only way to find that out is to try. >> Note that while most repos have a Chromium package, only Arch and Nix have >> CEF packages. Adding it as a GnuCash dependency is likely to get most >> distros to drop us, so nearly everybody on Linux/BSD would be forced to use >> flatpak. > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
