STR #3534

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features ]

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:


Name/Time/Date Filename/Size top right image
 
#1 manolo
09:57 Feb 17, 2020
plastic-print.patch
1k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#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.
 
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.