bugGNU Octave - Bugs: bug #44187, Bugs and modifications in print()...

 
 

bug #44187: Bugs and modifications in print() with gnuplot graphics toolkit

Submitted by:  Dan Sebald <sebald>
Submitted on:  Wed 04 Feb 2015 09:39:05 PM UTC  
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Dan Sebald Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sat 27 Feb 2016 02:43:15 AM UTC, comment #83:

Works for me. Closing report.

Rik <rik5>
Project Administrator
Sat 27 Feb 2016 01:26:06 AM UTC, comment #82:

Ok. I admit to lingering hesitation to push the change, but .... I suppose now is a good time. There will be ample opportunity to detect new bugs before a release will include this change.

http://hg.savannah.gnu.org/hgweb/octave/rev/5b9618f4f841

This is the last of the patches. If my push looks ok, then this can be closed.

Ben Abbott <bpabbott>
Project Member
Sat 27 Feb 2016 12:46:10 AM UTC, comment #81:

I was more optimistic that it was something small. There was a lot that has to be correct because onscreen rendering is correct.

I reverted this one change and printing now works for me.

I've uploaded the new patch for testing.

(file #36482)

Rik <rik5>
Project Administrator
Sat 27 Feb 2016 12:12:59 AM UTC, comment #80:

Ok. I suppose that settles my hesitation for now. Until I, or someone else, has the time we'll just leave things as they are.

Perhaps this should be closed?

Ben Abbott <bpabbott>
Project Member
Fri 26 Feb 2016 10:26:27 PM UTC, comment #79:

@Ben: I just tested your final patch for this bug report (in comment #78). The patch applies cleanly and onscreen plots work. But printing with gnuplot to ps, pdf, png no longer works. I do still get correct results if I print to svg format. I don't know what that implies, but hopefully it is a useful clue.

Rik <rik5>
Project Administrator
Thu 24 Dec 2015 06:27:21 PM UTC, comment #78:

I'm near the end of what I think is sensible to include.

I've prepared a patch that removes the color/mono syntax from the gnuplot toolkit specific m-files, and temporarily modifies the color of all objects instead. Since, I'm worried that this solution may run into problems due to the listeners, I'll mull over this a bit longer.

The same problem will exist for the OpenGL toolkits, so for practical purposes doing the same for gnuplot won't introduce any new bugs. But not doing it may introduce bugs that wouldn't exist otherwise.

(file #35852)

Ben Abbott <bpabbott>
Project Member
Thu 24 Dec 2015 05:45:53 AM UTC, comment #77:

@Ben: It seems like you are making great progress on bringing all these gnuplot changes into Octave. I don't know enough to help, but I can at least cheer you on!

Rik <rik5>
Project Administrator
Thu 24 Dec 2015 03:39:36 AM UTC, comment #76:

Pushed another changeset for coding improvements to _gnuplot_draw_axes_.m

http://hg.savannah.gnu.org/hgweb/octave/rev/33793796aa6e

Ben Abbott <bpabbott>
Project Member
Thu 24 Dec 2015 01:18:01 AM UTC, comment #75:

Pushed a changeset to add the "canvas" gnuplot terminal to the print.m doc-string.

http://hg.savannah.gnu.org/hgweb/octave/rev/22318eeaca3b

Ben Abbott <bpabbott>
Project Member
Wed 23 Dec 2015 11:27:34 PM UTC, comment #74:

I've pushed two more changesets

Add support for the standalone option for the gnuplot tikz terminal.
http://hg.savannah.gnu.org/hgweb/octave/rev/123da81b9176

Impproved support gnuplot terminals "eepic", "latex", "pstricks", & "texdraw".
http://hg.savannah.gnu.org/hgweb/octave/rev/984678f19352

Ben Abbott <bpabbott>
Project Member
Wed 23 Dec 2015 03:48:08 AM UTC, comment #73:

Some changes were needed to Dan's proposal for the Cairo based terminals.

http://hg.savannah.gnu.org/hgweb/octave/rev/6ac3d299c5ad

Since only recent version's of gnuplot include all the cairo terminals and
since the pango/cairo libraries are not required dependencies I modified the
changes so that cairo is not a required dependency for producing pdf/eps
output when using the gnuplot toolkit. In addition, I added the size info to
gnuplots "set terminal" command for the cairo based terminals.

The changeset I've attached does not include support for all of gnuplot
terminals which Dan had included. I will include support for others (such as
emtex/latex) in a future changeset.

Also, I have not included the demo code which Dan proposed. The demo code
associated applications with various file types. Rather than do that,
the "open" command should be used.

Ben Abbott <bpabbott>
Project Member
Mon 21 Dec 2015 04:21:36 PM UTC, comment #72:

@Ben: I think your approach is correct. It would nice to have an abstract print interface (_print_parse_opts_.m and print.m) and encapsulate the toolkit specific implementation details in separate files.

Rik <rik5>
Project Administrator
Sat 19 Dec 2015 07:23:25 PM UTC, comment #71:

I've pushed two changesets.

http://hg.savannah.gnu.org/hgweb/octave/rev/165ba7463ca9

http://hg.savannah.gnu.org/hgweb/octave/rev/793886a00c3b

Regarding the mono/color for gnuplot and the trouble with axes/figure background colors for "mono", these can easily be handled by having Octave convert from "color" to "mono" in print.m as is done for OpenGL.

Since I prefer that print.m and _print_parse_opts_.m include not toolkit specific code, I'd like fix both the mono/color problems and the background color problems by having print.m handle the color to mono conversion.

The gnuplot toolkit will then need to be modified to ignore opts.use_color. This would reduce complexity and simplify maintenance. Thoughts?

Ben Abbott <bpabbott>
Project Member
Fri 18 Dec 2015 02:16:27 AM UTC, comment #70:

Dan, Rik, Ederag, & others,

I've spent some time going over Dan's changes to the gnuplot toolkit and see many attractive things there. In its current state, i don't think I'm able to reliably
review the changes and debug problems that may surface later. Hence, I am encouraging those interested to assist in breaking up this large contribution into several changesets. Our coding practice encourages separating independent changes into different changesets. I estimate Dan's contribution may be split up into 10 changesets.

I'm attaching ChangeLogs.txt which includes a proposal for splitting up Dan's patch.

(file #35786)

Ben Abbott <bpabbott>
Project Member
Thu 17 Dec 2015 08:12:53 PM UTC, comment #69:

@Ben: Yes, this is icky. I used graft, rather than transplant, because it uses 3-way merging which can be easier to see what is going on. It wasn't so hard to graft the extension back on the stable branch, but when I tried to re-merge it forward on default it caused all kinds of mismatches. I think we should do nothing and just leave the documentation on stable as is.

Rik <rik5>
Project Administrator
Thu 17 Dec 2015 07:52:41 PM UTC, comment #68:

@Rik,

My hg is a bit old. I tried using the transplant extension, but encountered an error.

The problem looks to be with 5b7643257978 where trailing white space was removed. Unfortunately, that won't apply due to earlier changes which introduced the trailing whitespace (and do not exist in the stable branch).

The easy thing to do is ... nothing. Second easiest is to patch stable directly without any of the graft/transplant stuff, but I don't know how that will impact the archive. For example, will that make the next merge from stable to default more complex?

Ben Abbott <bpabbott>
Project Member
Thu 17 Dec 2015 07:13:45 PM UTC, comment #67:

@Ben: Changes to documentation are always allowed on the stable branch since that won't upset backwards compatibility. And it is usually the case that changes to the documentation are an improvement which clarifies something. With all that background in mind, I would say it is quite acceptable to update genpropdoc.m on the stable branch.

Rik <rik5>
Project Administrator
Thu 17 Dec 2015 07:00:32 PM UTC, comment #66:

@Rik,

After more thought and experimenting with the paper* properties, I've opted to leave the current implementation as it is and have modified genpropdoc.m for the default branch to indicate the changing orientation will trigger an update to the paperposition property. What are your thoughts, should the three changesets for genpropdoc.m be merged into stable?

Ben Abbott <bpabbott>
Project Member
Tue 15 Dec 2015 10:03:56 PM UTC, comment #65:

@RIk, Octave isn't compatible with how it handles paperposition, so I'd avoid changing the docs for stable. I hope to have a chance to work on that this week. If I can get go it soon enough, then I'll push to stable.

Ben Abbott <bpabbott>
Project Member
Tue 15 Dec 2015 09:58:50 PM UTC, comment #64:

@Ben: In comment #47 you asked for a review of a documentation patch. I found a typo, "pizel", that should be "pixel". In order not to go back and forth too much I just committed the small changes to the development branch (http://hg.savannah.gnu.org/hgweb/octave/rev/c640ea6a1612). If you wanted to backport the improved documentation on the default branch to stable that would be okay too, but a bit of work.

Rik <rik5>
Project Administrator
Tue 15 Dec 2015 09:18:46 PM UTC, comment #63:

I narrowed down the bug #46292, and hopefully found a better way to show why it is indeed a bug. Please see there.

ederag <ederag>
Tue 15 Dec 2015 02:16:02 PM UTC, comment #62:

That GL2PS associates an on screen pixel with a hardcopy "point" was a design decision by the developer. It is not a bug.

Octave's implementation of print() chose to share as much code between the various graphical toolkits as possible. This was done to simplify complexity and maintenance. I looked at 46292. The problem isn't with Octave. I'll reply further on that bug report.

Ben Abbott <bpabbott>
Project Member
Tue 15 Dec 2015 09:28:34 AM UTC, comment #61:

To me it was clearer to work with the true sizes, and workaround the GL2PS bug (pixels interpreted as points) only where GL2PS was involved.
Just a warning before you push:
I wonder if you are considering the whole picture, including fixing bug #46292 too, that concerned OpenGL, and all the font/line/marker size problems ?
Because this is what drove me into making all these small changes. And please believe that every one has been pondered.

ederag <ederag>
Tue 15 Dec 2015 03:10:37 AM UTC, comment #60:

I located where the incorrect scaling of the figure size for gnuplot was introduced. And will push a change tomorrow. It will be a small changeset and should not impact OpenGL.

Ben Abbott <bpabbott>
Project Member
Tue 15 Dec 2015 12:35:54 AM UTC, comment #59:

@Ederag/others,

i've started reviewing more changesets. Unfortunately, most of them are making changes in the wrong places. The function _print_parse_opts_.m and print.m is where most of the heavy lifting is intended to be done. The _XXXXX_print_.m functions were intended to be kept as simple as possible (to avoid duplication of code). Since the gl2ps library renders a point (i.e. 1/72 in) for each pixel, the print_m function used to scale everything appropriately. Maybe that is broken now (I haven't gotten that far yet).

Ben Abbott <bpabbott>
Project Member
Sun 13 Dec 2015 10:51:35 PM UTC, comment #58:

I'm running the default branch, and the size of the eps-files do look to be called by 72/sceenpixelsperinc (which matlab says is 90, but Octave says is 129).

It is frustrating that during the year I was unable to build on MacOS, changes were introduced which deviated from the consistency in the implementation for OpenGL and Gnuplot printing and introduced the many gnuplot bugs. Unfortunately, after those changes were introduced the directory structure for script/plot/* was changed and the history of what was done is no longer easy to figure out from the mercurial archive (I'd really like to back all the stuff out that broke things and then introduce change sets that accomplish the desired result without breaking the earlier/cleaner/easier-to-maintain implementation)

Ben Abbott <bpabbott>
Project Member
Sun 13 Dec 2015 09:28:28 PM UTC, comment #57:

Dear Ben, the following script passes fine here (all green, and the generated files look fine).
This is with the patches, merged with 20741:a5ab31b52ae8, as described in comment #48.

What's the outcome of this script for you ?
You'll need the cprintf function described there:
https://savannah.gnu.org/bugs/?46292#comment10

If this happens without patches, then maybe you are hitting the very printout size bug that the patches intend to fix ?
With octave-4.0.1-rc1 the sizes are too small, indeed (screenshot of the tests attached). they are reduced in a
72 / screenpixelsperinch ratio. Here:
get(0 ,"screenpixelsperinch") => 107.48

I'll have some time tomorrow at lunch time and more in the evening. Please give more details.

(file #35731, file #35732, file #35733)

ederag <ederag>
Sun 13 Dec 2015 08:04:04 PM UTC, comment #56:

@ederag/others

I've pushed a few changes that allow be to build the docs using Gnuplot (when osmesa is not present). The resulting gnuplot figures are undersized. Is this a bug you recognize?

Fixing this problem is my top priority. So, I prefer to fix that first, but may push a few other minor changes in the meantime. At the moment, I'm surprised this is broken and am not sure where/when the bug was introduced. Any help would be appreciated.

I've begun browsing the other proposed patches. There are often several unrelated changes in a single changeset. It will be necessary to break those up prior to committing. And since some of the proposed changes deviate from Matlab compatibility, I won't be committing them until a wider agreement is reached that includes the behavior of the OpenGL toolkits.

Ben Abbott <bpabbott>
Project Member
Sun 13 Dec 2015 03:32:26 PM UTC, comment #55:

@Michael Discarding provided patches lightly is quite a sure way to get only bug reports, no patches any more.

But maybe that's the goal, only core devs ?

ederag <ederag>
Sun 13 Dec 2015 02:43:54 PM UTC, comment #54:

@Ben: OK. I just noticed this report late in its (long)
history. So, have you thought at all about the qt fltk merge?
This, it seems to me, needs to be done before much progress
can be made on the various OpenGL/mesa problems. Having
one plotting system that works well seems to me better than
three that do not.

By the way, are you familiar with the plotting in Mathematica?
The facilities that they provide can be viewed as a longer
term target. This includes animation...

In any case, it is great that you can find time to work on this!

Michael Godfrey <godfrey>
Project Member
Sun 13 Dec 2015 01:40:46 PM UTC, comment #53:

@Michael it looks like an overkill work on gnuplot, but my patches are actually trying to fix printouts for all the graphics toolkits,
including qt (and the GL2PS pixels/dots workaround)
They are a first step towards a consistent font size issue fix.
Why the discussion went here is given in comment #33.

ederag <ederag>
Sun 13 Dec 2015 01:25:49 PM UTC, comment #52:

Dear Ben, you are the core developer here (so many thanks !), and I get your point. There is some wisdom in it.

I really think we can be compatible with what is working in matlab (both papersize and paperposition, or auto paperpositionmode), and have a sensible behaviour that would be clearer for users and make the code easier to maintain.

Before taking your final decision, please follow all the links of my comment #44 and read the comment with an open mind. Hopefully you'll see the wisdom in my point of view too.

Please take your time to decide, I'm stopping there for now.

Actually, in the given patches, I stuck to the documented behaviour, so please please do not discard all this work.

And at least, remember the awesome Dan's patch.

ederag <ederag>
Sun 13 Dec 2015 12:56:25 PM UTC, comment #51:

There are a few serious regressions for gnuplot, and a few useful improvements (pdflatexstandalone for example). I hope to start pushing changes latter today.

Ben Abbott <bpabbott>
Project Member
Sun 13 Dec 2015 12:44:50 PM UTC, comment #50:

It is much more important to work on the (many)
outstanding problems with the OpenGL toolkits.

The gnuplot toolkit should be in maintenance only
mode.

If more than enough resources were available there
still would not be a case for working on gnuplot.

Michael Godfrey <godfrey>
Project Member
Sun 13 Dec 2015 12:35:56 AM UTC, comment #49:

@ederag
I don't think the intended behavior is too difficult to implement/maintain. imo, the problem is that the intended behavior isn't what would be initially expected, and those not sufficiently familiar with it introduce bugs when modifying to code. Over the years, I've introduced my share.

If you have a specific instances where you think is wise to deviate from a compatible implementation, then please place a patch on the patch tracker and raise the issue on the maintainers mail-list.

Ben Abbott <bpabbott>
Project Member
Sun 13 Dec 2015 12:24:29 AM UTC, comment #48:

@Ben
Thanks for the doc update. But, I believe to have already grasped the intended behaviour correctly.
The point I raised in comment #44 is not a mere documentation issue. It is a matter of consistency, that renders the code much more difficult to write and maintain. Even the Mathworks, with all their manpower, were not able to make a reliable implementation of it. Maybe you can, but not without a lot of time lost, IMHO.

@Rik
Two changes occurred in the last week of november. And even more with the code sprint. A merge will be needed eventually.
I did merge with default periodically, and it worked fine here.
Maybe I should have set a public repo ?

Meanwhile I propose to branch, for testing purpose:
hg update --clean 20741:a5ab31b52ae8

# wysiwyg_15c12da_bunch.hg.diff is the attached file,
# including all the necessary changesets
hg import wysiwyg_15c12da_bunch.hg.diff

# all tests pass
PASS 13440
FAIL 0
XFAIL 14
SKIPPED 77

Beware that the demo print crashes.
But after a merge with default,
hg merge -r 20881:7234cbd04292
(for the only conflict, choose the new branch),
now it is working.

Any advice for a better workflow would be welcome.

For pdflatexstandalone I'll have another patch. But the solution depends on the decision about the paper* stuff.

(file #35724)

ederag <ederag>
Sat 12 Dec 2015 09:48:11 PM UTC, comment #47:

@Rik,

Does the attached documentation change look ok? If so, I'll convert to a changeset and push.

(file #35721)

Ben Abbott <bpabbott>
Project Member
Sat 12 Dec 2015 07:44:47 PM UTC, comment #46:

I've snipped out the portion of Octave's manual documenting the paper properties and added some clarification.

I'll start work on a changeset for this.

Ben Abbott <bpabbott>
Project Member
Sat 12 Dec 2015 07:09:32 PM UTC, comment #45:

I recognize that the intended behavior of "papersize", "paperposition", "paperpositionmode", "paper orientation", & "papertype" aren't well documented and that Octave's behavior isn't always compatible with the intended behavior. Octave is in need a section of the manual dedicated to this topic. However, I strongly advice against deviating from the documented/intended behavior.

One of the reasons I've had trouble pushing patches is that my personal time is dominated by 3 toddlers and I have nearly zero time left for verifying compatibility across all toolkits, and then fixing incompatible behavior. My apologies for that. In the next week, I may have some time in the middle of the week to work on this.

If patches are constructed that maintain compatibility, and correct incompatible behavior the process of pushing them will be rather quick.

Ben Abbott <bpabbott>
Project Member
Sat 12 Dec 2015 05:38:54 PM UTC, comment #44:

From a pristine octave clone, some hunks are rejected, indeed. It looks like I missed a change in _ghostscript_.m that happened 3 weeks ago.
I'll look into that.

Meanwhile, I tried to fix some margins (paperposition) issues.
Now I think that using papersize not only for paper printing, but also for file printing would be much more consistent.
Paperposition should set the frame of the figure (the equivalent of the figure border on screen) inside the printout.

Matlab treats differently image formats and pdf formats.
http://fr.mathworks.com/help/matlab/ref/figure-properties.html#prop_PaperPosition
This is kind of weird, since pdf format could be either intended to have a margin (e.g. printing a full a4 page), or not (e.g. a figure to be included in latex). In the latter case, the sensible behaviour would be: no difference in size/positions between png and pdf.

Matlab implementation is full of bugs/strange behaviours. See for instance
http://www.mathworks.com/matlabcentral/answers/218286-export_fig-paperposition-not-considered-when-exporting-to-pdf#answer_180198
http://www.mathworks.com/matlabcentral/answers/130735-font-size-and-figure-size-when-printing-figure-to-eps
http://www.mathworks.com/matlabcentral/answers/155249-printing-a-figure-with-latex-annonations-and-readable-linewidths-to-disk
So they also have problems to create a clean implementation, with such a weird intended behaviour.

Most of the times recommendation are either to use of export_fig, e.g.
http://matlab.wikia.com/wiki/FAQ#How_do_I_save_my_figure.2C_axes.2C_or_image.3F_I.27m_having_trouble_with_the_built_in_MATLAB_functions
or to both set papersize and paperposition, e.g.
http://stackoverflow.com/questions/11261823/export-matlab-figure-as-png
http://stackoverflow.com/a/7576598/3565696
https://dgleich.github.io/hq-matlab-figs/

My conclusion: there are so many problems in their approach that we should not follow Matlab there.

We should use papersize to control the overall size of any printout (whatever the format).
The recommended way to select the printout size to [5", 3"] for inclusion in another software would be:
papersize = [5, 3];
set(gcf, "papersize", papersize)
set(gcf, "paperposition", [0 0 papersize])
To shorten things, we could define a new "paperpositionmode": "full", which triggers a change of paperposition to [0 0 papersize] whenever papersize is changed.

We could also have a "screen" papertype, that would set
"papersize" to the figure physical size on screen.
This would be a sensible replacement for the paperpositionmode "auto" of matlab.

Please note that even with this big change,
people setting both papersize and paperposition
won't see any difference between matlab and octave.

I'll be able to work on that in the last weeks of this year,
but please give me a go/no go signal.

ederag <ederag>
Sat 12 Dec 2015 01:54:01 AM UTC, comment #43:

@ederag: I tried applying the patches in the order you summarized in comment #42 but I get a lot of rejections. Has the code changed so much in two weeks, or am I doing something wrong?

Rik <rik5>
Project Administrator
Sat 28 Nov 2015 10:17:45 AM UTC, comment #42:

Objects with "normalized" units also were not to be repositioned
(of course).
Now the printout sizes are fine.

And PaperPositionMode "auto" was not a good idea since the figure size on screen is different than the PaperSize.
Both PaperSize and PaperPosition have to be specified.
This is fixed in the print demo.

Remaining glitches:
for fltk and qt, lines are too thick because of the rescaling.
Font sizes also need fixes (but now that printout sizes are consistent, hopefully font stuff should be clearer)

But please note that in the beginning, the openGL pdf printout sizes were wrong (if ScreenPixelsPerInch not 72). It is not a gnuplot fix that is breaking openGL stuff.
And Dan's print demo is useful well beyond gnuplot, so maybe the category should be changed to general "Plotting".

As a summary:
file #35293,
file #34657,
file #35406,
file #35407,
file #35437,
file #35548,
file #35550;

And the attached file

(file #35585)

ederag <ederag>
Wed 25 Nov 2015 10:04:03 PM UTC, comment #41:

If you pushing gnuplot modifications, please look also in
bug #46496

Avinoam Kalma <avinoam>
Project Member
Wed 25 Nov 2015 09:07:22 PM UTC, comment #40:

The placing of labels and title is now fixed (file #35548).

As a summary:
file #35293,
file #34657,
file #35406,
file #35407,
file #35437,
file #35548,

And the attached patches (in a single hg export) that
- add labels and legend to the demo
- set Papersize instead of paperposition,
and set PaperPositionMode to "auto".
This should be closer to a standard printout to file.

The actual printout size and position of the plots still depend on the toolkit/terminal, which is not expected.

(file #35550)

ederag <ederag>
Wed 25 Nov 2015 06:23:24 PM UTC, comment #39:

@Ben There is a glitch with texts, probably because their "units" are "data". (the repositioning needed for openGL should not be done for them). I'm working on it, but help would be appreciated.

ederag <ederag>
Wed 25 Nov 2015 04:18:06 PM UTC, comment #38:

@Ben: I have added bug #46517 as a dependency. Once you have signed off on the patches in comment #37 then the patch in that report can also be committed.

Rik <rik5>
Project Administrator
Wed 11 Nov 2015 07:02:28 PM UTC, comment #37:

Thanks Ben, here is your patch, credited to you.

As a summary:
file #35293,
file #34657,
file #35406,
file #35407
and the attached file.

(file #35437)

ederag <ederag>
Wed 11 Nov 2015 01:07:42 AM UTC, comment #36:

The switch/case block in _gnuplot_print_ was originally added (by me I think) prior to having a paperunits updater. Now that the updater is present it should be used. The specific advantage is that the papersize and paperpostion will be correctly determined for all units, including "normalized".

I haven't tested it, but something like below should work.

Ben Abbott <bpabbott>
Project Member
Tue 10 Nov 2015 10:50:40 PM UTC, comment #35:

I don't feel competent enough to review and check this in since I don't work very much with gnuplot. Hopefully Ben Abbott can verify the 5 patches listed in comment #34.

Rik <rik5>
Project Administrator
Sun 08 Nov 2015 07:03:34 PM UTC, comment #34:

The size control in Dan's patch was interfering with printing through ghostscript, but it is required for other devices.
The patch attached fixes this.

As a summary:
file #35293,
file #34657,
file #35406,
file #35407
and the attached file.

(file #35418)

ederag <ederag>
Sat 07 Nov 2015 01:51:08 PM UTC, comment #33:

The updated Dan's patch (file #34657) is really fine.
With the patch (file #35293) that fixes bug #46292,
part of Dan's patch is not required any more (and interferes).
Together with the additional patch attached, both my tests (https://savannah.gnu.org/bugs/?46292#comment10) and the demo
for png, pngcairo, pdf, pdfcairo, with or without mono, as well as pdflatex and pdflatex standalone seem fine.

As a summary:
file #35293,
file #34657,
file #35406,
and the attached file.

(file #35407)

ederag <ederag>
Sat 07 Nov 2015 11:55:47 AM UTC, comment #32:

Thanks a lot for the print demo, very useful.
Here is a patch to add the mupdf reader.

(file #35406)

ederag <ederag>
Sun 16 Aug 2015 06:15:58 PM UTC, comment #31:

I'm updating Daniel's patch to accomodate recent changes.

(file #34657)

Ben Abbott <bpabbott>
Project Member
Sun 02 Aug 2015 06:12:31 PM UTC, comment #30:

Daniel,

The demo's for print() are a nice addition. Unfortunately, most of them fail for me because the demo script is determining the applications which are to be associated with the file types and the applications hard-coded into the demo script do not exist on MacOS X.

On Mac OS X the shell command "open <filename.suffix>" is able to handle files with suffixes of pdf, ps, png, jpg, html, etc.

The changeset can be adapted by adding
just before setting the devlist in print.m.

Ben Abbott <bpabbott>
Project Member
Sun 02 Aug 2015 02:41:35 PM UTC, comment #29:

I modified the changeset and am now able to build the default branch without errors (Gnuplot is being used in replace of OSMesa). I've attached the edited version of Dan's chengeset.

(file #34567)

Ben Abbott <bpabbott>
Project Member
Sun 02 Aug 2015 12:14:54 AM UTC, comment #28:

I'm now able to build and am seeing errors for PDFLATEXSTANDALONE for the default branch. So I thought I'd try to apply the patch, but it does not apply. Some of the gnuplot m-files were recently renamed. That is the likely reason (?).

Dan, can you post an updated changeset?

Ben Abbott <bpabbott>
Project Member
Fri 17 Jul 2015 03:31:01 PM UTC, comment #27:

Creating a branch just for yourself is okay, but we wouldn't want to create one on the main repository.

Other options are to hg clone a repo and do development of only gnuplot in that directory. After you have got everything worked out, you can ask for someone to pull from that repo, or you could use hg export to collect all the csets into a single file which could then be imported into the dev repo.

In general smaller commits are easier to understand, and reverse if necessary. The commit messages are also easier because each commit is for fixing a particular problem.

Sometimes I do overhaul an m-file, and then the commit message just has to grow to cover all that was done, but if you are fixing a bug then one commit per bug is easiest.

Rik <rik5>
Project Administrator
Fri 17 Jul 2015 12:40:45 PM UTC, comment #26:

As I'm not able to build my comments are essentially those of a spectator. I'd suggest splitting up the changeset, pushing the each to default, and encouraging testing. I expect creating a temporary branch would result is less testing.

I assume you are worried about pushing bugs? Since 4.0 was just released, it will be some time before 4.2 is released and will give amble opportunity to shake out any problems.

Ben Abbott <bpabbott>
Project Member
Fri 17 Jul 2015 07:06:43 AM UTC, comment #25:

I'm attaching an update to the changeset. Contrary to what I had thought, "pdflatex" and "pdflatexstandalone" weren't implemented. But it wasn't too much effort to make that work. Getting the demo to work in most cases was a bit of work. (There are some bugs in outside applications on my system.)

If you want the changeset broken into smaller pieces, that's doable. I'm wondering if it would make sense to create a branch in the repository for a couple weeks and push all the changesets related to gnuplot on that branch. (This bug report. A half dozen or more other gnuplot-related changesets.) Then when everything seems stable merge the branch and be done with the branch (i.e., no periodic mergers). Updating changesets isn't efficient.

(file #34455)

Dan Sebald <sebald>
Wed 15 Jul 2015 07:44:25 AM UTC, comment #24:

Let me look through the changeset and try summarizing:

scripts/plot/util/__gnuplot_drawnow__.m: I suppose this one can stand on its own. If the mod in the print.m file that removes the reliance on an EPS intermediate file is not yet applied, this change is sort of irrelevant, but I don't think it hurts anything because EPS has the color option so color/mono still makes sense. Only the "eepic" terminal would be a problem because it uses "dashed" instead of "mono"--the consequence isn't too severe, though, as gnuplot only warns about options it doesn't understand.

scripts/plot/util/print.m
scripts/plot/util/private/__gnuplot_print__.m: These two should probably go together seeing as print.m refers to the gnuplot toolkit. (I just noticed that the comment "The @samp{pdflatex}, @samp{pslatexstandalone} and ## @samp{pdflatexstandalone} devices are not available with the Gnuplot toolkit." is still in the help text, but the goal is to supply these, so that comment should go.)

scripts/plot/util/private/__go_draw_axes__.m: Nothing new is passed into the function so this one stands alone.

scripts/plot/util/private/__go_draw_figure__.m: Nothing new is passed into the function so this one stands alone.

scripts/plot/util/private/__print_parse_opts__.m: These are just simple bugs local to the file.

Dan Sebald <sebald>
Tue 14 Jul 2015 11:52:07 PM UTC, comment #23:

Dan,

Is my observation correct that the changes to each m-file can be applied independently?

Ben Abbott <bpabbott>
Project Member
Tue 14 Jul 2015 08:06:49 AM UTC, comment #22:

Updating changeset to fix some conflicting code hunks.

(file #34442)

Dan Sebald <sebald>
Tue 17 Mar 2015 07:46:53 PM UTC, comment #21:

Could we move this latest patch into the repository? It doesn't feel like 4.0 is right around the corner yet, based upon bug reports still appearing.

Dan Sebald <sebald>
Sun 08 Mar 2015 07:32:38 PM UTC, comment #20:

Attached is a revamped version of the patch that simplifies things and adds a valuable demo to print() that illustrates what is available in terms of toolkits, devices and how to use the output in an external application.

The simplification is that I removed all the code that simulates grayscale to compensate for that missing behavior in gnuplot. Instead, for now one just gets what they get from gnuplot -mono or lack thereof. Instead, I'd rather fix gnuplot, as other Octave bug reports are coming in about rectangles obscuring plots. So there are several bugs to address in gnuplot and I'd rather go the route of fixing more on the gnuplot side of things. The consequence is that Octave user doesn't get automatic mono conversion for a few of the gnuplot devices, not a big loss as the user still has working color and in the meantime can do one or two extra lines of Octave code to get grayscale.

Other than the print demo, most everything else is bug fixes or syntax/efficiency changes, except for these three moderate changes (which themselves are kind of small):

1) Check for the availability of gnuplot terminal with mono/color options and use accordingly.

2) Don't use the "png16m"/"pdfwrite" technique of generating output by translating postscript in an external app.

3) Don't draw a rectangle behind the axes if it's color is the same as background. (If gnuplot is upgraded to fix these rectangle bugs, this can be removed. But I thought it annoying enough with current gnuplot to make this fix for now.)

4) Use 'paperunits' and 'paperposition' properties to control the size of gnuplot latex devices.

Regarding the last item, it seems to me that this family of properties:

is the way to control vector- or units-based output like LaTeX rather than the extra print option -S:

The -S seems like the thing to do with pixel-based formats.

I used the paperunits/paperposition options in the "demo print" program to set the output to 3"x5", and it seems to make sense in the processed LaTeX output. Without that control, the epslatex, etc. output of gnuplot was much too big for any document.

So, please give the demo a try. It is a good way of not only checking print results, but also illustrating the finicky nature of qt/fltk windows and printing with regard to program flow and cntrl-C behavior. Type Cntrl-C at various times (i.e., long running external postscript conversion) and check for crashes, odd behavior, so on. This is a realistic scenario of Octave is used. For example, run a simulation and display results in a plot every iteration.

I'd appreciate help on cleaning up gnuplot quirks as well, but perhaps any issues there can be put in new bug reports. I've gone through most terminals, but there are some for which my system tools are new enough to test. For example, the "tikz" devices really interest me, but it's too much of a hassle to update to 2.0 or 3.0 at the moment. (The process involves manually copying all sorts of files into sub-libraries of texmf; there's no "install" process for pgf/tikz.) Here's a summary so far of gnuplot bugs I'm seeing:

(file #33294)

Dan Sebald <sebald>
Mon 02 Mar 2015 08:33:33 PM UTC, comment #19:

I can't fix this before the 4.0 release, but I updated the patch so that it applies cleanly without rejects. See attached file.

There is still something wrong with -mono behavior. I tried

The resulting output is not grayscale, but various shades of purple. See the attached junk.pdf.

(file #33228, file #33229)

Rik <rik5>
Project Administrator
Sat 21 Feb 2015 07:38:38 AM UTC, comment #18:

Adding the following to the changeset (attached) makes the results appear visually as expected, but the grayscale is simulated using the color option:

(file #33144)

Dan Sebald <sebald>
Sat 21 Feb 2015 02:46:41 AM UTC, comment #17:

Not having publication-quality graphical output isn't a 4.0 blocker? The new plotting graphics and approach of running everything through a postscript converter doesn't make the grade. Look at a PNG file; lines are inconsistent, fonts are almost illegible. Latex output formats aren't working.

And the gnuplot toolkit currently has, along with the everything-through-postscript approach, enough bugs to render it practically unusable for graphical output.

Please try the following test script and closely examine the results as the external programs appear:

Dan Sebald <sebald>
Fri 20 Feb 2015 10:57:46 PM UTC, comment #16:

I agree with Rik. It is time to focus on
the release of 4.0. Regressions and blockers
only.

Michael Godfrey <godfrey>
Project Member
Fri 20 Feb 2015 10:13:30 PM UTC, comment #15:

I've tried to minimize changes in the changeset, as it really only corrects the buggy behavior and makes gnuplot output functional, which right now it isn't. That was the point of aiming for some intermediate stable point. The only thing that is different from current behavior is that -dpng will create actual grayscale under the -mono flag, whereas all other devices are the same for the most part. (EPS still defaults to mono, etc. And there is always -dcairopng as an alternative PNG output format.)

To add grayscale as we think it should behave is the more significant step and is not part of this changeset.

I'd say apply the changeset and let developers give it a try. We can always back it out easily prior to 4.0 if there is a major problem because there is little activity in this private subdirectory. I'd rather take a bit of risk right now and have something fairly functional in 4.0 that remains stable until 4.X or 5.X rather than have marginal/buggy performance for all that while. That way it gives some time to redo the setup without having reports of broken output to deal with.

Dan Sebald <sebald>
Fri 20 Feb 2015 08:08:56 PM UTC, comment #14:

Since this change is potentially contentious I'm going to delay it until after the 4.0 release.

Rik <rik5>
Project Administrator
Fri 20 Feb 2015 12:14:08 AM UTC, comment #13:

Alright, I updated the changeset patch. It's probably not going to be the desired result, but I think this change is a good stable point, if something that is intermediate.

I tried changing as few items as possible to avoid a huge changeset. But there are some conceptual changes whereby only as far in the calling tree as the file _gnuplot_drawnow_.m does the word "mono" mean "-mono" Octave option. When going into the _go_draw_figure_.m and _go_draw_axes_.m files the word "mono" technically means grayscale, or more precisely simulate gray scale with a color commands (because the gnuplot terminal doesn't have a "mono" setting). I removed the old "mono" behavior and now always include the "rgb 0x123456" specification. The way gnuplot works is that syntax should always be valid. Changing a terminal in gnuplot does not influence the syntax of commands. The terminal options are the only thing that change.

Evaluate the patch, evaluate the behavior. Suggestions are welcome. The reason I'm inclined to leave the arguably confusing behavior as is is because the mono directive is done at the gnuplot level. We could change things so that "mono" is not used in gnuplot and rgbc() (i.e., map color to rgb) is used to simulate grayscale, but by doing that we miss gnuplot's ability to create minimal features in the generated EPS files. gnuplot will create postscript with minimal features and PostScript language. In other words a gnuplot-generated postscript file can be more compact with the terminal directive as opposed to making a color EPS file look as though it is grayscale.

So, before moving forward, I'd like to discuss with the gnuplot group how to proceed with the many terminals having the "mono" option. Main developers aren't even certain of it's meaning any more with so much evolution having occurred. What I think might be a good idea for gnuplot is to introduce another option "grayscale/greyscale", i.e., {mono|grayscale|color} -- where mono means one pen color (black), grayscale means grayscale pen and color means color pens. If that were the case, then I think the current changset would only need change

to

to produce the desired results for Octave "-mono".

(file #33138)

Dan Sebald <sebald>
Tue 17 Feb 2015 01:14:08 AM UTC, comment #12:

@Dan: You might want to pull the latest from Mercurial. I added a changeset that attempts to make sure that all printf statements with integer format codes actually are integers (http://hg.savannah.gnu.org/hgweb/octave/rev/5f2c0ca0ef51). This will have partially overlapped your cset for this bug.

Rik <rik5>
Project Administrator
Mon 16 Feb 2015 10:36:43 PM UTC, comment #11:

@Dan: For Matlab compatibility we will not be able to keep the old behavior of the printf family of functions that truncated floating point input to decimal format codes such as "%0X". Thus, we will keep the modifications you made to add round () to sprintf function calls. You mentioned in comment #9 that you might prepare a new version of the patch to take advantage of the 'bg' option to gnuplot. I would say go ahead and complete the patch and I will review and check in.

Rik <rik5>
Project Administrator
Mon 16 Feb 2015 08:27:14 PM UTC, comment #10:

A (very late) ansert to comment #4
The gnuplot bundled with windows version is gnuplot 4.6 patchlevel 4.

Avinoam Kalma <avinoam>
Project Member
Sat 14 Feb 2015 03:53:06 AM UTC, comment #9:

I wondered about that, but then thought maybe that was defined behavior, i.e., to print as float even if the field specifier indicates integer. Maybe something to do with the fact that variable input length functions aren't as robust in interpreted languages as they are in compiled languages--but that's just a guess.

It's fine to wait until the other behavior related to the printf family is resolved. I found out yesterday that "bg" can be used as a valid color in gnuplot and that doesn't have the bug of a white rectangle (i.e., "0xffffff") being cast to black under the mono option. So I can tweak the patch slightly in that regard as well when the printf is done, although I think it is generally correct as is when testing for "none", etc.

Dan Sebald <sebald>
Fri 13 Feb 2015 11:23:03 PM UTC, comment #8:

Another question, are the lines below trying to work around bug #44245?

If so, then we should get that bug fixed and then remove these lines from this patch.

Rik <rik5>
Project Administrator
Thu 12 Feb 2015 07:01:33 AM UTC, comment #7:

OK, I've made those changes.

I've also added one more change which is to not draw the axes background rectangle if its color matches that of the background. This is meant to circumvent bad behavior in "mono" output for gnuplot, whereby gnuplot treats 0xffffff (i.e., white) as a color and casts it to black. However, I think that the added condition is OK in general because if the figure background is "none" it is treated as white.

(file #33056)

Dan Sebald <sebald>
Tue 10 Feb 2015 12:28:40 AM UTC, comment #6:

For comment #5, yes, mono must produce grayscale output. That needs to be changed since I also get a green background when attempting grayscale printing.

Some other things I see:

"emf" should be in line with the other terminal types. The variables starting with "eepic" should be 1 character over to align inside the '{' grouping.

For Matlab compatibility, the postscript options without 'c' should produce black and white so this part of the cset should be reverted.

Rik <rik5>
Project Administrator
Sat 07 Feb 2015 06:14:38 PM UTC, comment #5:

Hi,

As I understand, mono is meant for grayscale and not single color.
I attaching one of the eps files, footest-mono.eps, which should be in grayscale colors. Note the right and left margins.

(file #33026)

Avinoam Kalma <avinoam>
Project Member
Thu 05 Feb 2015 06:22:09 PM UTC, comment #4:

OK, thanks.

Too bad about Cairo. What version of gnuplot are you using? If you were using Linux I'd say it is very easy to build gnuplot from scratch, but with Windows I think you'll need to get a recent binary version. You may also need to check your computer for the presence of the Cairo library. gnuplot's Cairo terminal produces some really nice looking graphs--good font and line thickness.

Could you please post the EPS file here as an attachment? EPS files should be cropped tight without removing any plot content. The idea is that white space can always be added later on when the EPS file is used inside a document editing application.

Dan Sebald <sebald>
Thu 05 Feb 2015 02:14:13 PM UTC, comment #3:

Hi,

I have checked the patch in mxe-octave under Windows XP.
Since the print command does not work well now (bug 44186), I have used
gs9.15 instead of gs9.07 that is bundled with mxe-octave.

All the coomands with print (' ', '-dpngcairo') or pdfcairo
did not work:

All the files has green background (color, mono....). The diference bewtween the mono and color files is the color of the line. The conflict and the default filles looks like the color files.

The image of the eps files is too close to the right margin

Avinoam Kalma <avinoam>
Project Member
Thu 05 Feb 2015 12:57:24 AM UTC, comment #2:

Here's a test script I was using when making the changeset:

Dan Sebald <sebald>
Thu 05 Feb 2015 12:54:35 AM UTC, comment #1:

Attached is the patch for bug fixes. There's one more than previously mentioned:

6) Use ",%d" rather than "%d" for fontsize in PNG et al. terminals. Make the unknown/default fontname string empty (""), rather than "{}". I think the original programmer looked at the gnuplot help and saw {} thinking that's mandatory, but in gnuplot help, {} just means optional item.

(file #32997)

Dan Sebald <sebald>
Wed 04 Feb 2015 09:39:05 PM UTC, original submission:

I will submit a changeset having a number of bug fixes in the graphics toolkit for printing.

1) There are several printf errors whereby a float is passed into an octal formatted number.

2) There are several strings for the parse options which are incorrectly accessed using curly parentheses rather than round parentheses.

3) The "mono" setting is passed into the graphics toolkit so that gnuplot can make the decision about what is format strings to create.

4) I've changed the default setting to "color" for PostScript. I'd much prefer a printed output that looks similar to what the default figure plot appears.

5) I've overridden the "png16m" and "pdfwrite" behaviors so that gnuplot does "png" and "pdf" if possible. I prefer gnuplot doing the "-dpng" option as opposed to creating an EPS figure and then some translation utility to create a PNG file. PNG fonts are something more suited for bitmap graphics (easier to read) than would-be scalable fonts (EPS) transformed to bitmap. The plot-to-postscript-to-png technique is something that can be done by the user if they like. I think that the exact implementation of these:

file formats should be done at the toolkit level and not the print() level.

Dan Sebald <sebald>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #36482:  gnup_mono.cset added by rik5 (21KiB - application/octet-stream)
file #35852:  changeset-mono.patch added by bpabbott (21KiB - application/octet-stream)
file #35786:  ChangeLogs.txt added by bpabbott (4KiB - text/plain - Proposal for splitting up Dan's patch)
file #35731:  script_wysiwyg_tests.m added by ederag (5KiB - text/x-matlab - test script and results)
file #35732:  results_15c13ba_4.0.1-rc1.png added by ederag (9KiB - image/png - test script and results)
file #35733:  results_15c13aa.png added by ederag (7KiB - image/png - test script and results)
file #35724:  wysiwyg_15c12da_bunch.hg.diff added by ederag (60KiB - text/x-patch - all changesets (up to now) in a single hg patch)
file #35721:  paperprops.diff added by bpabbott (3KiB - application/octet-stream)
file #35585:  wysiwyg_15b27aa_pageoffset.hg.diff added by ederag (3KiB - text/x-patch - fix pageoffset)
file #35550:  wysiwyg_15b25ba_auto.hg.diff added by ederag (2KiB - text/x-patch - labels + PaperPositionMode to auto)
file #35437:  wysiwyg-reintroduce-size-control_15b11aa.hg.diff added by ederag (1KiB - text/x-patch - Patch from Ben Abbott (comment #36))
file #35418:  wysiwyg-reintroduce-size-control_15b08aa.hg.diff added by ederag (2KiB - text/x-patch - bring size control back for non-gs devices)
file #35407:  wysiwyg-fix_dans_patch_15b07.hg.diff added by ederag (3KiB - text/x-patch - make Dan's patch compatible with the one of bug #46292)
file #35406:  wysiwyg-mupdf_15b07.hg.diff added by ederag (1KiB - text/x-patch - add the mupdf reader)
file #34657:  octave-gnuplot_bugs44187_2015Aug16.patch added by bpabbott (32KiB - application/octet-stream)
file #34567:  octave-gnuplot_bugs44187_2015Aug02.patch added by bpabbott (32KiB - application/octet-stream - Edited version of Dan's changeset)
file #34455:  octave-gnuplot_bugs44187_2015jul16.patch added by sebald (32KiB - application/octet-stream)
file #34442:  octave-gnuplot_bugs44187_2015jul14.patch added by sebald (29KiB - application/octet-stream)
file #33294:  octave-gnuplot_bugs44187_2015mar08.patch added by sebald (29KiB - application/octet-stream)
file #33228:  junk.pdf added by rik5 (75KiB - application/pdf)
file #33229:  gnuplot_mono.cset added by rik5 (20KiB - application/octet-stream)
file #33144:  octave-gnuplot_bugs44187_2015feb21.patch added by sebald (21KiB - application/octet-stream)
file #33138:  octave-gnuplot_bugs44187_2015feb19.patch added by sebald (21KiB - application/octet-stream)
file #33056:  octave-gnuplot_bugs44187_2015feb11.patch added by sebald (11KiB - application/octet-stream)
file #33026:  footest-mono.eps added by avinoam (21KiB - application/postscript)
file #32997:  octave-gnuplot_bugs44187_2015feb04.patch added by sebald (11KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by ederag (Updated the item)
  • -email is unavailable- added by ederag
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-02-27 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2016-02-27 bpabbott StatusIn Progress => Ready For Test
    2016-02-27 rik5 Attached File- => Added gnup_mono.cset, #36482
    2015-12-24 bpabbott Attached File- => Added changeset-mono.patch, #35852
    2015-12-18 bpabbott Attached File- => Added ChangeLogs.txt, #35786
    2015-12-13 ederag Attached File- => Added script_wysiwyg_tests.m, #35731
        Attached File- => Added results_15c13ba_4.0.1-rc1.png, #35732
        Attached File- => Added results_15c13aa.png, #35733
    2015-12-13 ederag Attached File- => Added wysiwyg_15c12da_bunch.hg.diff, #35724
    2015-12-12 bpabbott Attached File- => Added paperprops.diff, #35721
    2015-11-28 ederag Attached File- => Added wysiwyg_15b27aa_pageoffset.hg.diff, #35585
    2015-11-25 ederag Attached File- => Added wysiwyg_15b25ba_auto.hg.diff, #35550
    2015-11-25 rik5 Dependencies- => bugs #46517 is dependent
    2015-11-11 ederag Attached File- => Added wysiwyg-reintroduce-size-control_15b11aa.hg.diff, #35437
    2015-11-08 ederag Attached File- => Added wysiwyg-reintroduce-size-control_15b08aa.hg.diff, #35418
    2015-11-07 ederag Attached File- => Added wysiwyg-fix_dans_patch_15b07.hg.diff, #35407
    2015-11-07 ederag Attached File- => Added wysiwyg-mupdf_15b07.hg.diff, #35406
    2015-11-06 ederag Carbon-Copy- => Added ederag
    2015-08-16 bpabbott Attached File- => Added octave-gnuplot_bugs44187_2015Aug16.patch, #34657
    2015-08-02 bpabbott Attached File- => Added octave-gnuplot_bugs44187_2015Aug02.patch, #34567
    2015-07-17 sebald Attached File- => Added octave-gnuplot_bugs44187_2015jul16.patch, #34455
    2015-07-14 sebald Attached File- => Added octave-gnuplot_bugs44187_2015jul14.patch, #34442
    2015-03-08 sebald Attached File- => Added octave-gnuplot_bugs44187_2015mar08.patch, #33294
    2015-03-02 rik5 Attached File- => Added junk.pdf, #33228

    Back to the top


    Powered by Savane 3.3