forums.silverfrost.com

silicondale · Posted: Fri Nov 24, 2017 11:38 am Post subject:

Surely the default should be that annotation is placed outside the box? Almost always it will interfere (or there is a risk that it will interfere) with data being plotted within the box. When I developed a graphic subsystem (from first principles) in the 1970s and 1980s my users would never have even considered having annotation along axes within the plotting area !
http://www.vmine.net/g-exec/doc/gplot.pdf

Kenneth_Smith · Posted: Fri Nov 24, 2017 12:08 pm Post subject:

Paul,

Using Dan's code:-

Kenneth_Smith · Posted: Fri Nov 24, 2017 12:25 pm Post subject:

Paul,
See also my "Curly Wurly" code posted on Fri Sep 22, 2017 2:25 pm, I think this is the same basic problem. I've just rerun this with 8.2 and the strange effects on both axis scales are still apparent.
Ken

PaulLaidler · Posted: Fri Nov 24, 2017 6:13 pm Post subject:

Ken and Dan

The rogue space has now been located. Thank you.

silicondale

You may be right be don't forget that this development as grown out of the existing SIMPLEPLOT %pl.

DanRRight · Posted: Sun Dec 10, 2017 1:16 am Post subject:

Paul
How things go with the optimal numbering? Remember, we discussed that for the LOG scale the numbering has to be in the same style, it has to be either so called "engineering" (10, 100, 1000 or 1e2, 1e3, 1e4...) or "scientific" (10^1, 10^2, 10^4). May be good idea would be to introduce the appropriate WINOP@ key. Here is one example what %pl is doing right now

PaulLaidler · Posted: Sun Dec 10, 2017 9:45 am Post subject:

Dan

I have put the work on %pl to one side for now. Other things appear to be more urgent. He have already fixed some bugs and there is one more bug that I know about that is on the list. Hopefully I will be able to release a new set of DLLs before too long.

silicondale · Posted: Mon Dec 11, 2017 11:50 am Post subject:

Hi, John-S -- strange. That link is a simple graphical PDF made by scanning the original printed paper. Shouldn't cause problems even for the latest version of Adobe Reader.

DanRRight · Posted: Fri Dec 15, 2017 9:01 pm Post subject:

Looks like opposite to other native PL controls like

Kenneth_Smith · Posted: Fri Dec 15, 2017 10:07 pm Post subject:

Dan,

symbol_size is only specified once and applies to all curves with symbols in the plot. Maximum permitted value is 16.

Ken

DanRRight · Posted: Fri Dec 15, 2017 11:19 pm Post subject:

Thanks Ken. Do you agree this is more a defect then a feature?

PaulLaidler · Posted: Sat Dec 16, 2017 8:43 am Post subject:

Dan

You should get a error report if the symbol size is greater than 16.
This limit can easily be increased. How big would you like it?

PaulLaidler · Posted: Sat Dec 16, 2017 5:54 pm Post subject:

John

I am sorry that we are not providing the service that you expect. Unfortunately I do not anticipate further improvements to the native %pl in the short to medium term.

The delay from initial release until the release of the personal edition is normally about 2 months but it does depend on whether the initial release has proved to be successful.

DanRRight · Posted: Sat Dec 16, 2017 8:27 pm Post subject:

Paul,
Respect to symbol_size. Great that native PL now does not crash the code without diagnostics. That is very appreciated addition. But having restriction based on 16x16 pixel size is decision prone to permanent fixing in the future. It's ok for laptop screen, may be ok for 2k monitors, not enough for 4k and 5k monitors and is not acceptable for 8k.

What size has to be the maximum? I'd not restrict it till integer overflow where warning diagnostics should appear. If this will slow the graphics to total stall then 10x the screen dimensions have to be taken. Why so large? Some people may plot in virtual screens of extremely large dimensions.

Another is making one number for all plots which is fine for for first versions but besides making plotting less flexible is breaking the style of native %pl

Respect to some John's comments. I agree with him that the current shape of native PL needs urgent cosmetic fixing of few last often painful problems. That will take some extreme unsatisfaction with either bugs or missing features off the table. I'd go through this thread, make a list of what was asked for and what was done, reveal such screaming "nails in the shoe" problems, and close this large old thread for good.

silicondale · Posted: Sun Dec 17, 2017 1:23 pm Post subject:

I'd like to echo John's words - very much appreciate Paul's responsiveness. What other compiler developer has such close and productive interaction with their user base?

Having said that, I also agree about the small proportion of users who actually participate in this forum. However, this is probably quite normal. I have been on the other side of the fence in the past, as an applications system developer supporting a large international user community, of whom fewer than 5% ever took part in any user forums and meetings (this was before the days of the Internet and we had to go globetrotting to meet the users in person).

Specifically on %pl - speaking from personal experience, I found SIMPLEPLOT didn't do everything i needed, and developed my own graphics library using %gr and the Salford primitives such as draw_line_between@. Fortunately made easier by adapting an existing library that I had used before in different software environments. But of course if everyone does that, the same wheels get reinvented many times. That's why I'd really like to see the native %pl expand to something that can replace my (and anyone else's) old clunky code!

PaulLaidler · Posted: Fri Jan 12, 2018 9:25 am Post subject:

John

The next general release of intermediate DLLs will probably have to wait until the personal edition of FTN95 catches up.