Tue 06 Sep 2016 03:07:11 AM UTC, comment #11:
This has been fixed on the dvelopment branch and will be part of the 4.2 release.
|
Sun 16 Feb 2014 05:05:52 PM UTC, comment #10:
I think now that the problem is not 'barh'.
'barh' makes use of the 'patch' function and I was able to generate the bug by using only 'patch'.
See the attached file.
It generates 3 traingles. The most left triangle is surrounded by a countinous line, the middle one by dashed line and the right is surrounded by dashed-dotted line. Weird.
Ido
(file #30573)
|
Sun 16 Feb 2014 09:06:47 AM UTC, comment #9:
I checked that script using octave 3.6.4 and the bug is there.
Ido
|
Fri 14 Feb 2014 12:20:36 AM UTC, comment #8:
With Mike's script I can now reproduce this bug too. For me it's a problem both with the on-screen rendering and with the printing. In other words, saveas is correctly saving what I see on the screen in the svg file, but the screen is wrong to begin with.
If I take a look at the lines around the edge it seems to me that they are actually rotating between line styles. The smallest bar does indeed use '-' as a linestyle, but the others are wrong.
I found it helpful to use the bug40863 script followed by
This removed the red border and made the problem pop out.
|
Thu 13 Feb 2014 11:52:31 PM UTC, comment #7:
I can reproduce this bug in 3.8.0 and the default branch, but not in 3.6.4. Ido, can you confirm whether you see this with version 3.6.4 or only with a newer version?
Attached a script that produces the dashed output when run in 3.8.0 but not in 3.6.4.
(file #30547)
|
Mon 27 Jan 2014 12:43:00 AM UTC, comment #6:
Interesting, I get the dashed border as reported in this bug. Debian, gnuplot 4.6.4, wxt terminal. I compared my SVG to Rik's SVG and when I delete the red border, I definitely get a dashed black outline on the black bars. Might have something to do with different gnuplot versions? Gnuplot bug?
|
Thu 12 Dec 2013 11:32:08 PM UTC, comment #5:
I set the gnuplot terminal to wxt and used
I dissected the resulting file with Inkscape and removing the red border leaves a black rectangle with a continuous border. The svg is attached to this report as no_bug.svg.
(file #29911)
|
Thu 12 Dec 2013 10:11:36 PM UTC, comment #4:
I am not talking about the edge line. That why I defined it as zero width. If the edge line has some thickness it just hides the dashed line. That works for me also. Though, I think that if you'll run:
and then you remove the red line in the SVG file by inkscape you will find the dashed line over there.
Even that thickening the edge line might be some workaround I still think that the bar border line should be continuous by default, without the help of 'linewidth'.
Can you please post here the 'svg' file that the above script generates for you?
I am using gnuplot 4.6.4. and the 'octave -f' didn't change anything.
|
Thu 12 Dec 2013 04:11:25 PM UTC, comment #3:
I used the environmental variable GNUTERM to switch between qt, x11, and wxt terminals. In each case I changed the environment variable and then started Octave 3.6.4 and ran your test script. It worked for all three of these terminals. This was with gnuplot 4.6.2 and I also used inkscape for the verification.
You might try changing the script to use
This will make the borders extra large and bright red which will help in spotting the problem immediately (I've atteched wxt_plot.png which is the screenshot I get when running the commands above). Also, can you try starting octave using '-f' so that no initialization files are read? It's possible that the site-wide or your personal .octaverc file is changing some setting.
(file #29888)
|
Thu 12 Dec 2013 01:52:45 PM UTC, comment #2:
> Using 3.6.4 and the gnuplot backend I don't see this problem.
under octave with gnuplot using terminal 'x11' the border is continuous in the figure window. However, it is dashed in the output file that was generated by "saveas(h1,'bug.svg')".
> What Linux distro and version are you using?
I am using:
3.11-2-amd64 #1 SMP Debian 3.11.10-1 (2013-12-04) x86_64 GNU/Linux
> Are you using FLTK or gnuplot for plotting?
I am using gnuplot with 'wxt' terminal. Using FLTK give the same results as gnuplot with 'x11', i.e. continuous in the figure windows but dashed in the output file. (It should be noted that FLTK doesn't give me dashed line at all. Even when it should be dashed... but that might be another bug ...)
> If you zoom in to the plot window in Octave, are the borders dashed? Or is this only when printing?
Yes. They are dashed also in the 'wxt' figure window when zooming in. I
assume that by 'print' you mean 'printing to file' because I didn't
printed the image by printer. Only inspected the file with
'inkscape' (svg drawing software).
> Does it happen when you use a more regular backend
> like postscript?
>
Well, yes but for some reason it is harder to notice. I wrote
and the borders looked sometimes dashed and sometimes continuous. However, by converting that file to svg it could be seen that the borders are dashed.
|
Thu 12 Dec 2013 03:26:30 AM UTC, comment #1:
Using 3.6.4 and the gnuplot backend I don't see this problem. What Linux distro and version are you using? Are you using FLTK or gnuplot for plotting? If you zoom in to the plot window in Octave, are the borders dashed? Or is this only when printing? Does it happen when you use a more regular backend like postscript?
|
Tue 10 Dec 2013 09:35:06 AM UTC, original submission:
The following code:
generates bar plot and exports it as svg file.
I attached the corresponding file.
It can be seen that the bars border are dashed and this is unwanted. They should be either continuous or zero width.
Ido
|