Re: [Opengrads-devel] Fonts in GrADS

[Arlindo da S. <arl...@na...>]

On Feb 2, 2008 6:04 PM, Brian Doty <do...@co...> wrote:

> Hi Matt, thanks for all the feedback on all that stuff, it is very
> helpful!  I am going to take a very close look at Cairo and probably
> hack a partially functional interface between it and gxX just to see
> how it behaves.  It looks to support a lot of the stuff we want to do
> so it'll be great if it performs as advertised.  It appears to be a
> long lived and stable project; is that your sense as well?  It'll
> probably take me a week or two to play with it and discover any
> pitfalls.  I'll keep you informed... Brian
>

Cairo uses FreeType underneath to render its fonts, so you would be using
FreeType if you go thru the cairo API, but I believe it has support for
native fonts as well, say on Windows and/or Macs. You may want to take a
look at gxyat.c

http://opengrads.cvs.sourceforge.net/opengrads/contrib/extensions/gxyat/gxyat.c?revision=1.2&view=markup

to see how I mapped the gx metadata into cairo calls; of course, no fonts at
this point. I have gxyat implemented as an external command line utility,
and the same code compiles into gxyat.gex.so and functions as a built-in
extension --- I ifdef the code using the same trick Matt used for in-lining
gxeps.

I have been tinkering with the idea of addiing an option to gxyat to render
the plot to the screen instead of to a file. This would provide a quick
prototype of how a cairo graphical backend would look like, and allow for
some experimentation before tackling the gxX.c problem.

Another thing to keep in mind is that the cairo library proper only handles
the "rendering" of vector graphics (it used to be called Xr when it lived
inside X), it does not attempt to solve the event driven mouse click/key
pressed kind of stuff that would be needed for a full gxX.c replacement.
Cairo's approach is to rely on a "backend" library for that. A common
backend is libsdl:

            http://www.libsdl.org/

>From their home page:

Simple DirectMedia Layer is a cross-platform multimedia library designed to
provide low level access to audio, keyboard, mouse, joystick, 3D hardware
via OpenGL, and 2D video framebuffer. It is used by MPEG playback software,
emulators, and many popular games, including the award winning Linux port of
"Civilization: Call To Power."

SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD,
NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support
for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2,
but these are not officially supported.

SDL is written in C, but works with C++ natively, and has bindings to
several other languages, including Ada, C#, D, Eiffel, Erlang, Euphoria,
Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike,
Pliant, Python, Ruby, Smalltalk, and Tcl.

SDL is distributed under GNU LGPL version 2. This license allows you to use
SDL freely in commercial programs as long as you link with the dynamic
library.
---

  I haven't added cairo to the supplibs but it is on my to do list.

            Arlindo


