#680 add pentagon pointtype to cairo terminals

Version 5
closed-accepted
nobody
None
5
2014-05-19
2014-05-08
Karl Ratzsch
No

This adds an open and filled pentagon to the pointtypes in cairo terminals.
They come as no.s 14 and 15 like in the postscript or windows terminal.

1 Attachments

Discussion

  • Karl Ratzsch
    Karl Ratzsch
    2014-05-08

    And another one for the gd-based terminals.

     
    Last edit: Karl Ratzsch 2014-05-08
    Attachments
  • Karl Ratzsch
    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
  • Karl Ratzsch
    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.

     
    Attachments
  • Karl Ratzsch
    Karl Ratzsch
    2014-05-08

    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))}

     
    Attachments
  • Ethan Merritt
    Ethan Merritt
    2014-05-14

    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:

    • 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?
     
  • Karl Ratzsch
    Karl Ratzsch
    2014-05-15

    • 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.

     
  • Ethan Merritt
    Ethan Merritt
    2014-05-15

    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
    Attachments
    • Karl Ratzsch
      Karl Ratzsch
      2014-05-16

      Which viewer is this?

       
      • Ethan Merritt
        Ethan Merritt
        2014-05-16

        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.

         
  • Karl Ratzsch
    Karl Ratzsch
    2014-05-17

    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
    Attachments
  • Ethan Merritt
    Ethan Merritt
    2014-05-19

    • status: open --> closed-accepted