public void layoutAndMeasureView(View view, int viewWidth) { int measuredWidth = View.MeasureSpec.makeMeasureSpec(viewWidth, View.MeasureSpec.EXACTLY); int measuredHeight = View.MeasureSpec.makeMeasureSpec(ViewGroup.LayoutParams.WRAP_CONTENT, View.MeasureSpec.UNSPECIFIED); view.measure(measuredWidth, measuredHeight); view.layout(0, 0, view.getMeasuredWidth(), view.getMeasuredHeight()); view.requestLayout(); }The viewWidth parameter should be the width of the printer. For Clover's supported printers that's either 576 or 384 (pixels). Knowing which to use requires you to know to which printer your print job will target. If you plan on providing an explicit printer when you call print() on your print job (not typical), you can first look up the TypeDetails for that printer with PrinterConnector.getTypeDetails(), and inspect the resulting TypeDetails.getNumDotsWidth().
@Jeffrey Blattman - We are little late to comment. But we were hitting this in latest SDK even with layoutAndMeasureView inside the SDK. This is because view may not be completely laid out and ready for measurement. This was common if WebView is used. Simple native Android layouts also throw this, but if we wait for the rendering to be done, success rate is much better.
I don't see anywhere in our code where we wait for layout and measure to complete or otherwise give it extra time. It's *possible* that the timing is just such that gets enough time to do it's work before we try to turn it into a bitmap, but seem unlikely. Seems like an easy theory to test.
Sure, for a web view you'd need to wait for the page to load before trying to print the view. There are callbacks for that on the web view client listener. I haven't tested the specific of it though.
For testing you can also turn the view into a bitmap yourself, then print the bitmap instead of the view (ImagePrintJob). That way you can write the bitmap to a PNG and inspect it just to see exactly what you are sending to the printer.
2 People are following this question.