Enable setting the drawing area to any size using Ferret commands

[karlmsmith]

Reported by @karlmsmith on 28 Nov 2011 20:30 UTC
Allow the SET WIN /SIZE=fff command (also see SET WIN /ASPECT=fff for possible complications) to set the drawing area to as large as desired. This would turn into a resize command to the graphics delegate.

Also consider something like a SET WIN /SCALE=fff to show the drawing area (and currect picture) at some ratio of the normal size. This would turn into a scale command to the graphics delegate. PlotPlus would not know about this scaling.

Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1901

[karlmsmith]

Modified by @karlmsmith on 28 Nov 2011 20:31 UTC

[karlmsmith]

Comment by steven.c.hankin on 29 Nov 2011 18:23 UTC
These address important goals, but might be worth further pondering the use cases. The current SET WINDOW qualifiers are historical artifacts of the device-independent graphics nature of GKS. The result has been /SIZE=[nominal_factor], instead of size given in pixels. It has been a headache for users (as well as for LAS scripts) that it is so hard to specify pixel size in Ferret. It would be nice to address this.

There's an independent need for /XPIXELS=nx/YPIXELS=ny concept in the FRAME command and in the SET WINDOW command. One controls screen pixels; the other controls output image pixels. It is at the time of SET WINDOW that the ASPECT ratio is determined -- before FRAME is issued. How about this:

SET WINDOW/XPIXELS=nx/YPIXELS=ny
 ! sets aspect, sets window pixel size
 ! if larger than available screen pixels, scroll bars will show.

SET WINDOW/SIZE= /XPIXELS=nx/YPIXELS=ny
 ! if /SIZE is given together with /XPIXELS/YPIXELS the window behaves
 ! as it did in pre-Python Ferret -- no scroll bars will show
 ! BUT -- the default pixel size of later FRAME images is hereby established 

FRAME/XPIXEL=nx/YPIXEL=ny 
 ! Over-rides the SET WINDOW default pixel size (if it was specified).
 ! (Note: If both xpixel and ypixel are specified together and their
 ! ratio doesn't match the window aspect there will be white space on
 ! one edge of the plot)

An appealing element of this approach is that the Ferret user advancing into Pyferret will see straightforward new pixel size controls as part of Pyferret, with the new controls interacting in natural ways (hopefully) with the traditional device-independent controls.

[karlmsmith]

Comment by @karlmsmith on 29 Nov 2011 19:35 UTC
I do like this idea. (FYI, /SIZE is in "units" of 1280x1024, which was also the hard-coded values in Ferret.) PS and PDF output automatically scale and center the image on the "page" (since it is printing to file), thus ignoring these values. But I think a user would expect this behavior.

I had been thinking about specifying size in inches (or cm), which would be translated into number of pixels using the screen resolution for raster images. But I think specifying pixels directly would be more useful and meaningful. For vector images (PS & PDF), I think the user would then expect the given size specification (in inches or cm) to be honored in the output, thus leading to a whole new "can of worms".

[karlmsmith]

Comment by steven.c.hankin on 29 Nov 2011 23:14 UTC
Ah, I had forgotten that PLOT+ tied its GKS workstation size to a fixed pixel value. Now that you remind me ("of course") it has to be so, because X-windows is a concrete, device-dependent workstation in the GKS viewpoint. In that sense, by accidental good luck, the outline I suggested is pretty much on target: SET WINDOW/SIZE specifies the size on the terminal screen; SET WINDOW/XPIXELS/YPIXELS specifies the size of the page that the "window" peers onto.

PostScript and PDF do complicate the above. From my recent experiences as an amateur architect using CAD software I can attest that software to handle PDFs (at least) is very tightly tied to the idea of a pre-specified page size. But in inches (or cm), rather than in pixels, of course. To keep the metaphors consistent, you'd want the window (specified by a nominal /SIZE) to peer onto a page (specified in inches). How about this approach:

! example -- output to image
SET WINDOW/SIZE=.75/XPIXEL=800/YPIXEL=600
GO ptest
FRAME/FILE=image.png   ! 800x600 pixel image

! example 1 -- output to a page
SET WINDOW/SIZE=.75/XPAGE=8.5/YPAGE=11/RESOLUTION=300
!                             /RESOLUTION default is (say) 300 dpi
GO ptest
FRAME/FILE=image.pdf    ! 8 1/2 x 11 inch page

