Hi Jim: Now that 5.12.0 has been released, I am writing a series of posts to our active developers with this subject line, and it is now your turn. :-)
By all means please tell us of your plans for the current release cycle, but in any case I strongly encourage you to start working again on two development topics of yours that have intrigued us all in the past. Those are (1) your new interactive windows devices and (2) restoring the plmeta device and plrender. (1) Your new interactive windows devices My understanding is your new windows device driver has one interactive device implemented so far that is GDI (or GDI+) based (see <https://en.wikipedia.org/wiki/Graphics_Device_Interface> but with no Uniscribe (see <https://en.wikipedia.org/wiki/Uniscribe>) support for Unicode implemented yet. Also, you have at least discussed plans to add another device to that device driver that would use Direct2D <https://en.wikipedia.org/wiki/Direct2D> rather than GDI. and which would use the DirectWrite <https://en.wikipedia.org/wiki/DirectWrite> approach to search system fonts and render unicode text. And our build system goal would be to interrogate the system to see what was available out of all the GDI, Uniscribe, Direct2D, and DirectWrite possibilities and then present the available combinations out of the 4 possibilities (e.g., GDI with and without Uniscribe and Direct2D with or without DirectWrite) by default. But initially every combination would be OFF by default, i.e., a user would be forced to enable it using the appropriate cmake option (see discussion below). Furthermore, it appears this device driver in its present form is at least buildable (since you have circulated some patches concerning that device). So I strongly encourage you to go ahead and push your new windows device driver to SF master in exactly its present development state. After all, we have a really nice PLplot architecture where device driver development can proceed without affecting the rest of PLplot so you might as well take advantage of that architecture so long as most git users are insulated from build errors due to your new device (see the second comment below about how to arrange that insulation). And such a public development approach might attract some extra help for you (e.g., I would be happy to help with all build system issues.) Once you have pushed the current state of your new device driver code, I recommend the following further steps. * Rename the existing code for the device driver some generic name like windows.c or windows.cpp (depending on which of C or C++ you are using to develop it). Also rename the actual device implemented by that device driver as "winGDI". * Use the flag in cmake/modules/drivers-init.cmake to disable the winGDI device by default. That simply means that users who want to try it as an experiment would have to enable it explicitly with -DPLD_winGDI=ON. That's a bit of extra insurance allowing you to continue to develop that device without concerns about how it will affect the rest of us using the git version of PLplot. For example, if you introduced a build error on some platforms for your new device driver on initial push or after some further development it would not be an urgent matter to fix it because it would not affect that many PLplot git users. And that "pass" extends to releases as well so long as you keep the devices implemented by the device driver disabled by default. * Tear out any use of plfreetype if you are using it now for Unicode support. (The wingcc device currently uses that approach to attempt to get access to Windows system fonts, and render them, but that whole (pl)freetype approach is deprecated for very good reasons (see <http://plplot.sourceforge.net/docbook-manual/plplot-html-5.12.0/FreeType-notes.html>) so you should not propagate it to any further devices. * Keep developing -dev winGDI until you are completely satisfied with its results for the Hershey fonts (the only fonts you would be able to use at this stage). At that point you can enable -dev winGDI by default. * Give -dev winGDI optional (disabled by default) access to Unicode-enabled Windows system fonts using the Uniscribe <https://en.wikipedia.org/wiki/Uniscribe> approach. Once that component of your winGDI device works enable it by default if Uniscribe is available on the platform, but otherwise disable it. * Based on your (then) existing experience with development of -dev winGDI implement an additional device for your "windows" device driver called -dev winDirect2D which is based on Direct2D <https://en.wikipedia.org/wiki/Direct2D> rather than GDI. and which optionally (once Hershey fonts work) uses the DirectWrite <https://en.wikipedia.org/wiki/DirectWrite> approach rather than Uniscribe to give access to Unicode-enabled Windows system fonts. I highly recommend that you use the same device driver (called windows?) to implement both devices similarly to the way that the cairo device driver implements so many different devices. And I can certainly help with all the CMake aspects of discovering whether the current Windows platform supports GDI/Uniscribe and/or Direct2D/DirectWrite and enabling/disabling these two devices and their non-Hershey handling of fonts accordingly. But we can work out all those details later after an initial development with these (experimental) devices disabled by default. N.B. The first 3 of these steps should be at most a few hours work, but the remaining steps will likely take considerably longer, and I emphasize all of these development steps should be done publicly using the SF facilities rather than privately since that will encourage others to try your new devices (and perhaps help you with development), AND there is no way you can seriously affect git users of PLplot so long as the devices and independently the unicode treatment for each device is disabled by default until it is stablized code rather than experimental. N.B. Once you are completely happy with -dev winGDI with Uniscribe, and assuming that event occurs within this release cycle, I would plan to immediately deprecate wingcc for the forthcoming non-bugfix release 5.13.0 with the further plan for 5.14.0 to remove the deprecated wingcc, gd, and old wxwidgets device drivers and the whole deprecated plfreetype approach those deprecated devices depend on. In other words the event of stable -dev winGDI with Uniscribe support will trigger a wonderful opportunity for me to remove a lot of cruft from PLplot! :-) In sum I hope to see the first 3 steps above from you within a few days (assuming you have a few hours to work on PLplot right now), and I hope to see the 4th and fifth steps abpve completed before the release of 5.13.0 (mid 2017?) to start the clock on the cruft removal I hope to do for the 5.14.0 release (early 2018?). 2. Restoring the plmeta device and plrender The big complication here (if I am recalling correctly from your previous discussions of this topic) is you likely need substantial plbuf changes to move forward with this in a way that satisfies the "round trip test", i.e., (pl)rendering plmeta results to the plmeta form again should yield an identical plmeta result. And such plbuf changes impact all interactive devices and likely most git PLplot users. However, I think the general approach of making the plbuf change and adjusting all devices for that change is the best you can do. The only caveat is there must be plenty of testing time before the release to test your changes for each of the devices. That was the approach you used last time for your last plbuf change and it generally worked. Of course, for some reason wxwidgets slipped through the cracks and did not get adjusted but presumably Phil will be dealing with that issue shortly. And we had to temporarily remove the cairo adjustment because it clobbered one of the cairo special examples. But the cairo device driver worked fine with that change and your best guess at the time was you were simply uncovering an existing bug in the cairo special example. So I plan to put back the cairo adjustment shortly and simply disable the special cairo example instead (until somone figures out what the real issue is for that example). But it is obviously a good idea to wait until Phil adjusts the wxwidgets device driver and I restore your adjustment for the cairo device driver before you change plbuf some more. 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
