> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> 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 <gvj...@gmail.com> 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 <j...@dishaw.org> 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 >>> Plplot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/plplot-devel >>> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Plplot-devel mailing list >> Plplot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
