plplot-devel

[Plplot-devel] Driver behavior questions and wingdi preview

[Jim D. <ji...@di...>]

I have two questions on driver behavior that I’m trying to figure out.  

In the new wingdi driver I have implemented text rendering using the GDI interface.  The current implementation honors the height specified in chrht.  I have measured the heights both on the screen and when printed via wingdi using the windows print function.  The heights on the output device matches chrht; however, they appear smaller than the other device outputs (e.g. ps).  Should I scale the fonts up?

When printing, the output matches the content on the screen exactly.  If the background is black on the screen, it is black on the print version.  When I compare to the ps driver, it appears the colored background is suppressed.  Should I do the same when printing from the wingdi driver?

Attached are two patch series for wingdi.  The driver is still in an alpha state, so I don’t recommend applying to master or any branch that is important. There is still some issues with the multiple EOP that will require a keypress after a redraw event (e.g. resize, printing).  Also, I have forced debugging, so there is a fair amount of output on the console. Most of the examples appear to render correctly.  The driver does not support alpha blending or native gradient fills. I’m not sure if it is worthwhile to add these features in this driver, particular with a Direct2D version on the horizon. 

 Also this version of the driver is non-unicode to make a lowest common denominator driver.  I’m going to add unicode support because that appears to be the standard used by all the maintained/newer drivers.

Any feedback is greatly appreciated.

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Greg J. <gv...@gm...>]

The recent addition to struct wingcc_dev:
PLGraphicsIn gin;
Serves no purpose (other than to break backwards compatibility)
and shouldn't be propagated.  It was only thrown in there because xwin.c has
something similar.

  I would like to try wingdi.c but dont have a baseline file to run a patch
against; if you could shoot me the full file (wingdi.c) I could try it.

The cursor coordinate transformations need a ScreenToClient adjustment, I
think this works:

   GetClientRect(cursorwnd, &rcClient);

    ScreenToClient(cursorwnd, (LPPOINT)&Message.pt);

    gin->pX = Message.pt.x;
    gin->pY = (rcClient.bottom - rcClient.top) - Message.pt.y;
    gin->dX = (PLFLT) gin->pX/ (PLFLT) (rcClient.right - rcClient.left - 1);
    gin->dY = (PLFLT) gin->pY/ (PLFLT) (rcClient.bottom - rcClient.top - 1);

When the window is created, it really has no business becoming the
foreground;
We would like to see it, though:
    //
    ShowWindow( dev->hwnd, SW_SHOWDEFAULT );
    BringWindowToTop( dev->hwnd );

  I think, instead of buying into UNICODE/TCHAR ansii, just convert to
unicode where needed and call the W functions.  Why keep it complicated.
Also, I think the pointer #ifdef/#endif for 64 bits can just use the
64-bits version now for either compilation.

On Wed, Jun 10, 2015 at 6:44 PM, Jim Dishaw <ji...@di...> wrote:

> I have two questions on driver behavior that I’m trying to figure out.
>
> In the new wingdi driver I have implemented text rendering using the GDI
> interface.  The current implementation honors the height specified in
> chrht.  I have measured the heights both on the screen and when printed via
> wingdi using the windows print function.  The heights on the output device
> matches chrht; however, they appear smaller than the other device outputs
> (e.g. ps).  Should I scale the fonts up?
>
> When printing, the output matches the content on the screen exactly.  If
> the background is black on the screen, it is black on the print version.
> When I compare to the ps driver, it appears the colored background is
> suppressed.  Should I do the same when printing from the wingdi driver?
>
> Attached are two patch series for wingdi.  The driver is still in an alpha
> state, so I don’t recommend applying to master or any branch that is
> important. There is still some issues with the multiple EOP that will
> require a keypress after a redraw event (e.g. resize, printing).  Also, I
> have forced debugging, so there is a fair amount of output on the console.
> Most of the examples appear to render correctly.  The driver does not
> support alpha blending or native gradient fills. I’m not sure if it is
> worthwhile to add these features in this driver, particular with a Direct2D
> version on the horizon.
>
>  Also this version of the driver is non-unicode to make a lowest common
> denominator driver.  I’m going to add unicode support because that appears
> to be the standard used by all the maintained/newer drivers.
>
> Any feedback is greatly appreciated.
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Phil R. <p.d...@gm...>]

