[ Return to Bugs & Features ]
|Status:||1 - Closed w/Resolution|
|Priority:||3 - Moderate, e.g. unable to compile the software|
|Scope:||3 - Applies to all machines and operating systems|
|Summary:||Printing a window may be incorrect with the plastic scheme|
Trouble Report Files:
Trouble Report Comments:
09:57 Feb 17, 2020
|To reproduce the problem: |
Uncomment the first statement in main() of test/device.cxx to get
Then print to a .ps or .pdf file to save paper.
The plastic background of the main window does not appear in the
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
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
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.
10:08 Mar 03, 2020
|Fixed in Git repository. ||
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.
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.
[ Return to Bugs & Features ]