[Plplot-devel] Your development plans for this release cycle

[Alan W. I. <ir...@be...>]

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
__________________________