! example 2 -- output to a page
SET WINDOW/ASPECT=`11/8.5`
GO ptest
FRAME/FILE=image.pdf/XPAGE=8.5    ! 8 1/2 x 11 inch page
!                   /YPAGE could alternatively have been specified

I guess I like the approach in example 2 a little better, myself:

1. requires fewer new qualifiers
2. does not require the user to translate into and out of pixels

[karlmsmith]

Comment by @karlmsmith on 1 Dec 2011 19:54 UTC
Enabled SET WIN /SIZE=fff to work for any given size (can exceed the size of the hard-coded 1280x1024 "display size"). Verified that line thicknesses (and the images) scale properly; i.e., the scene from SET WIN /SIZE=4.0 gives the same image as SET WIN /SIZE=1.0 and then scaling the image by 2.0 in each dimension (Scene -> Scale in the viewer).

Delaying implementation of the new command options while I work on some other defects.

[karlmsmith]

Comment by @karlmsmith on 14 Jun 2013 18:16 UTC
E-mail to Andrew:

Since PPL$WIDTH and PPL$HEIGHT do not change when you reset the window size, I realize that I actually am not sure what the definition of a Ferret inch (or Denbo inch, as Ansley calls it) really is.

What I do observe, however, is that the window size, for a given /size=n, is the same number of pixels but not the same physical size on the monitor. Running the script:
use coads_climatology
shade /l=5 sst
frame /file=sst.png

On my ViewSonic 23" monitor,
   Monitor resolution   DPI-X  DPI-Y   Ferret/PyFerret window size
     1920 x 1080         95     95      8 1/2" wide, 7 3/8" high      
     1680 x 1050         85     94      9 3/4" wide, 7 5/8" high
     1440 x  900         72     80     11 3/8" wide, 8 7/8" high 
On the Lenovo laptop montor,
   Monitor resolution   DPI-X  DPI-Y   Ferret/PyFerret window size
     1280 x 800         108    108      7 5/8" wide, 6 5/8" high

All produce an 819 x 707 PNG image for PyFerret, or 819 x 706, 818 x 706, 819 x 707, 818 x 705 GIF image for Ferret.
(If you first set window /size=1, you get a 979 x 845 PNG image; the default is /size=0.7)
So the constant thing here is the window size in pixels.

Note 1: If you run ferret -gif, the GIF size is 768 x 662, so something shrinking it (94% original size) in this case.

Note 2: If you run pyferret -nodisplay, the PNG size is 1024 x 884, so something is enlarging it 25% in this case. I probably need to correct this.

Verified pixel size is what stays the same on flat's console with Ferret and PyFerret:
1024 x 768 monitor at 85 dpi in X and Y (although I had to set the ferret window size to 0.5)
and stout's console with PyFerret:
1920 x 1200 monitor at 102 dpi in X and Y.

But with Ferret on stout's console, the window/gif is a little larger (862 x 745 pixels).
Using the -gif option gives the same reduced-size gif seen before.

When this gets saved to PDF or PS in PyFerret, because of scaling without distortion, the constant becomes the page width or height, whichever is the limiting size. So for the default aspect ratio (819 x 707 or 979 x 845) going to an 11 x 8.5 landscape page, the image is approximately 9.85" x 8.5". Given that margins need to be added, this will be somewhat smaller.
For the /size=0.7 displayed window, one pixel (/thick=1) is about 0.86 points.
For the /size=1.0 displayed window, one pixel (/thick=1) is about 0.72 points.
Again, margins will make these smaller.

Basically, the change in /size is saying the window is larger, but then you are forcing it onto the same page size when you print to PDF/PS with automatic page fitting. Unless you want to force some scaling factor for creating the PDF/PS images and not have it fill the page, but consequently, /thick=1 gives a set line width in points in PDFs as well as pixels in PNGs. So, do we want:

(A) PyFerret to automatically fit the image to the page it is being printed to (so /size=1 printed to a "poster size" page makes a magnified version of what is on the screen; the user should have set /size=25 to make multiple normal-sized plots filling this large page),

or

