No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Issues with listgrid print preview.

    I have a listgrid with a couple of columns, where one is "note" and can be very large. When there is a lot of text, the columns becomes so big so that the other columns are squeezed together. In the grid itself this is not an issue, since i call setWidth on the other columns, and that is respected.

    However, in the print preview this is not the case, and the other columns are shrinked so that there's for example wordwrap on datetimes.

    I have tried setting wrap to false, tried setting minwidth on all other columns, but nothing works. If i do setWidth in CSS manually using firebug it works.

    So, this is my question: Is there any way for me to specify that a specific listgrid column should have a minwidth attribute that makes it into the print preview?

    As an aside, i noticed that the print preview is not resized when the window is resized. Is this by design? It looks kind of strange.

    We don't try to control the widths of columns in the print preview and just let browser heuristics kick in, because we don't really know the target overall width for what's being printed, so we don't know how to allocate sizes to columns. You didn't mention which browser - which is it?

    When you refer to these settings you've tried, are you referring to grid settings or manipulating the HTML after the grid has generated it? The former would not be expected to work, since the printed HTML doesn't use those settings. But the latter approach should work if you want to try to inject additional settings to influence printing. You could also have a CellFormatter that detects that printed output is being asked for, and adds a containing <span> or <div> to the cell contents to influence the wrapping width or turn off wrapping for other columns.


      Thanks for quick response!

      When i mention i tried minwidth, wrap to false etc, that is the grid properties, via java code. This does not seem to work.

      However, if i use FireBug in Firefox on the print preview, and manually add a CSS "minWidth" property on the column, it works, so technically it seems to me that it should be possible for it to work.

      So youi mean that i could manually add the minwidth property in the java code? Not sure how i would do that.


        Right, both of our suggestions above would be modifying the HTML - one after calling getPrintHTML() (e.g.: search and replace) and the other via a CellFormatter that behaves differently when printed HTML is being generated.


          Ok, how does a cellformatter know that it is printed html that is being generated?


            Canvas.getIsPrinting() will return true


              I am not sure what is best: to create a new topic or ask here but here is goes...

              1. What is the possibility to maintain the columns widths for the generated print html? Also how to keep the columns header height?
              2. The height of rows for treeGrids are not equal. The height for a non-leaf node is slightly bigger that the one of a leaf. Way is that and how can that be fixed?


                #1 was covered above:

                We don't try to control the widths of columns in the print preview and just let browser heuristics kick in, because we don't really know the target overall width for what's being printed, so we don't know how to allocate sizes to columns.
                We do not try to control sizes on printed output, because we have no idea what the target environment is, and we don't want to clip anything. If this isn't right for whatever you plan to do with the output, perhaps you want a screenshot instead?

                #2 please let us know how this can be reproduced. If you can't do it by pointing to an online sample, then please be very specific about browser, OS, skin, density, whether you have customized the skin or applied formatters, etc.


                  #1 We want the user to arrange the order and the size of the columns and to print them as they are. It is up to him to arrange them in such a way to fit their paper size... I understand that you are not aware of the target environment but this would not be a problem if the user prints on an A1 size for example. A screenshot is limited to the screen size hence this is a no go.

                  #2 The treeGrid uses horizontal and vertical lines with Entreprise skin and no customisation. The height difference appears because of the collapse/expand icons for non-leaf nodes. I shall try to reproduce in your showcase and get back on this...


                    OK for #2 please go to then change to Enterprise skin and Dense density. Then hide the Title column to avoid word wrap and hit print. In Print Preview if you inspect the rows you will see a 26 height for non-leaf versus 22 height for leaf.


                      #1 as we mentioned, we don't want to clip anything in a printed view, so any column widths we might set would be at best advisory. If you are looking for fixed columns and clipping, then you presumably do not want the printed view.

                      #2 All of the content is within a single HTML table, so nothing is misaligned. Are you saying that if you look into the DOM, the height of the content is taller for some cells? That's simply because the image plus text is taller than text alone. That's normal, and there does not appear to be an impact - is there something you're saying is visually wrong here?


                        We have a custom component with a treeGrid on the left and a chart on the right separated by a split. Currently there is no possibility for browsers or third party components to split large horizontal html content on multiple pages. Or at least I could not find one... They are able to split content only vertically. Horizontally the content gets clipped. Hence trying to squeeze the content horizontally does not help at all since the table might have so many columns that it still does not fit on an e.g. A4 page and it will get clipped anyway. Plus we also have the chart hence the only possibility is for the user to print on higher page formats (A3... A1) in .pdf and then split the .pdf in A4 format.

                        Now back to smartGWT...
                        #1 Since packing the columns does not help us at all then why not letting the user to keep the settings... How can we do that?
                        #2 The chart and the treeGrid are synchronised. If the rows height is not consistent then we can not make any computation anymore... In print preview it seems the height consistency gets broken. What can we do to fix it?


                          You can rearrange your screen immediately before printing, and that's likely what you want to do here. You can just move it back to side by side after printing.

                          #1 we don't understand what "keep the settings" means here

                          #2 we don't follow - are you saying your chart is actually pointing to TreeGrid rows or something similar?


                            I do not understand what you mean by rearrange the screen. Also how do I know when the printing is over or the user closed the print preview window?

                            #1 By keeping the settings I mean keeping the column widths and the table header height. For example you are keeping the "text-align" attribute for column headers so why not other attributes... I can not adjust the printed HTML in this case as suggested to mathias because there are no identifiers to search for them and replace them.

                            #2 Exactly. They are synchronised. For each row we are drawing an extension of it and some more graphical details. Because the height is not constant anymore the grid and the chart do not match anymore. See attached image to better understand.
                            Attached Files


                              Rearrange the screen meaning place the chart vertically under the TreeGrid. This particular strategy won't work for your use case, but in general, you can do this sort of thing: change settings, move components around, or even generate an entirely different screen for printing. Read the Printing overview: Print Preview is just a trivial Window created around the result of getPrintHTML(), you can replicate that with a few lines of code.

                              #1 again, we keep saying this: we're not going to clip the printed output so column widths cannot be maintained.

                              #2 so the browser is sizing the row based on the largest cell, and in your chosen skin and density, a cell with an icon is taller. if this only happens when the title column is hidden, just show it before printing.