Hi Jim
The documentation states that the provided text height will be in mm.
The user can set dpi with plspage so you should use the PLStream->xdpi
and PLStream->ydpi to size your text in pixels. In case the user
hasn't set this you should use a sensible default. Of course the
actual value will depend on the monitor, but rather than try to grab
this it seems that there are two standards and for consistency you
should use one of these. One is to use 72 pixels per inch so that 1
pixel = 1 pt. The other is 90 pixels per inch which seems to be the
default for most svg renderers. For wxWidgets I chose 90 pixels per
inch. I also noticed tect seems a little smaller than the example
online (from the cairo driver?) but it does as described in the
documentation so I am happy with that.

Then one question is what happens when you resize, do you honour the
size given initially or do you rescale it with the rest of the plot. I
chose to honour the initial size, but intend to allow the user to
select in the future.

Phil

On 11 June 2015 at 07:16, Greg Jung <gv...@gm...> wrote:
> The recent addition to struct wingcc_dev:
> PLGraphicsIn gin;
> Serves no purpose (other than to break backwards compatibility)
> and shouldn't be propagated.  It was only thrown in there because xwin.c has
> something similar.
>
>   I would like to try wingdi.c but dont have a baseline file to run a patch
> against; if you could shoot me the full file (wingdi.c) I could try it.
>
> The cursor coordinate transformations need a ScreenToClient adjustment, I
> think this works:
>
>    GetClientRect(cursorwnd, &rcClient);
>
>     ScreenToClient(cursorwnd, (LPPOINT)&Message.pt);
>
>     gin->pX = Message.pt.x;
>     gin->pY = (rcClient.bottom - rcClient.top) - Message.pt.y;
>     gin->dX = (PLFLT) gin->pX/ (PLFLT) (rcClient.right - rcClient.left - 1);
>     gin->dY = (PLFLT) gin->pY/ (PLFLT) (rcClient.bottom - rcClient.top - 1);
>
> When the window is created, it really has no business becoming the
> foreground;
> We would like to see it, though:
>     //
>     ShowWindow( dev->hwnd, SW_SHOWDEFAULT );
>     BringWindowToTop( dev->hwnd );
>
>   I think, instead of buying into UNICODE/TCHAR ansii, just convert to
> unicode where needed and call the W functions.  Why keep it complicated.
> Also, I think the pointer #ifdef/#endif for 64 bits can just use the 64-bits
> version now for either compilation.
>
> On Wed, Jun 10, 2015 at 6:44 PM, Jim Dishaw <ji...@di...> wrote:
>>
>> I have two questions on driver behavior that I’m trying to figure out.
>>
>> In the new wingdi driver I have implemented text rendering using the GDI
>> interface.  The current implementation honors the height specified in chrht.
>> I have measured the heights both on the screen and when printed via wingdi
>> using the windows print function.  The heights on the output device matches
>> chrht; however, they appear smaller than the other device outputs (e.g. ps).
>> Should I scale the fonts up?
>>
>> When printing, the output matches the content on the screen exactly.  If
>> the background is black on the screen, it is black on the print version.
>> When I compare to the ps driver, it appears the colored background is
>> suppressed.  Should I do the same when printing from the wingdi driver?
>>
>> Attached are two patch series for wingdi.  The driver is still in an alpha
>> state, so I don’t recommend applying to master or any branch that is
>> important. There is still some issues with the multiple EOP that will
>> require a keypress after a redraw event (e.g. resize, printing).  Also, I
>> have forced debugging, so there is a fair amount of output on the console.
>> Most of the examples appear to render correctly.  The driver does not
>> support alpha blending or native gradient fills. I’m not sure if it is
>> worthwhile to add these features in this driver, particular with a Direct2D
>> version on the horizon.
>>
>>  Also this version of the driver is non-unicode to make a lowest common
>> denominator driver.  I’m going to add unicode support because that appears
>> to be the standard used by all the maintained/newer drivers.
>>
>> Any feedback is greatly appreciated.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Alan W. I. <ir...@be...>]

On 2015-06-10 21:44-0400 Jim Dishaw wrote:

> [...]The driver does not support alpha blending or native gradient fills.
I’m not sure if it is worthwhile to add these features in this driver,
particular with a Direct2D version on the horizon.

To Jim and Aaron:

I didn't completely understand what Jim said above at first, and that
motivated me to look up (via google searches) what Windows subsystems
supported the important alpha blending and native (linear) gradient
capabilities.  It appears from what I skimmed that both GDI+ and
Direct2D support those capabilities which is also consistent with what
Jim said above.

@Jim: could you please confirm I now have the correct overview?

If that overview is correct, I am hoping we will end up with a driver
that supports alpha blending and native gradient via the
GDI/GDI+/Direct2D API's (only available for newer Windows platforms)
and possibly (if Aaron decides to work on it) also for the
GDI/GDI+/Uniscribe API's (available for a wider range of Windows
platforms than GDI/GDI+/Direct2D).  In the former case it does make
sense to go with Direct2D support of alpha blending and gradient fills
if there are some advantages to that API over the corresponding GDI+
API.  Of course, if/when the GDI/GDI+/Uniscribe approach is
implemented, it will need to use the GDI+ API to support alpha
blending and native gradients for the driver, but I am fine with that
from the overview perspective.

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
__________________________

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Jim D. <ji...@di...>]

> On Jun 11, 2015, at 11:42 AM, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2015-06-10 21:44-0400 Jim Dishaw wrote:
> 
>> [...]The driver does not support alpha blending or native gradient fills.
> I’m not sure if it is worthwhile to add these features in this driver,
> particular with a Direct2D version on the horizon.
> 
> To Jim and Aaron:
> 
> I didn't completely understand what Jim said above at first, and that
> motivated me to look up (via google searches) what Windows subsystems
> supported the important alpha blending and native (linear) gradient
> capabilities.  It appears from what I skimmed that both GDI+ and
> Direct2D support those capabilities which is also consistent with what
> Jim said above.
> 
> @Jim: could you please confirm I now have the correct overview?

The GDI API only supports a limited gradient fill capability.  Essentially it can do gradients with a vertical or horizontal orientation.

GDI+ supports horizontal, vertical, and diagonal gradient fills.  It can also do a “path gradient,” which is a closed shape with a gradient that changes from an interior point to the edges.

GDI has the ability to alpha blend a bitmap.  Thus, to implement alpha blending in GDI, the driver would need to draw to a bitmap, apply the alpha blending (possibly sectioning the bitmap if the alpha value is not constant over the bitmap), and blit the bitmap(s) to the window.  Not a difficult change, but how important is it to add?

GDI+ and direct2d has alpha blending brushes and the ability to specify alpha value in colors.
 
> 
> If that overview is correct, I am hoping we will end up with a driver
> that supports alpha blending and native gradient via the
> GDI/GDI+/Direct2D API's (only available for newer Windows platforms)
> and possibly (if Aaron decides to work on it) also for the
> GDI/GDI+/Uniscribe API's (available for a wider range of Windows
> platforms than GDI/GDI+/Direct2D).  In the former case it does make
> sense to go with Direct2D support of alpha blending and gradient fills
> if there are some advantages to that API over the corresponding GDI+
> API.  Of course, if/when the GDI/GDI+/Uniscribe approach is
> implemented, it will need to use the GDI+ API to support alpha
> blending and native gradients for the driver, but I am fine with that
> from the overview perspective.

From what I can tell, Direct2D is much faster than GDI+ and easier to work with.

It sounds like there will be three drivers

wingdi:  GDI only (and possibly an alpha blending capability) with ASCII and UNICODE (if available) text rendering
wingdi+: GDI+ (includes alpha blending, maybe native gradients) with UNICODE text rendering
wind2d: Direct2D (includes alpha blending, native gradients) with UNICODE text rendering

Fortunately, I think the three drivers will be able to share some code.

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Alan W. I. <ir...@be...>]

On 2015-06-11 12:20-0400 Jim Dishaw wrote:

