Steps to reproduce: 1.Print an invoice 2.In Options, set some items in the header to the right 3.In Options, unselect several columns from being displayed 4.Observe that the entire invoice (including header) shrinks in width rather than filling the page. Expected result: Regardless of the visible columns, the entire page width should be used for at least the header and footer elements or everything gets scrunched A simple quick-fix would be to change the following in the default CSS block in Options > Layout: .entries-table > table { width: 100% } to simply: table { width: 100% } This is because the entire page is contained in a table and this will force it (and others) to take up the full width they need. A user can still specify an individual width for the entries-table and even center it if desired. A better, long term solution would be to not to use tables for layout and only use them for tabular data. Floats are already being used for the header with their individual tables being contained in divs. Just ditch the table part of the HTML for those items and float (and size if needed) the divs.
It would be good to have a diff between current invoice output and desired invoice output. I'm sure you realised that the CSS input was offered as a free-form customisation option for anyone wishing custom invoices, and especially useful to merge the previous easy-invoice fancy-invoice printable-invoice separate reports. However now I realise that if we modify the invoice elsewhere using divs or whatever, the CSS input now becomes a backward-compatibility nightmare :(
(In reply to Christopher Lam from comment #1) > It would be good to have a diff between current invoice output and desired > invoice output. > > I'm sure you realised that the CSS input was offered as a free-form > customisation option for anyone wishing custom invoices, and especially > useful to merge the previous easy-invoice fancy-invoice printable-invoice > separate reports. > > However now I realise that if we modify the invoice elsewhere using divs or > whatever, the CSS input now becomes a backward-compatibility nightmare :( Which means we should in principle only make such changes in major releases. Exceptions would be fixing major bugs.
Created attachment 373387 [details] suggested patch result although patch fixes for A4 PDFs, it makes the report rather unattractive on screen.
I can mock up a semantic HTML skeleton, leaving the only table for the actual invoice data. (for the next major version) Yes, I was aware of the CSS input, as that is how I played with it to find that solution. See this thread: https://lists.gnucash.org/pipermail/gnucash-user/2019-September/086848.html Unfortunately John didn't send all those screenshots to the list, but I've added the one showing what happens when you remove columns and don't resize the table. Per Comment 3, I see what you mean about screen viewing. If someone were using a large screen and had GC maximized it would look pretty silly. (though if they had a really long description, this would happen anyway) There might be a solution for both but since my own stylesheets are modified, I'll need to play around with a test book. Otherwise, maybe if someone wants to alter the default visible columns, they'll simply need to also play with custom CSS to make it look the way they want to. (thanks for that work by the way)
Created attachment 373388 [details] Example report with current main-table having unset width
I think the something like the following does the trick. And this is very very likely bad CSS. I cannot remember why .entries-table table needed the 100% in the first place. This must belong to master for reasons above. @media print { table { width:100% } }
Adding the "@media print { table { width:100% } }" rule does fix this satisfactorily IMO. Also IMO it *could* go to maint. Not many users will change CSS. It's nicer that the default report options show expanded table in portrait printouts.
Is there only one table in the invoice reports ? If not, do we really want all other tables to expand to full width as well ? If the answer is two times yes, this is a proper fix. I especially appreciate it's only applied for print output. Finally @Adrien - does webkit1 understand the @media switch ? As you are on Macos you are in a position to verify this. That is, if you add this snippet to the custom css, will the table expand properly only in the pdf output and not in the on-screen display ?
As it turns out, "@media print { .main-table > table { width:100% } }" is a more precise fix. It also works magically on Windows' libwebkitgtk1 -- both on File -> Export as PDF, and File->Export->Export Report, open in Firefox, and print.
Then that's even better :)
This works for print: @media print { .main-table > table { width:100% } } It works with or without the .entries-table declaration. (because you're setting width higher up the cascade, it filters down) This does not in all cases: @media print { .main-table > table { width:100% } } That works with the .entries-table rule for Export as PDF, (but not without it) and fails as Export Report to HTML. Sadly I can't test an actual print for either rule as my physical printer is down at the moment.
Quote Jack Sparrow: "Now you're not making any sense at all" I have never printed from gnucash reports at all but either removing or inserting .main-table doesn't seem to matter at all. I'd add it for the precision.
Sorry, I realize now my copy/paste failed. What I meant to say was that: This works for Export PDF and Export HTML: @media print { table { width:100% } } This does not: @media print { .main-table > table { width:100% } }
Both types do work for me. What's the issue including .main-table?
I'd like to finalise this issue. Could you let me know what's the issue with .main-table please?
I've merged in maint. If there are further issues please reopen or file a new bug.
