On 2015-06-07 00:25-0400 Jim Dishaw wrote: > While working on my old Windows GDI based driver (see attached patches), I > stumbled across the problem that prompted Phil to add plP_eop() in > plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on > problems with -np when running automated testing. > > In plbuf.c, the EOP is never inserted into the plot buffer while the plot is > being generated. The obvious issue to having an EOP in the plot buffer is > that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI > driver that could cause problems (i.e. the WaitForPage() in the xwin driver > would be called multiple times). While working on wxwidgets, Phil added a > call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers > the EOP handler and results in the need for a keypress. I thought > eliminating the call to plP_eop() would be the simple fix (it does fix the > bug) but having the EOP is handy when redrawing the plot. > > I looked at the possibility of keeping the EOP in the plot buffer, but there > is all sorts of messy code on trying to “do the right thing” that I think > might cause more problems. In the ideal world, I like the symmetry of having > both a BOP and EOP in the plot buffer. However, to support that correctly in > the GUI drivers might be tricky. Instead, I think the best solution is to > eliminate the plP_eop() call that was added into plRemakePlot. That will fix > the issue that Andrew raised. The downside is that Phil might need to make > some changes to wxwidgets. It took some effort to get the new windows GDI > driver working without the plP_eop() call, but it does work. I can make a > fix for plbuf.c that removes the plP_eop(). >
> @Aaron & Alan (and others who might be interested) I have attached two sets of patches. One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done). I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar). @Arjen and Phil: Will you two please take a close look at Jim's patch series concerning MSVC build problems? If you try them out and they definitely improve the build on MSVC, then I think we should push them now as a bug fix so they will be part of the forthcoming release. > Should I add Freetype back in? > Once I finish with wingdi, I will implement the Direct2D version. Aaron responded to this by asking "Is it not possible to eliminate it [the plfreetype approach] and still get nice looking anti-aliased text with GDI/GDI+/Uniscribe?" @Aaron and Jim: Here is my response to both of you on these interesting questions. @Jim: The quick answer is no, don't bother with the currently deprecated plfreetype approach and instead move forward with your plans to implement a Direct2D approach for your successor to the wingcc device driver. @Aaron: I encourage you to add to Jim's planned Direct2D approach by implementing a Uniscribe approach as well for the case where the user has an older Windows system with no Direct2D available. @Jim and Aaron: I hope that division of the labour works for you. You should also note that in earlier parts of this discussion Phil mentioned the possibility of modifying the currently deprecated plfreetype approach to take care of its known issues with finding glyphs in system fonts and rendering those glyphs properly for complex text layout languages. Specifically, he proposed we should deal with those issues by using the capabilities of the GTK+ components, fontconfig, pango, and harfbuzz which are available on both Unix and Windows platforms. I think that would be a very useful project if someone wants to take that on. However, such an approach would have some obvious dependencies on GTK+ components that are going to irritate some Windows users. So if/when the plfreetype approach is modified as above would be the time to add it back into the successor to wingcc as an alternative to the Uniscribe and Direct2D alternatives that should also be available. > @Alan > > I was not able to uncrustify. I have not had time to set it up on my Windows > machine. Sorry. @Jim: No problem. 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