>
>> On Jun 11, 2015, at 11:42 AM, Alan W. Irwin <ir...@be...> wrote:
>>
>> On 2015-06-10 21:44-0400 Jim Dishaw wrote:
>>
>>> [...]The driver does not support alpha blending or native gradient fills.
>> I’m not sure if it is worthwhile to add these features in this driver,
>> particular with a Direct2D version on the horizon.
>>
>> To Jim and Aaron:
>>
>> I didn't completely understand what Jim said above at first, and that
>> motivated me to look up (via google searches) what Windows subsystems
>> supported the important alpha blending and native (linear) gradient
>> capabilities.  It appears from what I skimmed that both GDI+ and
>> Direct2D support those capabilities which is also consistent with what
>> Jim said above.
>>
>> @Jim: could you please confirm I now have the correct overview?
>
> The GDI API only supports a limited gradient fill capability.  Essentially it can do gradients with a vertical or horizontal orientation.
>
> GDI+ supports horizontal, vertical, and diagonal gradient fills.  It can also do a “path gradient,” which is a closed shape with a gradient that changes from an interior point to the edges.
>
> GDI has the ability to alpha blend a bitmap.  Thus, to implement alpha blending in GDI, the driver would need to draw to a bitmap, apply the alpha blending (possibly sectioning the bitmap if the alpha value is not constant over the bitmap), and blit the bitmap(s) to the window.  Not a difficult change, but how important is it to add?
>
> GDI+ and direct2d has alpha blending brushes and the ability to specify alpha value in colors.
>
>>
>> If that overview is correct, I am hoping we will end up with a driver
>> that supports alpha blending and native gradient via the
>> GDI/GDI+/Direct2D API's (only available for newer Windows platforms)
>> and possibly (if Aaron decides to work on it) also for the
>> GDI/GDI+/Uniscribe API's (available for a wider range of Windows
>> platforms than GDI/GDI+/Direct2D).  In the former case it does make
>> sense to go with Direct2D support of alpha blending and gradient fills
>> if there are some advantages to that API over the corresponding GDI+
>> API.  Of course, if/when the GDI/GDI+/Uniscribe approach is
>> implemented, it will need to use the GDI+ API to support alpha
>> blending and native gradients for the driver, but I am fine with that
>> from the overview perspective.
>
>> From what I can tell, Direct2D is much faster than GDI+ and easier to work with.
>
> It sounds like there will be three drivers
>
> wingdi:  GDI only (and possibly an alpha blending capability) with ASCII and UNICODE (if available) text rendering
> wingdi+: GDI+ (includes alpha blending, maybe native gradients) with UNICODE text rendering
> wind2d: Direct2D (includes alpha blending, native gradients) with UNICODE text rendering
>
> Fortunately, I think the three drivers will be able to share some code.

Hi Jim:

Thanks for your responses above to my questions and comments.

PLplot implements linear gradients at any angle, but from what you
said it appears GDI+ does not have linear gradient capability at
anything other than 0 deg and 90 deg.  Therefore, it sounds like we
will be forced to use the PLplot core software fallback for gradients
for both the wingdi and wingdi+ device drivers. That's an acceptable
limitation (for example, we use that fallback for -dev xwin) although
the core software fallback gradient result typically looks pretty bad
because of aliasing issues.

Also note there is a choice whether to organize wingdi, wingdi+, and
wind2d as separate, single-device, device drivers or as separate
devices for a single device driver.  That latter choice might make it
a little more convenient to share code between those devices.  I
emphasize what approach you take for these three devices is completely
your choice, but I thought I should at least point out that you do
have that choice.

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
__________________________

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Jim D. <ji...@di...>]

> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Hi Jim
> The documentation states that the provided text height will be in mm.
> The user can set dpi with plspage so you should use the PLStream->xdpi
> and PLStream->ydpi to size your text in pixels. In case the user
> hasn't set this you should use a sensible default. Of course the
> actual value will depend on the monitor, but rather than try to grab
> this it seems that there are two standards and for consistency you
> should use one of these. One is to use 72 pixels per inch so that 1
> pixel = 1 pt. The other is 90 pixels per inch which seems to be the
> default for most svg renderers. For wxWidgets I chose 90 pixels per
> inch. I also noticed tect seems a little smaller than the example
> online (from the cairo driver?) but it does as described in the
> documentation so I am happy with that.

90 dpi is pretty close to the value (96 dpi) that windows reports for most displays.  For high dpi monitors you can get 200 dpi and for printers you get what the device is able to produce (e.g. 600 dpi). There is some hidden magic that windows does to actually put pixels on the screen, so there is some internal conversions between the reported dpi and the actual dpi.  

Evidently, the cell height used by the Hershey fonts is different then the cell height used by Windows fonts (it has something to do with the ascenders and descenders).  That difference in cell height is the reason why for the same value of chrht, the sizes do not match up.  There is a comment in one of the drivers about the need to scale up by to match up the characters with the Hershey fonts.  On my wingdi driver I need to scale by a factor of 1.6 to match the size produced by the SVG driver.

