Re: "set scale" as opposed to "set size" or something else

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Sunday 11 February 2007 00:22, Daniel J Sebald wrote:
> 
>>set term png size 1280,960
>>
>>the result is a 1280 x 960 PNG image with the same resolution as the 
>>previous 640 x 480 PNG image.  That is, depending on one's viewpoint, 
>>it's as though every plot item has become 1/2 the size relative to 
>>the plot coordinate system.   
>>I could increase resolution by making the pointsize twice 
>>as big, line thickness twice as big, etc.
> 
> 
> I believe that this was the original intent of the "set size" command.
> It later got co-opted to implement multiplot mode instead.
> The original terminal entry point  term->scale() is still there, however.
> 
> It is interesting that Timothée recently submitted a patchset (#1616945)
> to remove this terminal entry, and now you are arguing in effect that
> we whould intead resurrect it for its original purpose.  
> 
> So if I may re-phrase your suggestion.  We should add a command
> 	set scale <multiplier>
> that is passed to each terminal.  Terminals capable of uniform scaling
> would apply this multiplier to relevant plot elements, including
> 	font size
> 	point size
> 	line width
> 	dash length
> 
> This is not strictly necessary, as all of these can be set separately
> for terminals that support them.  But it would add some degree of 
> convenience.

Yes, that is about right.  However, I'm not sure if the above list covers border line thickness, etc.  Anyway...

Reflecting on this, the parameters you listed should be units relative to the screen (plot?).  That is, what would be nice is to strive for sizes to always match the "ticscale" (relatively speaking) on the test pattern from one terminal to another.  If I change the number of pixels in the PNG image from 640,480 to 1280,960 the little marks at the top center of the test pattern stay about the same.  OK, so those little marks sort of correspond to the unit size on a screen when it comes to laying out borders.

The elements that remains roughly the same size relative to the screen are the hexagon and the patterns.  Fonts and line widths do not.  I guess I'm arguing they should attempt to do so.  (If one has to fall back on the fixed point fonts, it's a problem... but so be it.)

Some comments (that may be obvious):  If we do something like this:

  set term png font "courb,12" size 640,480

the 12 of "<font>,12" inherently sets "set font size" based upon the resoultion 640x480.  Vice-versa, "set font size" inherently sets "<font>,???".  Seems obvious, but what I'm saying is that "<font>,#" is extraneous (maybe not?) if we have an understanding that "pointsize", etc. is always relative to "ticscale".

[Timothée, note this part.]  So, what is the ramification for the line patterns?  Well, if we want to carry the idea of consistent line patterns across terminals, that means that 1,2,3,4,5,6 example in "test" would always also have to look about the same relative to "ticscale".  We couldn't just set the pattern for the library to 011101 (dash-dot), in some instances we'd have to set it to 001111100011, i.e., change pattern scale (that is, resample the pattern somehow).  Not as easy as it looks and I think that is what Ethan was getting at--correct me if I'm wrong.


> [nit-picking follows]

Well, there's my usual dash of inate confusion...

> 
> 
>>Say there were a "resolution #" option that would internally scale line 
> 
> thickness, pointsize, and fonts (have to have a mapping to medium, large, 
> giant... unfortunately the largest font doesn't have very high 
> resolution).
> 
> What is this "medium, large, giant" business?  
> Surely you are not still using the old 1999 PNG driver!

Yes, I knew that.  When in doubt, try "helvetica".  (Didn't work...)

I've read now and understand the fonts.  Hey, any interest in using opendir() and readdir() to scan through the files in the font directories for the file names (and search those that have an internal ASCII name) to list available fonts, e.g.,

show fonts

??  Could use file name completion or something to limit the list:

show fonts "*elvetica*"

Dan