My feeling (but happy to have my mind changed) is that for consistency all rasterised drivers should all adopt the same strategy. So either plstrm_init sets the dpi to a constant, or alternatively plstrm_init has platform dependant code to set it to the monitor resolution. Those drivers which then require a specific DPI (e.g. ps) can then set that as they need.
I think however it is important to bear in mind that plplot is a library - not a program. I think that the most important thing is simplicity of use (including good documentation - not that I'm good at that) so it is much easier for us to document and conforms closer to the principle of least surprise if we state a single default dpi for raster graphics. This would mean, for example that a plot rendered by an interactive driver, then redrawn with a non-interactive driver would look (approximately) the same. @Jim You have perhaps already looked into this but if not this page https://msdn.microsoft.com/en-gb/library/windows/desktop/dn469266(v=vs.85).aspx is worth a read. You should note that it would appear that if you do not call SetProcessDpiAwareness() then Windows will assume the application is not scale aware and it will scale your text and UI elements for you (although with lower quality than if you did it yourself). This will give you double scaling of your text which is bad. However, if you do call SetProcessDpiAwareness(), then you are potentially overriding a call made by the library user and you are forcing a user to do what you want and not what they want. For this reason I would suggest that you do not attempt to grab the monitor dpi, but instead allow the user to decide whether to be dpi aware and deal with it themselves by calling plspage. While we are on the topic of standardising DPI is it also worth standardising page size? It might be useful to have a set of default sizes, perhaps portrait A4, for noninteractive drivers, and a default size for interactive drivers which would be a scaled version of that for noninteractive drivers as A4 is significantly bigger than my laptop screen assuming 90 dpi? Not sure if raster and non raster drivers should have different default sizes? Phil On 21 August 2015 at 08:15, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > Hi Jim: > > On 2015-08-20 23:41-0400 Jim Dishaw wrote: > >> 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. > > > Good. > > But what do you do when you see that both plsc->xdpi and plsc->ydpi > are set to PLPLOT_DEFAULT_API? (See my second previous post in this > thread concerning PLPLOT_DEFAULT_API.) Did the user set that because > they wanted that exact value, or is that the default value which you > can then override by following the Microsoft prescription? > > Maybe for the default we should set > > plsc->xdpi = -PLPLOT_DEFAULT_API; > plsc->ydpi = -PLPLOT_DEFAULT_API; > > as a well-known signal that we want to use default DPI? Most drivers > would then simply use PLPLOT_DEFAULT_API if plsc->[xy]dpi was set to > the negative of that, but some might use a different default value > instead (such as the Microsoft prescription) if either plsc->xdpi > or plsc->ydpi was -PLPLOT_DEFAULT_API? > > Just thinking aloud here to stir up more discussion.... > > > 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
