Fri 18 Nov 2016 03:50:06 PM UTC, comment #31:
@Ederag: there actually already exists a report about non joined axes lines: bug #39643. And I tested LINE_STRIP (basically what we use for line objects) and it is not a solution.
|
Mon 14 Nov 2016 03:36:24 PM UTC, comment #30:
I pushed the patch here: http://hg.savannah.gnu.org/hgweb/octave/rev/39f39eb4e476
Closing report as fixed.
|
Sun 13 Nov 2016 05:35:08 PM UTC, comment #29:
Thanks for testing Ederag, I'll push the linejoin patch ASAP.
>> "2 setlinecap" on axis borders would make better axis joints (corners) than current default.
>> Does it deserve a separate report, or maybe am I missing something ?
Yes please open a separate bug report. Using setLineCap is not necessarily the best solution (this only works for printout) and single lines could eventually be replaced by line strips which would improve both onscreen and printout figures.
|
Sat 12 Nov 2016 09:30:33 PM UTC, comment #28:
Confirmed; congratulations !
The LD_PRELOAD is needed because with the dev version the run_path
contains a spurious /usr/lib64:
This is not the case for 4.2.0-rc4
(unpatched, but this is probably not relevant):
"2 setlinecap" on axis borders would make better axis joints (corners) than current default.
Does it deserve a separate report, or maybe am I missing something ?
|
Wed 02 Nov 2016 10:01:36 PM UTC, comment #27:
I attached a patch and the image I obtain for the Original example.
In order to test it you need to build the current snapshot of gl2ps [1], and then bootstrap/configure/rebuild Octave using appropriate FLAGS, e.g.:
[1] http://geuz.org/gl2ps/src/gl2ps-svn.tgz
(file #38869, file #38870)
|
Fri 28 Oct 2016 10:47:22 AM UTC, comment #26:
Many thanks Mike, it works great.
|
Thu 27 Oct 2016 06:07:02 PM UTC, comment #25:
Sorry, one line in that patch should probably be
just in case the user's LIBS are important for the test to pass.
And I meant the global CPPFLAGS and LDFLAGS to use -I and -L options to find a non-default gl2ps library.
|
Thu 27 Oct 2016 06:04:17 PM UTC, comment #24:
Sure, a small change like this should be enough to get started
This will automatically add HAVE_GL2PSLINEJOIN to config.h (on my system it's not found and is undefined).
Yeah we don't have any more sophisticated checking/enabling/disabling for gl2ps for now, that could be added later (for now just use the global CPPFLAGS and LIBS variables to point to an alternate installation).
|
Thu 27 Oct 2016 07:23:52 AM UTC, comment #23:
I am working on a patch but I could use some help to get me started on introducing build conditionals.
@Mike: I need to define something like a HAVE_GL2PS_LINEJOIN variable. This would be true when gl2psLineJoin has been found to be present during configure. The following options for configure would also be welcome: "--with-gl2ps-includedir" and "--with-gl2ps-libdir". I know I could find the solution with a little searching but I am pretty sure you will be able to point me to the right direction faster.
|
Sun 04 Sep 2016 05:20:31 PM UTC, comment #22:
The patch has been merged upstream [1]. There are now 2 new functions inn gl2ps: gl2psLineCap and gl2psLineJoin.
Once Octave 4.2 is out, I'll propose a patch to make use of those functions if they are available.
[1] http://www.geuz.org/pipermail/gl2ps/2016/000443.html
|
Tue 23 Aug 2016 09:51:45 AM UTC, comment #21:
No news from gl2ps maintainers up to now [1]. In any event I don't think anything robust can be done on the Octave side without modifying gl2ps itself, see comment #15.
[1] http://www.geuz.org/pipermail/gl2ps/2016/000439.html
|
Tue 23 Aug 2016 09:15:33 AM UTC, comment #20:
Are there any news on this? It would be great to have the problem fixed in the 4.2 release!
|
Fri 08 Jul 2016 06:13:25 PM UTC, comment #19:
I posted a feature request and a preliminary patch on gl2ps mailing list.
|
Tue 05 Jul 2016 05:59:26 PM UTC, comment #18:
The spurious transformation by savannah should be fixed.
As a test, here is the link about line joins:
http://ngwww.ucar.edu/gks/ps.html#MiterLimit
|
Mon 04 Jul 2016 02:44:46 PM UTC, comment #17:
Beware that with the patch (file #37690), some ylabels disappear.
For instance
Without patch: file #37705: try_pristine.ps
With gl2ps.diff patch: file #37706: try_patched.ps
Here is the diff:
The "(a)Tj" line disappeared.
Manually inserting "1 setlinejoin" works fine (the label is there):
|
Mon 04 Jul 2016 08:29:06 AM UTC, comment #16:
Oh and ML has "linejoin" property that we should use to control this.
|
Mon 04 Jul 2016 08:26:54 AM UTC, comment #15:
I think having a control on linecap/join would be very useful, but setting it directly in the postscript prolog looks like a hack:
- 1- it is not safe to assume that gl2ps won't change the value of linejoin we have set
- 2- as per comment #12 and comment #14, it would be useful to change the value of linejoin/cap on a per object type basis.
- 3- terminal svg and pdflatexstandalone will not be affected and will thus be different from other formats (which are all based on postscript)
We thus need something like the pseudo-code below:
We should also be able to do the same for pdf (psdlatexstandalone uses pdf terminal) and svg terminals.
In the end, this looks like a feature request for gl2ps, no?
|
Sun 03 Jul 2016 08:14:52 PM UTC, comment #14:
@Dmitri "1 setlinecap" looks fine to me.
"2 setlinecap" makes better axis joints (corners) than current default, while keeping rectangular ticks. But ticks and other lines will look a bit longer (by half a linewidth).
Maybe options to print.m ?
@Mike Yes, the patch works perfectly.
By the way, it does fix bug #46529 too.
Thanks to all !
|
Sun 03 Jul 2016 06:28:39 PM UTC, comment #13:
But again "1 setlinecap" make axis joints look nicer.
Decision, decision...
Dmitri.
--
|
Sun 03 Jul 2016 06:00:15 PM UTC, comment #12:
On second thought, "1 setlinecap" would make ends of tic marks rounded, I am not sure if this is a preferred choice for everyone.
Dmitri.
--
|
Sun 03 Jul 2016 05:36:21 PM UTC, comment #11:
I would change setlinecap to 1 as well....
Dmitri.
--
|
Sun 03 Jul 2016 05:33:56 PM UTC, comment #10:
Dmitri, good catch.
ederag, does the attached patch work for you?
(file #37690)
|
Sun 03 Jul 2016 05:15:55 PM UTC, comment #9:
Yes, the gl2ps library (as of 1.3.9) sets both setlinecap and setlinejoin to "0". To me "1" in both cases looks like a more reasonable choice. I am not sure if it possible to overwrite it with gl2psSpecial in octave source.
Dmitri.
--
|
Sun 03 Jul 2016 05:11:59 PM UTC, comment #8:
Yes you should probably take this up with gl2ps.
I see every gl2ps file contains a PostScript prolog with "0 setlinejoin" in it unconditionally.
|
Sun 03 Jul 2016 03:31:19 PM UTC, comment #7:
The postscript file #37686: try_orig.ps
generated by
print -color try.ps
has the same glitches as the png.
adding 1 setlinejoin manually removes the spikes.
cf. file #37687: try_round.ps
and the diff
file #37688: try_round.diff
So the problem could be fixed by adding a mere postscript directive.
Probably in gl2ps ?
|
Sun 03 Jul 2016 03:22:51 PM UTC, comment #6:
I think it is a limitation of opengl. It just does not have a sophisticated line joining algorithm one would fine in a true 2-d drawing library like cairo. So I would suggest using gnuplot with cairo based terminals (qt, pngcairo, pdfcairo, epscairo).
Alternatively you may want to draw your data with dots then overplot with thin line.
Dmitri.
--
|
Sun 03 Jul 2016 11:27:14 AM UTC, comment #5:
Yes there is the linewidth difference, but I'm more concerned about the sharp spikes (in file #37678: qt_try.png).
They make the spectrum look noisier than it really is.
Should I prepare a figure with side-by-side comparison to make this point clearer ?
This is exactly what they describe in PS and miter limit:
It should be possible to change the linewidth without triggering this problem.
|
Sun 03 Jul 2016 11:09:27 AM UTC, comment #4:
All I see is a line width difference.
|
Sun 03 Jul 2016 11:07:26 AM UTC, comment #3:
Last try, in verbatim
|
Sun 03 Jul 2016 11:06:23 AM UTC, comment #2:
Sorry, but the correct "http://ngwww." is transformed by savannah to "http://ng[http://www]."...
Here is the link in quotes
"http://ngwww.ucar.edu/gks/ps.html#MiterLimit"
|
Sun 03 Jul 2016 11:01:31 AM UTC, comment #1:
correct link
http://ngwww.ucar.edu/gks/ps.html#MiterLimit
|
Sun 03 Jul 2016 10:58:13 AM UTC, original submission:
Sometimes printed plots look much noisier than they should, with Qt backend.
The files given have been obtained with the latest development version.
hg id -in
91611c9e1d81 22032
The attached `script_miter.m` loads an experimental data file, plot and print it.
On screen (qt_screenshot.png) the plot looks fine, with little noise.
The printout (qt_try.png) is much noisier, to the point that the qt backend can not be used for reporting purposes.
with graphics_toolkit("gnuplot"), the printout is fine (except for the color): gnuplot_try.png.
At first sight, this seems related to bug #46529, but here the spacing is reasonable (2048 points, minimum dx > 0.5).
Decimating is not an option here.
It might be related to line joins:
http://ngwww.ucar.edu/gks/ps.html#MiterLimit
|