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 <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