The recommendation in the Windows API is to use GetDeviceCaps () with the LOGPIXELSX/LOGPIXELSY values to get the dpi setting.  Right now I’m ignoring the DPI setting provided by the user.  On native text rendering devices the xdpi/ydpi settings are essentially being used to scale the size of fonts, which (IMHO) abuses the meaning of “DPI”.  

> 
> Then one question is what happens when you resize, do you honour the
> size given initially or do you rescale it with the rest of the plot. I
> chose to honour the initial size, but intend to allow the user to
> select in the future.
> 

Which size are you referring to?  When the window is resized, the driver gets the new dimensions of the client area (via GetClientRect() for displays and GetDeviceCaps() for printers).  It uses the new size to calculate the new scaling between device virtual coordinates (PIXELS_X/PIXELS_Y in PLplot) and the new output device coordinates,  The dpi remains consistent with what Windows reports.

I do need to make some changes to print routine to preserve the same aspect ratio used by the window.  I figure the user would want the print version to match the aspect of the displayed version.

> Phil
> 
> On 11 June 2015 at 07:16, Greg Jung <gv...@gm...> wrote:
>> The recent addition to struct wingcc_dev:
>> PLGraphicsIn gin;
>> Serves no purpose (other than to break backwards compatibility)
>> and shouldn't be propagated.  It was only thrown in there because xwin.c has
>> something similar.
>> 
>>  I would like to try wingdi.c but dont have a baseline file to run a patch
>> against; if you could shoot me the full file (wingdi.c) I could try it.
>> 
>> The cursor coordinate transformations need a ScreenToClient adjustment, I
>> think this works:
>> 
>>   GetClientRect(cursorwnd, &rcClient);
>> 
>>    ScreenToClient(cursorwnd, (LPPOINT)&Message.pt);
>> 
>>    gin->pX = Message.pt.x;
>>    gin->pY = (rcClient.bottom - rcClient.top) - Message.pt.y;
>>    gin->dX = (PLFLT) gin->pX/ (PLFLT) (rcClient.right - rcClient.left - 1);
>>    gin->dY = (PLFLT) gin->pY/ (PLFLT) (rcClient.bottom - rcClient.top - 1);
>> 
>> When the window is created, it really has no business becoming the
>> foreground;
>> We would like to see it, though:
>>    //
>>    ShowWindow( dev->hwnd, SW_SHOWDEFAULT );
>>    BringWindowToTop( dev->hwnd );
>> 
>>  I think, instead of buying into UNICODE/TCHAR ansii, just convert to
>> unicode where needed and call the W functions.  Why keep it complicated.
>> Also, I think the pointer #ifdef/#endif for 64 bits can just use the 64-bits
>> version now for either compilation.
>> 
>> On Wed, Jun 10, 2015 at 6:44 PM, Jim Dishaw <ji...@di...> wrote:
>>> 
>>> I have two questions on driver behavior that I’m trying to figure out.
>>> 
>>> In the new wingdi driver I have implemented text rendering using the GDI
>>> interface.  The current implementation honors the height specified in chrht.
>>> I have measured the heights both on the screen and when printed via wingdi
>>> using the windows print function.  The heights on the output device matches
>>> chrht; however, they appear smaller than the other device outputs (e.g. ps).
>>> Should I scale the fonts up?
>>> 
>>> When printing, the output matches the content on the screen exactly.  If
>>> the background is black on the screen, it is black on the print version.
>>> When I compare to the ps driver, it appears the colored background is
>>> suppressed.  Should I do the same when printing from the wingdi driver?
>>> 
>>> Attached are two patch series for wingdi.  The driver is still in an alpha
>>> state, so I don’t recommend applying to master or any branch that is
>>> important. There is still some issues with the multiple EOP that will
>>> require a keypress after a redraw event (e.g. resize, printing).  Also, I
>>> have forced debugging, so there is a fair amount of output on the console.
>>> Most of the examples appear to render correctly.  The driver does not
>>> support alpha blending or native gradient fills. I’m not sure if it is
>>> worthwhile to add these features in this driver, particular with a Direct2D
>>> version on the horizon.
>>> 
>>> Also this version of the driver is non-unicode to make a lowest common
>>> denominator driver.  I’m going to add unicode support because that appears
>>> to be the standard used by all the maintained/newer drivers.
>>> 
>>> Any feedback is greatly appreciated.
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Phil R. <p.d...@gm...>]

