Just want to check that I understand the problem correctly. Is there a reason why we can't send HTML reports to the browser, as suggested, then print or save to pdf from the browser? Do we need to generate postscript or pdf directly from gnucash? I know that at the moment there can be problems with html reports and pagination, in particular, but there is a solution for that, e.g., using paged.js https://pagedjs.org/made-with-paged.js.html
I know paged.js from its use in an R package. Here's some examples: - a report https://slides.yihui.org/2019-ISU-pagedown.html#12 - a poster with a complex layout https://slides.yihui.org/2019-ISU-pagedown.html#20 - a letter https://slides.yihui.org/2019-ISU-pagedown.html#24 - a journal article in html and pdf side-by-side https://slides.yihui.org/2019-ISU-pagedown.html#34 Or have I misunderstood the problem? David On Tue, 21 Nov 2023 at 03:36, john <jra...@ceridwen.us> wrote: > > 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 -- David Whiting _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