(B) to make the user adjust SET WINDOW /SIZE=... to the appropriate size to fit the page being printed to (for example, /size=25 to fill a "poster-size" page and /size=1 would give a small plot centered in this large page)?

Not sure how real the suggested scenario is, but I am inclined to stick with (A).

[karlmsmith]

Comment by @karlmsmith on 15 Jun 2013 13:26 UTC
Adding excerpt from e-mail message:

But re-reading Steve's suggestion in ticket #1901 re: SET WINDOW /XPIXEL= /YPIXEL= and FRAME /XPAGE= /YPAGE=, I could see the following scenario that leaves the user in control of all of this:

yes? SET WINDOW /XPIXEL=720 /ASPECT=7.5/10.0
! creates a 720 x 540 plot - planning on 11" x 8.5" less 0.5" margin

(perform the plot)

yes? FRAME /FILE=test.png
! creates a 720 x 540 pixel PNG plot

yes? FRAME /FILE=test.pdf /XPAGE=10.0
! creates a 10" x 7.5" plot; thus 1 pixel (thickness of 1) is 10"/720 = 1 point

And using the SET WINDOW /THICKEN=... one could adjust the raster image size and still keep the line thickness of 1 to be 1 point (e.g, SET WINDOW /XPIXEL=1440 /THICKEN=2 /ASPECT=0.75)

[karlmsmith]

Comment by @karlmsmith on 15 Jun 2013 13:28 UTC
Adding e-mail message from Andrew:

Maybe the simplest approach would be to have SET WINDOW define a drawing surface (in inches), a base pen (in points), and a dots-per-inch (dpi) render factor for the screen. If we set 72dpi, we get one rasterized pixel per PostScript point. If we set 144dpi, we get 2 pixels per PostScript point, and the raster (e.g. screen) output is twice as wide and twice as tall, without changing the vector output at all. If we set 30dpi, we get a tiny little window with wispy antialiased lines. So how about

SET WINDOW/WIDTH=11/HEIGHT=8.5/THICK=1/DPI=72

For backwards-compatibility, the user could instead provide /SIZE and /ASPECT qualifiers, and the height and width would be computed using some default dpi: HEIGHT=SIZE/( default_dpi*ferret_factor) and WIDTH=HEIGHT/ASPECT.

Then for graphics output, we'd do

FRAME/file=test.pdf
FRAME/file=test.png ! default DPI is that of the window, in this case 72
FRAME/file=test.png/DPI=144 ! output with higher dpi

[karlmsmith]