On 11 June 2015 at 17:57, Jim Dishaw <ji...@di...> wrote:
>
>> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d...@gm...> wrote:
>>
>> Hi Jim
>> The documentation states that the provided text height will be in mm.
>> The user can set dpi with plspage so you should use the PLStream->xdpi
>> and PLStream->ydpi to size your text in pixels. In case the user
>> hasn't set this you should use a sensible default. Of course the
>> actual value will depend on the monitor, but rather than try to grab
>> this it seems that there are two standards and for consistency you
>> should use one of these. One is to use 72 pixels per inch so that 1
>> pixel = 1 pt. The other is 90 pixels per inch which seems to be the
>> default for most svg renderers. For wxWidgets I chose 90 pixels per
>> inch. I also noticed tect seems a little smaller than the example
>> online (from the cairo driver?) but it does as described in the
>> documentation so I am happy with that.
>


>
> The recommendation in the Windows API is to use GetDeviceCaps () with the >LOGPIXELSX/LOGPIXELSY values to get the dpi setting.  Right now I’m >ignoring the DPI setting provided by the user.  On native text rendering devices >the xdpi/ydpi settings are essentially being used to scale the size of fonts, >which (IMHO) abuses the meaning of “DPI”.
>
Yes as you say the windows API provides this mechanism - in fact there
is something about if you wish to have your app in the windows store
you must do this so your app can work on phones/tablets/pcs or
something. Not sure of the details.
For The windows interactive device it is perhaps not a big deal - for
wxWidgets the user can pass in a paint dc or a memory dc so in the
latter case it is down to the user to specify a DPI. Because all DCs
are treated equal it is up to the user in all instances. Re DPI
basically being a text scaling parameter - well you are correct - but
does any other function receive arguments in mm/inches or is text the
only one?

> Which size are you referring to?  When the window is resized, the driver gets >the new dimensions of the client area (via GetClientRect() for displays and >GetDeviceCaps() for printers).  It uses the new size to calculate the new >scaling between device virtual coordinates (PIXELS_X/PIXELS_Y in PLplot) >and the new output device coordinates,  The dpi remains consistent with what >Windows reports.
>
So for wxWidgets if I resize the window to double the size, the text
stays the same size. I.e. I maintain the same dpi and text height in
mm when the window is resized.

Phil

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Jim D. <ji...@di...>]

> On Jun 14, 2015, at 5:28 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> On 11 June 2015 at 17:57, Jim Dishaw <ji...@di... <mailto:ji...@di...>> wrote:
>> 
>>> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d...@gm...> wrote:
>>> 
>>> Hi Jim
>>> The documentation states that the provided text height will be in mm.
>>> The user can set dpi with plspage so you should use the PLStream->xdpi
>>> and PLStream->ydpi to size your text in pixels. In case the user
>>> hasn't set this you should use a sensible default. Of course the
>>> actual value will depend on the monitor, but rather than try to grab
>>> this it seems that there are two standards and for consistency you
>>> should use one of these. One is to use 72 pixels per inch so that 1
>>> pixel = 1 pt. The other is 90 pixels per inch which seems to be the
>>> default for most svg renderers. For wxWidgets I chose 90 pixels per
>>> inch. I also noticed tect seems a little smaller than the example
>>> online (from the cairo driver?) but it does as described in the
>>> documentation so I am happy with that.
>> 
> 
> 
>> 
>> The recommendation in the Windows API is to use GetDeviceCaps () with the >LOGPIXELSX/LOGPIXELSY values to get the dpi setting.  Right now I’m >ignoring the DPI setting provided by the user.  On native text rendering devices >the xdpi/ydpi settings are essentially being used to scale the size of fonts, >which (IMHO) abuses the meaning of “DPI”.
>> 
> Yes as you say the windows API provides this mechanism - in fact there
> is something about if you wish to have your app in the windows store
> you must do this so your app can work on phones/tablets/pcs or
> something. Not sure of the details.
> For The windows interactive device it is perhaps not a big deal - for
> wxWidgets the user can pass in a paint dc or a memory dc so in the
> latter case it is down to the user to specify a DPI. Because all DCs
> are treated equal it is up to the user in all instances. Re DPI
> basically being a text scaling parameter - well you are correct - but
> does any other function receive arguments in mm/inches or is text the
> only one?
> 