>
> On Feb 2, 2008, at 1:07 AM, Matthias Münnich wrote:
>
> > Hi Brian
> >
> > Based on my experience, and your intention to give GrADS a major
> > overhaul, I would try out  Cairo.   The Freetype solution, at least
> > the one I started implementing,  would likely still appear like
> > patchwork and may  lead to more  maintanance trouble on the long
> > run.   I think, the basis of  a new implementation should be to
> > move away from the low-level "pin-up, pin-down" and introduce
> > higher order graphics elements  within the GrADS source to then
> > offload as much a possible to some graphics libraries like Cairo.
> >
> > That said, one advantage of going with FreeType would be that many
> > of the items you mention are actually already implemented in my
> > private version of GrADS 1.9.
> >
> >  - The metafile format was amended for strings, line-style, polygons
> >  - Freetype support was added to  gxhpng.c
> >  - String support was added to gxeps.c (these changes are actually
> > already in GrADS 1.9).
> >  - On-screen fonts are drawn with Freetype.
> >
> > You may like to  revisit the patches I sent to COLA a couple of
> > years ago. For your convenience I put a tar-file of my private
> > GrADS version at http://www.atmos.ucla.edu/~munnich/grads/<http://www.atmos.ucla.edu/%7Emunnich/grads/>
> > grads-1.9XP1mm3.tar.bz2    Go to the "oldformat" subdirectory for
> > diffs and have a look at  matts_cppflags for a summary of my
> > changes.  These changes are far from perfect. Here is a list of
> > deficiencies  off the top of my head:
> >
> >  1)  gxeps's BoundingBox comment is broken.  The main trouble here
> > is to get the extent of strings on the plot.
> > The implementation I came up with seems broken and, lacking time, I
> > began using ghostscript to get the BoundingBox.
> >
> > 2) Fonts are sometimes not displayed if one starts a session
> > remotely.  As far as I remember, FreeType  off-loads rendering to
> > the local X11 server, where FreeType may not be found.   It is
> > either this, or the event loop implementation in GrADS does not
> > play well with FreeType.
> >
> > 3) Clipping is a mess.   It is sufficiently differently done in X11
> > and PostScript to cause trouble.  I struggled with this and likely
> > implemented it badly.  Our graphics assistant at UCLA routinely
> > edits gxeps PS files using Adobe Illustrator.  However the tons of
> > clipping paths introduced by my gxeps version made it cumbersome
> > for her as she had to remove all of them by hand to before being
> > able to edit a figure.  Of course, this may be a problem of the EPS
> > importer of AI. Anyway,   I ended up creating a gxeps with disabled
> > clipping.  This meant that  strings ran out of the graphic boundary
> > but this was much easier for her to fix than dealing with the
> > clipping paths.
> >
> > 4) Subscripts and Superscripts are not working.
> >
> > Additional thoughts:
> >
> >  - Implementing clipping the way you once mentioned  -- introducing
> > a fine raster mask -- does not play nicely with
> > PostScript's idea of being resolution independent and may be
> > cumbersome to implement in gxeps.
> >
> >  - You should start supporting transparency (alpha-channel). In
> > this context  you may like to have a look  into the SVG  graphics
> > format.  It's a W3 standard and as such, all modern browsers can
> > render basic SVG files.  SVG supports alpha channel.  I always
> > thought I should write a gxsvg which should not be hard.
> >
> >  - Keep an eye on rendering speed.  At least the early versions of
> > Cairo (or was it Xft? ) I tried out  had issues  in this regard.
> >
> >  - Arlindo (cc)  asked me last May about my thoughts on
> > antialiasing and fonts in GrADS.  He came up with some solution.
> > You may like to contact him as well.  His knowledge should be more
> > up to date.   It's been a long time since I worked on this. Somehow
> > I mostly ended up thinking about a new contour filling routine,
> > when my mind drifted toward GrADS development.
> >
> >
> > ... Matt
> >
> >
> > On Jan 31, 2008, at 9:09 PM, Brian Doty wrote:
> >
> >> Hello Matt, I am beginning to think about the graphics layer of
> >> GrADS for v2.  There are a number of things on the list.
> >>
> >> One thing which we have discussed before is to put some sort of
> >> "native" font support into the package.  For screen output, I am
> >> looking at the Freetype library, and also the Cairo graphics
> >> library.  The Cairo project (formerly Xr/Xc) is of particular
> >> interest as it provides vector graphics primitives with a multi-
> >> platform backend.  This would allow for GrADS to be built native
> >> for Linux, Windows, and Mac, with no X server needed for the
> >> latter two.  But this is not something I have fully researched as
> >> yet.
> >>
> >> Anyway, the basic idea is to have a way to draw strings using
> >> raster fonts rather than the Hershey vector fonts.  The GRADS
> >> higher level utilities say they want to plot a string at a
> >> specific color, size, and rotation.  Also there is a call into the
> >> font library currently which provides back the actual length of
> >> the string to be drawn, thus taking into account proportional
> >> spacing.  For screen display we can use either X native or Cairo.
> >> For printim we can use either Freetype or Cairo.  My unknown is
> >> how to also support this via postscript output.  My knowledge
> >> there these days is limited.  I am also not sure if any of these
> >> things support rotated fonts.  If not then we just fall back to
> >> Hershey fonts when rotation is used.   GrADS puts it's contour
> >> labels horizontally by default so for most plots the rotation is
> >> not used.
> >>
> >> I am also planning to allow the "real" page size to be set on the
> >> fly.  This currently is hardwired as 8.5x11 or 11x8.5.  I want to
> >> allow this to be set arbitrarily, so the user can control the
> >> aspect ratio.  This is needed when the primary output is an image.
> >>
> >> Lastly, I would like to provide some ability to produce image
> >> output and somehow be able to print that to the postscript file.
> >> The overall design of this would depend on the hardcopy output
> >> limitations.
> >>
> >> Overall the goal continues to be to have a unified approach to the
> >> graphics such that something that can be displayed on the screen
> >> can also be printed via vector graphics with high quality
> >> reproduction.  Of course there are many things that can be done if
> >> one stays purely in the image realm, but I really want to maintain
> >> the vector hardcopy capability.  This may fade in importance with
> >> time, but for this round of planning I think it is still important
> >> enough.
> >>
> >> Needless to say many of these things create new entries in the
> >> graphics "metafile".  Thus gxeps will need to be extended.  I am
> >> planning on dropping the gv utility and probably also the old gxps.
> >>
> >> Please give me your thoughts, views, advice, etc!  Thanks... Brian
> >
> > Matthias Munnich
> > mu...@at...
> >
> >
> >
> >
>



-- 
Arlindo da Silva
NASA/GSFC Code 610.1
Tel: (301) 614-6174
Fax: (301 614-6297