Announcement

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

    showPrintPreview() not honoring layout widths

    I am having issues with the widths of my components/layouts not being honored when using Canvas.showPrintPreview(). It results in what looked nice in the webapp being misaligned when printing.

    Below is a self contained code example that shows the issue. I have an HLayout, containing a 16px wide image, and a 200px label. It nicely shows the label immediately adjacent to the image, each sized precisely. When Canvas.showPrintPreview() is called with the HLayout, the components are displayed using a table, but with table data (column) sections that have no widths. This results in the image being displayed in a cell that is 132px wide, and the label taking the remaining space. The label is no longer adjacent to the image.

    Code:
    package com.smartgwt.sample.client;
    
    import com.google.gwt.core.client.EntryPoint;
    import com.smartgwt.client.widgets.Canvas;
    import com.smartgwt.client.widgets.IButton;
    import com.smartgwt.client.widgets.Img;
    import com.smartgwt.client.widgets.Label;
    import com.smartgwt.client.widgets.events.ClickEvent;
    import com.smartgwt.client.widgets.events.ClickHandler;
    import com.smartgwt.client.widgets.layout.HLayout;
    import com.smartgwt.client.widgets.layout.VLayout;
    
    public class PrintLayoutIssue implements EntryPoint {
    
    	public void onModuleLoad() {
    
    		VLayout example = new VLayout();
    		example = new VLayout();
    		
    		final HLayout header = new HLayout();
    		header.setHeight(20);
    		Img opener = new Img();
    		opener.setSrc("[SKIN]/SectionHeader/opener_opened.png");
    		opener.setHeight(16);
    		opener.setWidth(16);
    
    		header.addMember(opener);
    		Label label = new Label("Title goes here, next to the image");
    		label.setHeight(20);
    		label.setWidth(200);
    		header.addMember(label);		
    		
    		IButton button = new IButton("Print", new ClickHandler() {
    			@Override
    			public void onClick(ClickEvent event) {
    				Canvas.showPrintPreview(header);				
    			}
    		});
    		example.addMember(button);
    		example.addMember(header);
    
    		example.draw();
    	}
    }
    I would expect the td width attributes of the generated table in the html used by print preview to be specified as the width of the components contained in the HLayout.

    I'm using the SmartGWT EE 3.1d nightly build from 7/27/2012:
    SmartClient Version: SNAPSHOT_v8.3d_2012-07-27/Enterprise Deployment (built 2012-07-27)

    GWT is version 2.4.0.

    I've been able to reproduce the issue in Firefox 13.0.1, Safari 5.1.7, and Google Chrome 21.0. I'm Running on Mac OSX 10.6. The issues occurs in hosted mode and deployed.
    Attached Files
    Last edited by cjustice; 6 Aug 2012, 10:26. Reason: Clarification

    #2
    Unfortunately, we have little control over printed HTML - we don't even know how many pixels or what page size we are rendering for, so by design we write a minimum of sizes and give the browser room to do it's usual heuristic layout.

    In this case the best handling is probably to shift your separate Img component for an icon for the Label. This makes your intent clearer and will result in a nested table that will keep the image close to it's text.

    Comment


      #3
      This would also be faster (for both print and normal rendering) than using an HLayout, Img and Label.

      Comment


        #4
        Thanks, I will try that for this particular instance.

        I'm seeing similar behavior elsewhere when two components are side by side with specified widths. When showPrintPreview() generates the HTML under the hood, it isn't possible for it to use the widths of the components from the HLayout in the td parts of the table? In this case you have the exact sizes of the components.

        Thanks!

        Comment


          #5
          Not really - think of the case of two components on a 1600x1200 screen with a large empty space in the middle. Assuming a typical A4 page you want the empty space to disappear when printed, so you want the browser to decide that based on the HTML content of the components and it's potential to be wrapped, etc - tossing the widths being used from the rendered screen into the HTML is likely to do more harm than good.

          Comment

          Working...
          X