STR #3534: Printing a window may be incorrect with the plastic scheme

STR #3534

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Printing
Summary:	Printing a window may be incorrect with the plastic scheme
Version:	1.4-current
Created By:	manolo
Assigned To:	manolo
Fix Version:	1.4.0
Fix Commit:	8f142b938ae5bbbb5a7677f1a7e71ee6308a7589
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	manolo 09:57 Feb 17, 2020

plastic-print.patch
1k

Trouble Report Comments:

#1	manolo 09:57 Feb 17, 2020

To reproduce the problem: Uncomment the first statement in main() of test/device.cxx to get Fl::scheme("plastic"); Run test/device Click "Fl_Printer" Click "GO" Then print to a .ps or .pdf file to save paper. The plastic background of the main window does not appear in the "printed" file. The cause is that Fl_Tiled_Image::draw() calls Fl_Window::current() to identify which window contains the Fl_Tiled_Image being drawn. This works well when the draw operation goes to the display because Fl_Window::make_current() has necessarily been applied to that window before any drawing is done. But this fails when the draw operation is to another drawing surface, such as the printer, because Fl_Window::current() is set to the last window drawn on the display, not to the window being printed. The attached patch should fix that problem, by making Fl_Window::draw() temporarily set Fl_Window::current_ when the drawing surface is not the display. The patch would hopefully also satisfy the comment // This should be fixed! (AlbrechtS, 01 Mar 2015) waiting at line 172 of src/Fl_Tiled_Image.cxx Comments?

#2	AlbrechtS 09:39 Mar 03, 2020

I tested your patch and it worked for me - printing to a PDF file using Linux Mint. Feel free to commit. Hint: there's no need to edit test/device.cxx, you can run it with $ test/device -s plastic

#3	AlbrechtS 09:44 Mar 03, 2020

Regarding my comment in src/Fl_Tiled_Image.cxx: no, the issue is not fixed by your patch. The comment says "The latter can not be checked here..." which refers to "... or widget", i.e. we don't have the widget size in this context. The documentation above states: "Tiled images can be used as background images for widgets and windows ..." and "If both \p W and \p H are 0 the image is repeated as often as necessary to fill the entire window" (which should, BTW, read "the entire window or widget, respectively). So, the "trick" is, if both W and H are zero we always fill the entire *window* and rely on clipping set correctly if only a particular *widget* should be filled. The problem arises only if a program calls Fl_Tiled_Image::draw() to fill a widget and sets W and H to 0 (zero). Well, this is likely a pathological case. Maybe we should disallow this, but as the documentation says, it's legal right now. This is just for clarification. If this is not an issue for you to be discussed further, feel free to apply your patch and close this STR. TIA.

#4	manolo 10:08 Mar 03, 2020

Fixed in Git repository.

#5	manolo 10:13 Mar 03, 2020

The doc says If both \p W and \p H are 0 the image is repeated as often as necessary to fill the entire window, unless there is a valid clip region. If you want to fill only one particular widget's background, then you should either set a clip region in your draw() method or use the label alignment flags \p FL_ALIGN_INSIDE|FL_ALIGN_CLIP to make sure the image is clipped. From this, my understanding is that, when W and H are initially 0, it's correct to set: W = Fl_Window::current()->w(); H = Fl_Window::current()->h(); X = Y = 0; also if only a widget is to be painted because the limitation to the widget's area is done by the clip mechanism, not by setting X, Y, W and H adequately for the widget.

#6	AlbrechtS 14:09 Mar 03, 2020

Yes, you are absolutely right according to the current wording of the docs. I agree after reading it again. But I had in mind that I wrote this documentation to describe the current status - which was not optimal and I would like to address this later. It's still something worthwile to think about. But for now it's fine. Thanks for your comment.