Re: [Guidolib-devel] Guido Graphic Stream

[Dominique F. <fo...@gr...>]

Hi Scott,

Le 1 juin 04, =E0 04:56, J. Scott Amort a =E9crit :

> 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

That's a good news. We're to meet Holger at the end of the week.
He should present us the GGS implementation.

> synced up the ggs branch with the dev branch as of yesterday (05/30)=20=

> and
> committed all of my work to this point.  There are three main=20
> additions:
>
> (1) The implementation of GGS within the engine as a series of=20
> 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=20=

> 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=20=

> to

why not renaming it to ggs2img ?

> 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

Please wait a little before merging to the dev branch. We're currently
working on the library API and major changes are in progress. We would=20=

like
to publish rapidly a GUIDOLib SDK based on this new API and therefore,=20=

these
changes are to be merged soon to the main branch. Since we've also=20
strong
deadlines with our GUIDOLib based project (IMUTUS), we would preferably=20=

integrate
the GGS stuff after having release our IMUTUS prototypes.

You could have a look at the new API and make some comments. The best=20
way is
probably to make the documentation using doxygen. Note also that the=20
old APIs
have been preserved but to use them, you need to define a specific=20
label.


> 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=20
> 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=20=

> 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

yes you're right!

> GuidoOnDrawDesc) which may or may not be the same, will be resolved,=20=

> 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=20=

> 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=20=

> a
> second VGDevice is used for the GuidoOnDrawDesc, but that will get=20
> 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=20
> either/or
> choice - you won't be able to have both GGS and VGDevice.  What does
> everyone think?
>

We've also consider these issues while designing the new API and the=20
conclusion
was that a GFontManager was the best solution. The problem is that we=20
can't
work on it right now. We can plan to do it in July.

Again, since we're to meet Holger and Juergen soon, we'll discuss all=20
these points.

--dom