On 2015-08-20 21:48+0100 Phil Rosenberg wrote:
> On 20 August 2015 at 20:44, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
>> [...]If you agree with this approach for setting default PLplot-wide
>> plsc->xdpi and plsc->ydpi values will you please push a commit to this
>> effect to get this preliminary out of the way?
>
> This seems perfectly sensible to me. I will make this change and commit it.
Hi Phil (and Jim too since this affects the new device he is
implementing):
I have now looked further, and it turns out this proposed change will
need a follow-up commit because the non-zero default values for
plsc->xdpi and plsc->ydpi will interfere with the following type of
logic that is currently in our device-driver code:
software@raven> grep -A 6 'if.*dpi.*0' drivers/*
drivers/cgm.c: if ( pls->xdpi <= 0 )
drivers/cgm.c- {
drivers/cgm.c-// This corresponds to a typical monitor resolution of 4
pixels/mm.
drivers/cgm.c- plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/cgm.c- }
drivers/cgm.c- else
drivers/cgm.c- {
--
drivers/gd.c: if ( pls->xdpi <= 0 )
drivers/gd.c- {
drivers/gd.c-// This corresponds to a typical monitor resolution of 4 pixels/mm.
drivers/gd.c- plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/gd.c- }
drivers/gd.c- else
drivers/gd.c- {
--
drivers/gd.c: if ( pls->xdpi <= 0 )
drivers/gd.c- {
drivers/gd.c-// This corresponds to a typical monitor resolution of 4 pixels/mm.
drivers/gd.c- plspage( 4. * 25.4, 4. * 25.4, 0, 0, 0, 0 );
drivers/gd.c- }
drivers/gd.c- else
drivers/gd.c- {
--
drivers/ps.c: if ( pls->xdpi <= 0 )
drivers/ps.c- pls->xdpi = 72.;
drivers/ps.c: if ( pls->ydpi <= 0 )
drivers/ps.c- pls->ydpi = 72.;
drivers/ps.c-
drivers/ps.c- pxlx = YPSSIZE / LPAGE_X;
drivers/ps.c- pxly = XPSSIZE / LPAGE_Y;
drivers/ps.c-
drivers/ps.c- if ( text )
--
drivers/psttf.cc: if ( pls->xdpi <= 0 )
drivers/psttf.cc- pls->xdpi = 72.;
drivers/psttf.cc: if ( pls->ydpi <= 0 )
drivers/psttf.cc- pls->ydpi = 72.;
drivers/psttf.cc-
drivers/psttf.cc-
drivers/psttf.cc- pxlx = YPSSIZE / LPAGE_X;
drivers/psttf.cc- pxly = XPSSIZE / LPAGE_Y;
drivers/psttf.cc-
--
drivers/qt.cpp: if ( pls->xdpi <= 0. )
drivers/qt.cpp- dpi = DEFAULT_DPI;
drivers/qt.cpp- else
drivers/qt.cpp- dpi = pls->xdpi;
drivers/qt.cpp-
drivers/qt.cpp- // Shamelessly copied on the Cairo stuff :)
drivers/qt.cpp- if ( pls->xlength <= 0 || pls->ylength <= 0 )
--
drivers/qt.cpp: if ( pls->xdpi <= 0. )
drivers/qt.cpp- dpi = DEFAULT_DPI;
drivers/qt.cpp- else
drivers/qt.cpp- dpi = pls->xdpi;
drivers/qt.cpp-
drivers/qt.cpp- // Set the plot size to the memory buffer size, on the off
chance
drivers/qt.cpp- // that they are different.
--
drivers/wingcc.c: if ( pls->xdpi <= 0 ) // Get DPI from windows
drivers/wingcc.c- {
drivers/wingcc.c- plspage( GetDeviceCaps( dev->hdc, HORZRES ) /
GetDeviceCaps( dev->hdc, HORZSIZE ) * 25.4,
drivers/wingcc.c- GetDeviceCaps( dev->hdc, VERTRES ) /
GetDeviceCaps( dev->hdc, VERTSIZE ) * 25.4, 0, 0, 0, 0 );
drivers/wingcc.c- }
drivers/wingcc.c- else
drivers/wingcc.c- {
--
drivers/wxwidgets_dev.cpp: if ( pls->xdpi == 0.0 || pls->ydpi == 0 )
drivers/wxwidgets_dev.cpp- {
drivers/wxwidgets_dev.cpp: if ( pls->xdpi == 0.0 && pls->ydpi == 0 )
drivers/wxwidgets_dev.cpp- c_plspage( 90, 90, 0, 0, 0, 0 );
drivers/wxwidgets_dev.cpp- else
drivers/wxwidgets_dev.cpp- {
drivers/wxwidgets_dev.cpp- PLFLT dpi = MAX( pls->xdpi, pls->ydpi );
drivers/wxwidgets_dev.cpp- pls->xdpi = dpi;
drivers/wxwidgets_dev.cpp- pls->ydpi = dpi;
In the cgm and gd cases, the cure is simply to remove those stanzas so
that those devices use the PLplot default or user-set plsc->xdpi and
plsc->ydpi values rather than the current special default for those devices of
4*25.4 = 101.6 (!).
I am pretty sure for the ps and psttf cases that the results should be
completely independent of default or user-set dpi. After all, a
printer point unit (important for PostScript) is defined to be 1/72 of
an inch, and allowing the user to fiddle with that strikes me as a
hack to use a false definition of a printer point to scale the
results. Instead, I am pretty sure scaling should be done using the
-geometry option or the equivalent call to plspage with non-zero 3rd
and following arguments.
I am not sure quite what needs to be done in the qt, wingcc, and
wxwidgets cases, but I am pretty sure it will be obvious once one of
us takes a detailed look at the relevant code.
After your commit creating the default plsc->xdpi and plsc->ydpi
values, I would be willing to take responsibility for the required
logic modifications of cgm, gd, ps, psttf, and qt. Would you be
similarly willing to do the same thing for the wingcc and wxwidgets
devices?
@Jim:
I assume you are completely familiar with dpi issues for both wingcc
and your new device that is a modernized version of that. So chime in
here please, if you see any problems with letting users (or PLplot by
default) set dpi values for those devices.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