At least when it comes to DPI, text is the only that uses that field.  I think all the drawing commands are in the plot coordinate system, thus physical dimensions are subsumed into the coordinate system.  There is plsvpa() that allows the user to specify the viewport in terms of physical measurements.

My rationale for keeping the dpi tied to the device is to ensure that physical measurements are invariant (the principle of least surprise).  If the API says “mm” or “inches” the driver should render something that measures correctly.

>> Which size are you referring to?  When the window is resized, the driver gets >the new dimensions of the client area (via GetClientRect() for displays and >GetDeviceCaps() for printers).  It uses the new size to calculate the new >scaling between device virtual coordinates (PIXELS_X/PIXELS_Y in PLplot) >and the new output device coordinates, The dpi remains consistent with what >Windows reports.
>> 
> So for wxWidgets if I resize the window to double the size, the text
> stays the same size. I.e. I maintain the same dpi and text height in
> mm when the window is resized.
> 

Same with wingdi.  When resized the text stays the same.  

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Phil R. <p.d...@gm...>]

Yeah, that seems like a good argument to me

On 15 June 2015 at 03:30, Jim Dishaw <ji...@di...> wrote:
>
> On Jun 14, 2015, at 5:28 AM, Phil Rosenberg <p.d...@gm...> wrote:
>
> On 11 June 2015 at 17:57, Jim Dishaw <ji...@di...> wrote:
>
>
> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d...@gm...> wrote:
>
> Hi Jim
> The documentation states that the provided text height will be in mm.
> The user can set dpi with plspage so you should use the PLStream->xdpi
> and PLStream->ydpi to size your text in pixels. In case the user
> hasn't set this you should use a sensible default. Of course the
> actual value will depend on the monitor, but rather than try to grab
> this it seems that there are two standards and for consistency you
> should use one of these. One is to use 72 pixels per inch so that 1
> pixel = 1 pt. The other is 90 pixels per inch which seems to be the
> default for most svg renderers. For wxWidgets I chose 90 pixels per
> inch. I also noticed tect seems a little smaller than the example
> online (from the cairo driver?) but it does as described in the
> documentation so I am happy with that.
>
>
>
>
>
> The recommendation in the Windows API is to use GetDeviceCaps () with the
>>LOGPIXELSX/LOGPIXELSY values to get the dpi setting.  Right now I’m
>>ignoring the DPI setting provided by the user.  On native text rendering
> devices >the xdpi/ydpi settings are essentially being used to scale the size
> of fonts, >which (IMHO) abuses the meaning of “DPI”.
>
> Yes as you say the windows API provides this mechanism - in fact there
> is something about if you wish to have your app in the windows store
> you must do this so your app can work on phones/tablets/pcs or
> something. Not sure of the details.
> For The windows interactive device it is perhaps not a big deal - for
> wxWidgets the user can pass in a paint dc or a memory dc so in the
> latter case it is down to the user to specify a DPI. Because all DCs
> are treated equal it is up to the user in all instances. Re DPI
> basically being a text scaling parameter - well you are correct - but
> does any other function receive arguments in mm/inches or is text the
> only one?
>
>
> At least when it comes to DPI, text is the only that uses that field.  I
> think all the drawing commands are in the plot coordinate system, thus
> physical dimensions are subsumed into the coordinate system.  There is
> plsvpa() that allows the user to specify the viewport in terms of physical
> measurements.
>
> My rationale for keeping the dpi tied to the device is to ensure that
> physical measurements are invariant (the principle of least surprise).  If
> the API says “mm” or “inches” the driver should render something that
> measures correctly.
>
> Which size are you referring to?  When the window is resized, the driver
> gets >the new dimensions of the client area (via GetClientRect() for
> displays and >GetDeviceCaps() for printers).  It uses the new size to
> calculate the new >scaling between device virtual coordinates
> (PIXELS_X/PIXELS_Y in PLplot) >and the new output device coordinates, The
> dpi remains consistent with what >Windows reports.
>
> So for wxWidgets if I resize the window to double the size, the text
> stays the same size. I.e. I maintain the same dpi and text height in
> mm when the window is resized.
>
>
> Same with wingdi.  When resized the text stays the same.
>