> On Aug 20, 2015, at 7:43 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
>
>> 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.
>
My plan was to default to the DPI setting returned by the windows API.
Microsoft has documentation on how to write code that would be compatible with
high-dpi and regular devices. I don't see any major problems with letting the
user set the dpi other than poor quality output.
My goal is to honor the font size height specified by the user as the default
behavior.
> 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