Comment by @AndrewWittenberg on 16 Jun 2013 00:11 UTC
(Apologies for not noticing the earlier-proposed XPAGE, YPAGE, RESOLUTION -- that's just what I had meant by WIDTH, HEIGHT, DPI.)

Merging all these ideas, and renaming a little, how about this:

SET WINDOW/XINCHES/YINCHES/XDOTS/YDOTS/DPI/SIZE/ASPECT

where only some combinations are allowed -- the other items would be computed from what the user specifies and/or the Ferret defaults. An advantage of these names is that it gives DPI an obvious meaning, and allows the short abbreviations XI/YI/XD/YD. Once Ferret has filled in the gaps, these would all be provided to the user as Ferret symbols, and also would serve as the window-defaults for FRAME -- unless overridden for raster output by

FRAME/FILE=test.png/XDOTS/YDOTS/DPI

where only one of those dots qualifiers would be allowed, since the aspect ratio is fixed.

Let me know if I'm missing anything. One question is whether to split DPI into XDPI and YDPI, in case a monitor has non-square pixels -- how common is that?

[karlmsmith]

Comment by @karlmsmith on 16 Jun 2013 16:18 UTC
At least ten years ago, probably longer, one of the big enhancements in monitors was that DPI-X was the same as DPI-Y at their "native" resolution (1920x1080 on the 23" ViewSonic, 1920x1200 on the 22" ViewSonic, 1280x800 on the Lenovo, 1024x768 on the old monitor on flat). Of course, if you set to a resolution that does not have the same aspect ratio (e.g., 1600x1200 on the 23" ViewSonic), then that no longer holds. But everything displayed on my Ubuntu system gets noticeable skewed in these cases (icons, fonts) - unless you can get the system does something similar to letter-boxing done with movies.

That being said, (I am fairly sure) all the Ferret / PyFerret software still supports separate DPI-X and DPI-Y. If wanted to, we could have /DPIX and /DPIY, and /DPI will match both. Not sure if we want to, however.

[karlmsmith]

Comment by steven.c.hankin on 17 Jun 2013 16:04 UTC
2 quick comments:

1. Aren't the qualifier names "/XDOT" and "/YDOT" a bit inconsistent with syntax already in Ferret, such as "PPL$XPIXEL" and "PPL$YPIXEL"? In other contexts in Ferret doesn't the word "dot" refer to a period character as used in Ferret attribute names?

2. Controlling dots-per-inch is a nice goal, but I fear it will come back to bite you repeatedly. How reliably does the OS even know (or pay attention to) the physical size of the display? I'm thinking about the microscopic sizes of fonts as they show up on my laptop .... (Or does DPI refer to "dots per Denbo inch" ... something that we can control FWIW.)

[karlmsmith]

Comment by @AndrewWittenberg on 17 Jun 2013 22:18 UTC
You're right -- I had forgotten that we already have PPL$XPIXEL and PPL$YPIXEL. So I agree we should name the qualifiers /XPIXEL and /YPIXEL (rather than /XDOT and /YDOT).

On Steve's comment 2: Yes, I did mean "dots per Denbo inch". Could we make the Denbo inch also output to a PostScript inch?

Karl: from the sound of it, DPI should be sufficient for now -- no need to split it into DPIX and DPIY.

Is everyone on board with XINCHES rather than XPAGE? If so, we'd now have

SET WINDOW/XINCHES/YINCHES/XPIXELS/YPIXELS/DPI/SIZE/ASPECT/THICKNESS
FRAME/FILE=test.png/XPIXELS/YPIXELS/DPI

Sample usage would be:

! default window, with 1-point (and 1-pixel) lines
SET WINDOW/XI=11/YI=8.5/DPI=72/THICK=1 1

! some equivalents
SET WINDOW/XI=11/YI=8.5/XP=792/THICK=1 1
SET WINDOW/XP=792/YP=612/DPI=72/THICK=1 1
SET WINDOW/XI=11/XP=792/ASPECT=`8.5/11`/THICK=1 1
SET WINDOW/SIZE=1/ASPECT=`8.5/11`/DPI=72/THICK=1

! 11"x8.5" PostScript output
FRAME/FILE=test.ps

! 792x612 pixel PNG output
FRAME/FILE=test.png

! ways to create a double-sized PNG (all equivalent)
FRAME/FILE=test.png/DPI=144
FRAME/FILE=test.png/XP=1584
FRAME/FILE=test.png/YP=1224

! same window but with 2-point, 2-pixel base-lines
SET WINDOW/XI=11/YI=8.5/DPI=72/THICK=2 1

! double-sized window with 1-point, 2-pixel base-lines
SET WINDOW/XI=11/YI=8.5/DPI=144/THICK=1 1

[karlmsmith]

Comment by steven.c.hankin on 17 Jun 2013 22:43 UTC
Just personal opinion on this matter: XINCHES, XPIXELS, and DPI over-specify the problem and raise the possibility of self-contradictory specifications. Error checking and reporting on the interactions of the qualifiers will be needed in the code (as /ASPECT already requires). Is the net contribution of the over-specification positive or negative? It depends, I suppose, on whether these qualifiers will be so commonly used in such a variety of ways that the extra convenience (up side) over-rides the extra complexity (down side).

My personal vote would be to drop /DPI as a qualifier. A user wanting to specify DPI could still do so via

LET DPI = 144
SET WINDOW/XPIXEL=1584/XINCHES=`1584/DPI` 1

which seems pretty clean and self-evident. There's also the detail that the name "DPI" refers to "dots", which may send a user chasing down the detailed documentation in order to be sure she understands the meaning of the qualifier.

[karlmsmith]

Comment by @AndrewWittenberg on 17 Jun 2013 23:54 UTC
Ok, I can live without DPI.

SIZE and ASPECT are redundant now too. But shall we keep them around for backwards-compatibility and convenenience?

If so, then we're down to:

! default window, with 1-point (and 1-pixel) lines
SET WINDOW/XI=11/YI=8.5/XP=792/THICK=1 1

! some equivalents
SET WINDOW/XP=792/YP=612/XI=11/THICK=1 1
SET WINDOW/XI=11/XP=792/ASPECT=`8.5/11`/THICK=1 1
SET WINDOW/SIZE=1/ASPECT=`8.5/11`/XP=792/THICK=1

! 11"x8.5" PostScript output
FRAME/FILE=test.ps

! 792x612 pixel PNG output
FRAME/FILE=test.png

! ways to create a double-sized PNG (all equivalent)
FRAME/FILE=test.png/XP=1584
FRAME/FILE=test.png/YP=1224

! usual window but with 2-point, 2-pixel base-lines
SET WINDOW/XI=11/YI=8.5/XP=792/THICK=2 1

! double-sized window with 1-point, 2-pixel base-lines
SET WINDOW/XI=11/YI=8.5/XP=1584/THICK=1 1

Suggested defaults:

XINCHES=11
YINCHES=8.5
XPIXELS=792
YPIXELS=XPIXELS*YINCHES/XINCHES
ASPECT=YINCHES/XINCHES
SIZE=XINCHES/11

Over-specification would cause the lowest-precedence qualifier to be ignored, producing a warning, e.g.:

yes? SET WINDOW/XI=11/YI=8.5/ASPECT=2
 **WARNING: SET WINDOW is over-specified, ignoring /ASPECT

yes? SET WINDOW/XI=11/YI=8.5/SIZE=1
 **WARNING: SET WINDOW is over-specified, ignoring /SIZE

yes? SET WINDOW/XI=11/YI=8.5/XP=792/YP=612
 **WARNING: SET WINDOW is over-specified, ignoring /YPIXELS

[karlmsmith]

Comment by steven.c.hankin on 18 Jun 2013 00:43 UTC
I like your approach to handling over-specified commands. (The reference to "/YPOINTS is a typo, no?)

But two fundamental points to explore further:

1. In the preceding comments SIZE is defined in inches. Since the intention of SIZE is (historically) to control the size of a visible window on the screen, shouldn't SIZE be interpreted in pixels, instead of inches?
2. If the goal of /XINCHES and /YINCHES is to control the size of the resulting PDF, would they do better as controls on the FRAME command?

Example session:

SET WINDOW/XPIXEL=792/YPIXEL=612
GO ptest                         ! creates a window of the indicated pixel size
FRAME/FILE=out.png               ! creates an image the same pixel size as the window 
FRAME/FILE=out.pdf/XINCHES=8.5   ! creates a PDF 8.5" wide

! now resize the window
SET WINDOW/SIZE=0.3              ! makes the window pixel size smaller based on area
FRAME/FILE=out.png               ! creates an image the pixel size of the new window 
FRAME/FILE=out.pdf/XINCHES=8.5   ! identical to previous PDF (window size is irrelevant)

[karlmsmith]

Comment by @AndrewWittenberg on 18 Jun 2013 18:57 UTC
Replying to [comment:15 steven.c.hankin]:

(The reference to "/YPOINTS is a typo, no?)

Yes, a typo -- now fixed above.

[karlmsmith]

Comment by @AndrewWittenberg on 18 Jun 2013 19:56 UTC
My motivation for specifying window dimensions in "Denbo or PostScript inches" (and making that the go-to unit) is to move to a more "vector" graphics paradigm, with device-independence of the "virtual page". That way we can specify line thicknesses in "points" rather than "pixels", and take advantage of the antialiasing capabilities of our new Python graphics libraries to produce a more WYSIWYG display for vector graphics.

Under that approach, XINCH or YINCH needs to be provided to SET WINDOW, so Ferret will know how thick to make a 1-point line; otherwise it wouldn't know how many pixels per inch. (With antialiasing, even a fractional-pixel line can be rendered now with PyFerret's graphics.)

If you agree with that (and I'm not sure you do), then since we'd be specifying the inch-dimensions of the window anyhow, to keep things simple we could just pass that straight through to any vector output with FRAME.

To enlighten this discussion, take a look at Inkscape vector graphics editor (File-> Document Properties). In that dialog, one can set the default units (px, pt, in, cm) as well as the page size in those units. (The default dpi for Inkscape is 90, i.e. 90px = 1in.)

[karlmsmith]

Comment by steven.c.hankin on 18 Jun 2013 20:31 UTC
I fully agree with the logic of the points you've made.

My concern about /XINCHES and /YINCHES on the window command has to do with the possibility that it may be opening a Pandora's box of graphical layout issues. For /XIN and /YIN to work as a SET WINDOW options, they need to set the PLOT+ axis lengths and all of the associated offsets to locate labels, etc. Issues are raised about whether default text font sizes should be adjusted as the window size in inches is enlarged. (I'd say "no", but realizing that this means the prominence of text on the page will diminish as the /XIN, /YIN specification is increased.

There is partial logic to do all of this already -- associated with the /ASPECT qualifier. My recollection, though, is that inside of the /ASPECT logic, the area of the page is held constant. This means that the layout logic has been tested only over a small range of values. There is also related logic in the /TEXT_PROMINENCE qualifier of DEFINE VIEW.

In short -- my feeling is that some experimentation inside of the code is needed before making a commitment. This small script illustrates the nature of the work that is needed.

GO ptest
PPL SIZE 15,20
go ptest

[karlmsmith]

Comment by @AndrewWittenberg on 18 Jun 2013 21:01 UTC
Thanks Steve. I was hoping to avoid Pandora's box by simply having SET WINDOW do the following: (1) compute the DPI from the input qualifiers and/or their defaults; (2) compute/input the XPIX & YPIX, to set the window size and provide a default size for the raster forms of FRAME; (3) save the XIN & YIN for possible later use by the vector forms of FRAME.

Font sizes are already specified in Denbo inches, aren't they?

Some new logic would be required to handle all the various combinations of these qualifiers and their defaults. But the only new action-items for the command would be to store the DPI (for use with line thickness) and the XIN & YIN (to set the dimensions of any later vector output).

[karlmsmith]

Comment by steven.c.hankin on 18 Jun 2013 23:30 UTC
I wonder if the following slight (only) further simplification might still keep Pandora's box closed:
o yes -- SET WINDOW supports /XINCHES, /YINCHES, /XPIXEL, and /YPIXEL
o no -- there is no concept of DPI -- Xinches and Xpixels do not interact, except through consistency checks about the window aspect ratio. (Pixels and inches are mutually exclusive, no? Seems like one applies only to PDFs; the other only to rasters.)

Then

SET WINDOW/XINCHES=6/YINCHES=8 saves the 6x8 inch size as a '''default''' for later FRAME commands. (Its just a convenience. The same control is available when saving a PDF via the FRAME command)

SET WINDOW/XPIXEL=600/YPIXEL=800 sets the window size (and the size of future raster images saved via FRAME)

[karlmsmith]

Comment by @AndrewWittenberg on 19 Jun 2013 20:28 UTC
Not having a DPI would be ok for antialiased graphics ("high quality"). But without it, we'd have to assign some conversion for line thicknesses with non-antialiased graphics ("draft quality") -- e.g. 1 point = 1 pixel (DPI=72).

Or we could just remove draft-quality graphics altogether (that's fine with me).

[karlmsmith]

Comment by @karlmsmith on 20 Jun 2013 00:12 UTC
Realized, since I am recording the drawing commands in memory (using QPicture in Qt, using SVG surface in memory in Cairo), and then "replaying" those drawing commands to create desired PNG, PDF, etc., I cannot define different base line widths depending on whether I am writing to PNG or to PDF.

Qt explicitly says the "replaying" of the QPictures will give WYSIWYG (explaining this is just what you need for print-preview). Thus line widths are scaled along with everything else.

I do not know if Cairo does the same with line widths when replaying the stored SVG commands to a PNG. Hopefully WYSIWYG to match Qt behavior.

So if line thickness is to be specified in points then I need somehow get a DPI to convert to pixel thickness, thus the need for /XINCHES, /YINCHES.

If the line thickness is in pixels, then I do not need the DPI, but the user will need to tweak the global line thickness scaling factor to make one pixel thickness match whatever line thickness in points is desired in the PDF finally output. Having /XINCHES and /YINCHES ahead of time will enable the program to figure out that factor.

So thinking along the lines of Andrews comment:14 except I am inclined to just throw an error if over-specified (so I don't have to figure out and explain priorities).

Steve mentioned that there might be a way to make /XINCHES and /YINCHES the Denbo inch size of the plot as well, and still have everything properly laid out in the default Ferret plot. If this can be done, then /XINCHES and /YINCHES becomes a lot more meaningful in the SET WINDOW command. To be investigated.

I will work on this and see what I can come up with. Then we can evaluate and go from there.

[karlmsmith]

Comment by @karlmsmith on 11 Jul 2013 18:41 UTC
Implemented SET WINDOW /XINCHES= /YINCHES= /XPIXELS= /YPIXELS= /TEXTPROM=

The default window size (/XINCHES, /YINCHES) is 10.5 inches wide and 8.5 inches high, with margins of 1.375 inches all around; thus plot axes of 7.75 inches wide and 5.75 inches high which has an axis aspect ratio of 0.74. This change was made to have the default page size fit on a landscape letter-sized page.

Compare to traditional ferret defaults 10.2 inches wide by 8.8 inches high with a left margin of 1.2, right margin of 1.0, and top and bottom margin of 1.4; thus plot axes of 8 inches wide and 6 inches high which has an axis aspect ratio of 0.75.

/XINCHES and /YINCHES set the window size using the display resolution. This is also the default size for vector images (PS, PDF, SVG) output. /XPIXELS and /YPIXELS is the pixel size of the displayed image and is the default size for raster images (PNG). All /XPIXELS and /YPIXELS do is set the image scaling factor in the viewer. Ferret is unaware that the displayed image is scaled when shown to the user. Only three of the four /XINCHES, /YINCHES, /XPIXELS, /YPIXELS can be given.

The /ASPECT= option is also available for specifying size given just width or height. Thus with /ASPECT, only one of /XINCHES or /YINCHES can be given, and only one of /XPIXELS or /YPIXELS can be given.

The /SIZE= option is also available. The /SIZE=n option now just set the image scaling factor to sqrt(n), and sets the /XPIXELS and /YPIXELS default raster image size accordingly, i.e., /XPIXELS = /XINCHES * DPI-X * sqrt(n); thus /SIZE is incompatible with /XPIXELS and /YPIXELS. By default, /SIZE=0.7 as in Ferret. If /SIZE=1, the displayed image will be inch size specified.

Over-specification of size results in an error. The default window is /XINCHES=10.5 /YINCHES=8.5 /SIZE=0.7.

Default margin size, default tic-mark and other lengths, default text heights are all now scaled according to the window size: scale = sqrt(widthheight/10.58.5). This value is given in the symbol PPL$SCALE. So major tic marks will by default have full length of 0.25 * PPL$SCALE (typically only the outer half is drawn). /TEXTPROM applies further scaling to default text heights. Any lengths or text heights specified by PPL commands are used as given; they are not scaled.

The values set by PPL LABSET are now used as the default heights of main labels (HLAB1) and axis labels (HXLAB and HYLAB). The main label may have its size automatically reduced if too large. The dataset and logo labels are still (scaled) hard-coded sizes. (The fourth size in LABSET, HLABS, is not used for the height of any automatic labels.)

Because window sizes can now vary, all these PPL settings are stored for each window. Switching between windows will reinstate the last PPL values for that window. PPL RESET will reset to the default (scaled, if appropriate) values for the currently active window only.

Line widths are now in units of points. The default line thickness scaling factor for windows changed to 0.75 so the default line thickness in plots closely match that given in Ferret (96 DPI * 0.75 pt / 72 pt_per_in = 1 pixel). Figured better to keep the width definition clean and adjust the default scaling of this width.

Print options dialog removed from the viewers when saving PS and PDF. PS and PDF are no longer scaled and centered to fit a letter-sized window since the desired size is now specified in the FRAME command, and the image size on screen is now always used when using the Image->Save As... command. But this means images that do not fit on a letter-sized page will get cut-off. The full page is used (no margins) as margin specification was not available in older Qt. Software for printing PS and PDF almost always gives the option for fitting and centering, so this should not be an issue, and it makes incorporating images into documents easier. Removal of the print options dialog also removes some confusion, as one is saving, not printing.

Closing out this ticket as I think this completes the objective of this ticket. There might be issues with viewports (although plots appear correct with casual examination); to be determined and, if so, a separate ticket will be created.