> On Jan 30, 2017, at 3:40 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > 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.)
I will rebaseline my driver with the newest release and push to the git repository. I now have a Windows Vista and a Windows 10 build environments setup for development and testing. I also have a high DPI machine that will help test out the implementation on the environment. > > 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”. I was planning on using wingdi.c as the filename. > > * 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. > Got it > * 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. > I have not been using Freetype—I have been keeping it as pure windows API as I can. > * 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. > I have to think about this recommendation. It sounds like a good idea. > 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?). > Sound reasonable > 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. > I think it is best to wait until Phil finishes his work on wxwidgets ------------------------------------------------------------------------------ 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
