Hello,
While the Grouping field works perfectly on the view, it does not group by correctly on the PDF page.
The same field is selected in the View Table settings and in the PDF Page Table settings (Grouping field).
Am I missing something?
See attached screenshots
Thanks!
Anne Marie

Comments

subscribe for version 7.x-1.0-rc1 as well

StatusFileSize
new14.79 KB

I've rolled a quick & dirty patch to get the grouping field working in one use case (simple category headings for a table view on a two-page document), but this is against the latest 7.x version from Git, not 6.x-1.0.
There didn't seem to be a simple bug to fix; there is already a function views_plugin_style::render_grouping in the base class, but this wasn't being used at all, and PdfTemplate::drawTable needed refactoring so that it could produce multiple sub-tables (one for each grouping) while still tracking the overall position within the document. At the moment I've not added anything to the UI to style the group headings, and the updating of numberOfRecords in views_pdf_plugin_style_table::render is almost certainly wrong. It might be better to do some more drastic refactoring, affecting PdfTemplate::renderRow as well, before trying much more with this.

If "drastic refactoring" is needed would it be better to have individual pdfs per grouping? As in we would have a HTML page of multiple tables according to their grouping field. Under each table would be their pdf icon for a printout of that group. I understand that if the current function was working for 6.x it would print one page that contained all the groupings. I can see how my suggested change could be done by a views exposed filtering form as well. But, setting it up to separate by grouped field might have other benefits in the long run.

Also is someone working on the 6.x patch or should the Version be changed to 7.x to reflect this discussion better?

I can't speak for the maintainers, but it seems as if a hybrid HTML-PDF approach isn't just a refactoring, but a different module from Views-PDF (but of course that might be a desirable thing in itself, if someone wanted to work on it). If I update the patch I'll change the version here to 7.x, but an update depends on having some way of checking that it doesn't break the existing behavior of the module in unexpected ways.

Subscribing

I'm tryin to replicate the behaviour of normal views where i list content (products) grouped by taxonomy terms (category) hiding the taxonomy term in the field section and just setting it as a group field but as a result the category is not printed on pdf.
Using 7.x dev version.
Is there anything new on this issue?
Is the above patch working somehow?

Zik

Version:6.x-1.0» 7.x-1.x-dev

StatusFileSize
new15.74 KB

The previously posted patch no longer applies cleanly, so here's a revision against a recent clone of the 7.x-1.x branch.
Most of the commits since the original version didn't conflict with it directly.

commit aec75710db3dce6a112e9f23ece5a503f5275d99
Author: Christian Steiger <e-mail@christiansteiger.eu>
Date:   Wed Feb 1 15:12:27 2012 +0100
Issue #1280394 by Zuzuesque: fixed by applying the patch http://drupal.org/node/1280394#comment-5434618

was the one real conflict, and the commit to fix #1252660: Weird stuff with table view was duplicated.

Status:Active» Needs review

Patch needs review.

I found this issue because I got many errors in my log, similar to this:

Notice: Undefined index: eval_after in PdfTemplate->renderRow() (linea 506 di /home/sapories/domains/saporiesapere.it/public_html/shop/sites/all/modules/views_pdf/views_pdf_template.php).

Has this error something to do with this issue? Something about rows rendering that module isn't able to do?

Since the issue has been moved to the 7.x branch, then 6.x users might be interested in a workaround.

Generally speaking, it seems like a duplicate effort to produce a PDF document of the same content in a HTML page. I mean wouldn't it be nice to just to be able to use a regular Drupal theme to style the PDF? Shouldn't all browsers just have a "Save as PDF" function that works the same way as an embedded HTML "Print" button does now?

Anyway, the workaround I have used is to install the "Print pages to PDF" plugin for Firefox. We don't have many users, so this is an acceptable solution for us for 6.x. I used the Sections module to specify a PDF friendly theme (e.g. Marvin) and customised the style.css with the CSS attribute "page-break-before: always;" on h2 headings. Crude but effective.

/Kevin

So, the verdict is that grouping doesn't work at all for PDF Unformatted or for PDF Table, and the patch doesn't help?
This is a great module in many ways, but this is a show-stopper for most of what I'm trying to accomplish.

StatusFileSize
new3.84 KB

Here is a new patch. I haven't done extensive testing, but it groups rows in my case...

StatusFileSize
new5.85 KB

Another version of this patch, with improved grouping support.

Component:Miscellaneous» Code
Priority:Normal» Major
Status:Needs review» Needs work

I'm just moving to needs works, Cause I have to reorder the issues. That doesn't mean the patch doesn't work. Is just to start making progress to fix the module.

Priority:Major» Normal
Status:Needs work» Fixed

Lets try the guillaumev solution other solution for this user work so seen good to me. Commited.

Please reopen this issue if this doesn't work.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Needs review
StatusFileSize
new480 bytes

Reopening this as I've found out that the grouping fields don't show up when combined with this patch:

https://drupal.org/node/2032863

Here is a patch that fixes this issue.

Need to be an is_string? could be !empty ?

+    if (($key !== NULL && $view->field[$key]->theme($row)) || is_string($row)) {

It's not better to be if (($key !== NULL && $view->field[$key]->theme($row)) || !empty($row)) {

Hi everyone,

first of all, THANKS for such a useful module.

Not that I would have a solution to the above discussed bug, however I do have a workaround that works quite fine for me (not ideal, but it does do the job).

Scenario:

Every day a list of delivery dockets must be printed for each order. Every delivery docket must be listing all the ordered products. So Ideally, I would group all the products from the same order and place a PDF page break after this group. (but that doesn't work).

Workaround:
1/ install http://drupal.org/project/views_field_view
2/ create a view (single_docket) listing all the products for an order (this view has a contextual filter which is the order ID) - chose any format for this view (table works for me)
3/ create a view (list_of_dockets) which is simply a list of all orders that need to printed as single dockets.
4/ add a field: Global View - using the module mentioned in point #1, and add pass the order ID from each row to this embedded view as an argument.
5/ create PDF page, set it all up as usual
6/ place a pdf page break after this Global View field

Now, what happens is that "list_of_dockets" simply prints out all the orders, each order/row on a single page (thanks to the pdf page break), but at the same time, it runs another "nested" query for each row, which returns the list of products (single_docket)

If it is not clear either ask or just read documentation for views_field_view module.

However, this is merely a workaround. Not a solution to the bug.

I just commit the patch. In a few hours will be able to download in the dev branch. Test it and see what happen.

I didn't reply the scenario. I'll tomorrow

Version:7.x-1.x-dev» 7.x-1.1

I have figured it out.

Version:7.x-1.1» 7.x-1.x-dev

Thauk.

Keep this in dev stage. You still have some problem?

My view doesn't even use grouping but I get this notice:

Notice: Undefined offset: 0 in render_grouping_sets() (line 48 of /.../views_pdf/views_pdf_plugin_style_unformatted.inc).

Mikran can you please submit some patch for this.

Thanks :)

Issue summary:View changes
Status:Needs review» Active

If this issue generate an extra notice. Please open a new issue. The functionality of this issue is working.

Status:Active» Fixed

#2042927: notices in style unformatted fixed the notice I was getting (comment #25).

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

#21 works well for me. Basically create the first view with the header/grouping info you need, then insert the rest of the information (from a separate view) as a view field.

Version:7.x-1.x-dev» 7.x-1.3
Status:Closed (fixed)» Needs work

If the format is PDF Table grouping field still doesn't work. I looked at patch in #14 and only views_pdf_plugin_style_unformatted.inc was updated.