[Guidolib-devel] Guido Graphic Stream

[J. S. A. <js...@sy...>]

Hi All,

I have been doing quite a bit of work with the GGS implementation over
the past few months, and I think it is almost ready to go.  I have
synced up the ggs branch with the dev branch as of yesterday (05/30) and
committed all of my work to this point.  There are three main additions:

(1) The implementation of GGS within the engine as a series of OnDrawGGS
routines that parallel the OnDraw functions.  These functions are
marshaled by a GuidoGGSFactory object which can then stream the output
to a standard C++ iostream.  Still to be implemented is GGS input to the
factory object;

(2) A GGS parser implemented as a mixed C/C++ flex/bison library; and

(3) Two applications: guido2ggs, which converts a GMN file to GGS; and
ggs2ps, which contrary to it's name is actually a general purpose GGS to
image file converter.  It takes a GGS file and creates programmatic
PostScript or EPS output, which can then also be converted to any of a
variety of image formats (currently jpeg, bmp, gif, tiff, png, pict)
with the help of the ImageMagick library.  Other formats are also
available, but I've limited it to the above for now.

Overall, the main problems still to be completed are scaled output (I'm
waiting on Holger to decide on how he wants the GGS to address that),
text placement and implementation of complex music elements such as
tuplets.  There are also some spacing issues I've come across -
collisions of articulations come to mind, plus some other musical
problems (e.g. barlines that don't extend through systems), but I think
it's looking pretty good.

At any rate, after spending a few days syncing the latest dev branch
into the ggs branch, I wanted to address the possibility of merging the
two branches.  There really is only one issue that stands in the way of
this - the GuidoInitDesc and its dependence on a VGDevice.  In the GGS
branch, I have changed this and created a device-independent 
GFontManager class that offers all of the font management routines
needed by the GuidoInitDesc and ultimately, the
gGlobalSettings.gDevice.  This GFontManager can also be used as a base
class for a device-dependent derivation that can be attached to the
VGDevice object if the user wants to use that mechanism, or left alone
if GGS is the only required output.  However, this will necessitate a
rewrite of all of the VGDevices (essentially, a GFontManagerXX will need
to be subclassed for each VGDevice implementation and the font routines
will be transferred to that object).  I sent an email to this list a
while back detailing this, but didn't get any feedback on that
strategy.  I'll assume that this means it wasn't enthusiastically
received :-)  So, I'll suggest three options:

(1) Go with my initial suggestion, and rewrite a bunch of the VGDevice
code.  The VGDevice.h and VGDevice.cpp are actually already done in the
GGS branch (they now require an embedded GFontManager), however all of
the device specific classes will have to be redone to work with this new
implementation.  I did a GFontManagerPS and GDevicePostscript for
testing, but all of the other platforms will have to be done as well. 
The strength of this suggestion is that the somewhat strange situation
of having two VGDevices (one in the GuidoInitDesc and one in the
GuidoOnDrawDesc) which may or may not be the same, will be resolved, and
the font data will be device-independent (thus the engine can be
compiled with or without a VGDevice, as seen fit by the user);

(2) Use a series of preprocessor directives to allow for either a GGS or
a VGDevice implementation choice at compile time; or

(3) Redo the GFontManager to be derived from VGDevice, but do not
properly implement anything except the font routines.  It can then be
used as the VGDevice required by GuidoInitDesc.  This won't require any
code rewrites of the dev branch, but I'll have to change a number of
things on the ggs side, and the OnDraw routines will be broken (unless a
second VGDevice is used for the GuidoOnDrawDesc, but that will get messy
pretty quickly, I think).

Option (2) seems to be the middle ground, while the other two will
require a pretty major design change on one of our parts to get it
going.  (1) or (3) will allow for both the VGDevice and GGS to be
implemented within the same engine, but I think (3) will be a
problematic implementation of this option.  Finally, (2) is an either/or
choice - you won't be able to have both GGS and VGDevice.  What does
everyone think?

Best,
Scott