.. and one for term.c, tested on the dxf terminal, where it adds as no. 7.
#define POINT_TYPES
is also in term/driver.h, and the compiler complained when it was redefined, so i changed it there, too. But i guess it should only be in one place, right?
And i noted in term.c that some of the other pointtypes first move to the beginning of the outline of the point symbol, and then draw a line to the same place. Is that necessary? Following the example of the triangles, my patch doesn´t do that, either.
There was a benefit to having 13 point types. Since 13 is a prime, the number of linetype+pointtype combinations generated automatically was large. The current default has the line types cycle every 9, so point type cycling every 13 yields 117 distinct combinations. With 15 point types and 9 line types you only generate 45 distinct combinations. You can say "set linetype cycle 8" to get 8*15=120 combinations at the cost of one distinct color being used, but I wonder if there should be a "set pointtype cycle" command also?
The main reason that pentagons weren't added for all terminals long ago was that on terminals with low resolution or no antialiasing they are hard to distinguish from a circle. That is still true for gd and for x11. The antialiasing in cairo seems good enough and I expect the antialiasing in qt would be also.
Specific comments:
There's a bug in the svg patch - point type 14 is invisible because the linewidth is 0. I fixed it.
As noted above, the rendering quality in gd is not good enough to distinguish pentagon from circle.
emf version is buggy. Point type 13 is drawn as a superimposed diamond and pentagon. The rendering quality is marginal in my emf viewer. I don't know how much better or worse it is in MSOffice, which I think is the primary place people would want emf. Have you checked?
the do_point() routine in term.c is a legacy fallback for old terminals that don't have their own. At least for the bitmap terminals the resolution is too dodgy for pentagons.
So overall I think:
OK for cairo, svg, probably should be added for qt
not OK for gd, do_point
not sure about emf
consider adding a command "set pointtype cycle N". This might be a pain, since all terminals would have to check it. And what about terminals that don't have that many point types?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i see it´s a pain to have to apply patches individually to files, sorry. i´m new to all this, do you know of some good intruduction on the web on how to set up my local sources and use version control?
pointtype cycle command would be handy. This would also allow to further expand the pointtype lists at minor releases, without breaking peoples plots. The terminals would just still need the internal, hardcoded cycle in addition.
Yes, it´s very bad in gd with pointsize one. I didn´t check that. My standard setting is "points 2", where it looks quite ok.
emf output looks OK in windows paint (awful really, but no diamond on the pentagon), and good in MS word. Better in printout than on screen, but that´s with all symbols. Word2007 seems to do antialiasing only for fonts on screen. In "EMF_point()" are (line 1488) a few "special point types" and i think they might have something to with the overprint error you see in your viewer. I´m just completely lost as to what they´re supposed to do.
With pointsize 2 they pentagons look quite ok on bitmap, so i think they could be added together with a "pointtype cycle" command. Same goes for gd terminals.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The ENHMETA reference implementation provided (long ago) by Microsoft. I run it under wine on linux. It allows you to inspect the internal layout of *.emf files. But it doesn't allow you to edit them so it's of limited use for debugging.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The patched version of emf.trm missed the "break" at the end of "case 12" (line 1624). (and has an extra one at the end of "case 14", where it´s not needed.)
So (likely because i didn´t give "diff -u",) the patch was inserted one line too early. Only noticed that today when i applied the same patch on my linux box.
I also tried inserting an emf test plot in a libreoffice document, and the pentagons look fine there. Superior to MS Word, in fact, well antialiased also on-screen.
There´s still those "special pointtypes". I found out when they were added, and it´s supposed to be similar to postscript:
And another one for the gd-based terminals.
Last edit: Karl Ratzsch 2014-05-08
.. and one for term.c, tested on the dxf terminal, where it adds as no. 7.
#define POINT_TYPES
is also in term/driver.h, and the compiler complained when it was redefined, so i changed it there, too. But i guess it should only be in one place, right?
And i noted in term.c that some of the other pointtypes first move to the beginning of the outline of the point symbol, and then draw a line to the same place. Is that necessary? Following the example of the triangles, my patch doesn´t do that, either.
Last edit: Karl Ratzsch 2014-05-08
And here´s one for emf. Should the other terminals pre-calculate the relative positions of the corners too?
I find it a bit ugly, but it probably saves some time (if you draw too many points on a single sheet, so?!?)
And might someone get the idea that it´s a "real" pentagon, and stumble over my 4-digit numbers? I don´t think so.
Last one from me: svg
this one writes "stroke-width=0.000" in the .svg file, so the open symbol is invisible. I couldn´t find the reason for this.
I choose for a relative outer radius of the pentagon of 1.33, calculated with this :
xy(r,phi) = rcos(phi) - irsin(phi); i=sqrt(-1)
do for [j=0:4] {d=xy(1.33,pi(j*72-90)/180); print sprintf("%.3f %.3f", real(d),imag(d))}
I'm working my way through testing these.
General comments:
Please generate patches using "diff -ur"
There was a benefit to having 13 point types. Since 13 is a prime, the number of linetype+pointtype combinations generated automatically was large. The current default has the line types cycle every 9, so point type cycling every 13 yields 117 distinct combinations. With 15 point types and 9 line types you only generate 45 distinct combinations. You can say "set linetype cycle 8" to get 8*15=120 combinations at the cost of one distinct color being used, but I wonder if there should be a "set pointtype cycle" command also?
The main reason that pentagons weren't added for all terminals long ago was that on terminals with low resolution or no antialiasing they are hard to distinguish from a circle. That is still true for gd and for x11. The antialiasing in cairo seems good enough and I expect the antialiasing in qt would be also.
Specific comments:
There's a bug in the svg patch - point type 14 is invisible because the linewidth is 0. I fixed it.
As noted above, the rendering quality in gd is not good enough to distinguish pentagon from circle.
emf version is buggy. Point type 13 is drawn as a superimposed diamond and pentagon. The rendering quality is marginal in my emf viewer. I don't know how much better or worse it is in MSOffice, which I think is the primary place people would want emf. Have you checked?
the do_point() routine in term.c is a legacy fallback for old terminals that don't have their own. At least for the bitmap terminals the resolution is too dodgy for pentagons.
So overall I think:
i see it´s a pain to have to apply patches individually to files, sorry. i´m new to all this, do you know of some good intruduction on the web on how to set up my local sources and use version control?
pointtype cycle command would be handy. This would also allow to further expand the pointtype lists at minor releases, without breaking peoples plots. The terminals would just still need the internal, hardcoded cycle in addition.
Yes, it´s very bad in gd with pointsize one. I didn´t check that. My standard setting is "points 2", where it looks quite ok.
emf output looks OK in windows paint (awful really, but no diamond on the pentagon), and good in MS word. Better in printout than on screen, but that´s with all symbols. Word2007 seems to do antialiasing only for fonts on screen. In "EMF_point()" are (line 1488) a few "special point types" and i think they might have something to with the overprint error you see in your viewer. I´m just completely lost as to what they´re supposed to do.
With pointsize 2 they pentagons look quite ok on bitmap, so i think they could be added together with a "pointtype cycle" command. Same goes for gd terminals.
Here's what I get for pointsize 2 using the emf terminal.
Notice point type 13 is a superposition of two shapes
Last edit: Ethan Merritt 2014-05-15
Which viewer is this?
The ENHMETA reference implementation provided (long ago) by Microsoft. I run it under wine on linux. It allows you to inspect the internal layout of *.emf files. But it doesn't allow you to edit them so it's of limited use for debugging.
The patched version of emf.trm missed the "break" at the end of "case 12" (line 1624). (and has an extra one at the end of "case 14", where it´s not needed.)
So (likely because i didn´t give "diff -u",) the patch was inserted one line too early. Only noticed that today when i applied the same patch on my linux box.
I also tried inserting an emf test plot in a libreoffice document, and the pentagons look fine there. Superior to MS Word, in fact, well antialiased also on-screen.
There´s still those "special pointtypes". I found out when they were added, and it´s supposed to be similar to postscript:
https://github.com/mojca/gnuplot-context/commit/a4ad01f7800ce8742502d69574bec981324852ef
They are not filled, otoh, like that old changelog says they´re supposed to, neither in emf nor in postscript.
I updated that in my patch too, but i wonder what it´s good for in the first place.
Last edit: Karl Ratzsch 2014-05-17