On Fri, March 30, 2007 2:53 pm, two old wrote: > if custom script exist -> execute ([user dir]/script) > else use standard script. > > if custom template exist -> use it ([user dir]/template) > else use standard template
It's simpler to always just have the user create a custom report, which is a copy of the existing report. If they care to revise the script, template, both (, or neither), then that's their prerogative. But the only option should be to create a new whole report. Also, it's simpler to require all custom reports have a different name/identity than the "standard" one. So it's not so much "invoke <Invoice> and use the override if it exists", but "invoke <Invoice>" and/or "invoke <Joe's Invoice>". > switch (option-browser) > case internal browser: > case external browser: The reports would need to target the LCD of functionality between the browsers (internal and external[s]) for most of their work, and the reports do expect to be able to use gnucash-specific URLs to open GnuCash resources. We can't support using an external browser exclusively for report content. The option to Export should (continue to) exist, and we should probably add a "... and launch browser" checkbox on the Export dialog. But it bears noting that preparing a report for export is different than preparing a report for internal viewing. Specifically, the graphs and gnucash-specific URLs need to be handled very differently. Also, a different printing stylesheet may want to be used (though this might be combined with a media=screen stylesheet). Generally, an Exported report needs to be more self-contained and less gnucash-coupled than a normal report can get away with. I think our best bet is to have a more capable internal browser (gecko), and raise the level of reports to support its features for rendering, formatting and printing. Frankly, I don't think it's an unreasonable dependency for a "top of the stack" desktop app. Note that other parts of gnome (yelp and epiphany, maybe devhelp indirectly via yelp) already depend on it, so we can safely assume that it will be available for "GNOME desktops". I'm aware of two objections to a dep on firefox: political and technical. AFAIUI most political/freeness objections around firefox concern branding and graphics, not the core rendering and browser component. The technical objections are mostly package-management concerns. I'm aware that certain Gentoo users don't want to have to build all of mozilla/firefox, and the binary distribution can't be used in a development context. But these are distribution concerns, really, and can be resolved independently. > In my opinion the individuals will customize the script/template, this is > a fact. Therefor you have to define the restrictions rather then program > for every eventuality. The goal isn't to eliminate the reasons why people need customized reports, but to minimize them. If the common use-case is to add a logo into an Invoice, then that should be a first-order configuration option of the standard Invoice report. If there's some more special-case concern, then it's probably valid for the user to have a customized report. As you've expressed, your goal is nicely-printed invoices. Here are the problems between here and there: - the existing report is hard to customize (generally true...) - the existing HTML engine cannot represent basic modern formatting features (HTML > v3, CSS at all) - HTML element creation via the reporting infrastructure only knows to emit basic HTML 3 constructs. - exporting is done *through* GtkHTML, which will munge any "complex" HTML+CSS embedded in the output. This last point is important, because it means we can't even have the current reports generate "modern" HTML+CSS for export that gtkhtml could display in a degraded capacity. One more direct solution would be to have Export not use gtkhtml, but instead to serialize the original report-generated document, which could be enhanced to emit HTML 4 + CSS, and maybe have a "downsampler" between that document and the input to GtkHTML. There's a fair amount of work there. All that being said, it's not just a case of having an external browser, but of some substantial changes to the way reports are architected. I'm hoping to detail how I think that should work in the coming months. -- ...jsled http://asynchronous.org/ _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
