-----BEGIN PGP SIGNED MESSAGE-----
Hi Alan, Rafael,
When you try x06 with the ps driver, the results are quite different
(see http://aolab.phys.dal.ca/~tomduck/temp/x06.pdf). You will see
that many of the symbols are missing. Can you confirm this problem?
For reference, I am running a Debian (unstable) system.
I have not attempted to enable unicode in the gcw driver yet. I
have, however, assessed the situation, and it should be straight-forward
to implement. I won't be able to use the plfreetype support, because it
is for bitmapped drivers, if I understand correctly. My approach will be
similar to that for the ps driver. I am using the gnomecanvas font
support from gnome-print, and it seems to work fairly well (I believe that
I can use all ttf).
BTW, I am already building the documentation, and have read what you
wrote on unicode, Alan. Good stuff. I am still thinking about a plan for
releases, and intend to present some ideas to you all soon.
On Wed, 23 Feb 2005, Alan W. Irwin wrote:
> On 2005-02-23 10:28-0400 Thomas J. Duck wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > Hi,
> > I now have Greek characters in the gcw driver; i.e., I have all of
> > the Type 1 font stuff working now. It shouldn't be too hard to implement
> > the unicode translation.
> > My question is this: Currently in our unicode implementation, we have
> > lost most of the usual symbols used in line plots (circles, squares,
> > triangles, etc). I am wondering what the plan is to cover this? Are we
> > going to use OpenSymbol?
> Tom, I just had a quick look through your updated gcw.c, and clearly you are
> not yet consistent with the new font infrastructure. (No processing of FCI,
> fixed set of 4 fonts, etc.). I haven't followed your code in detail, but
> you probably lost access to the symbol font because of that inconsistency.
> It also appears you are handling fonts completely independently of
> plfreetype.c. The one device driver that does that now in a manner consistent
> with the new font infrastructure is ps.c so you may want to have a look
> at that to get some insight about what to do.
> I assume you are letting some GNOME library handle fonts for you through the
> face = gnome_font_face_find_closest(curfontname);
> call. Are those names restricted to just type 1 fonts (what you appear to
> use now), just truetype fonts, or are both allowed? If truetype fonts are
> allowed, then my experience is they have a much richer symbol set then type
> 1, and, of course, they are immediately accessible by unicode (UCS-4) while
> you have to do something special with type1 fonts (which I was forced to do
> in ps.c) to make the limited 255 possibilities accessible by unicode index.
> But regardless, you will want to use the FCI information in your device
> driver to handle the font choice so that 30 different font names are
> available to you. For the ps.c device driver, the translation between FCI
> and type 1 name is fixed in plfci-type1.h. For your case, however, if
> truetype fonts are accessible to gnome_font_face_find_closest, then I would
> pick the 30 best truetype names corresponding to the 30 possible FCI's.
> Note, plfreetype.c currently uses a rather crude configuration approach
> where plfci-truetype.h maps FCI's to symbolic font names which are #define'd
> in config.h by ./configure as specific font _file_ names. At some point we
> will want to go to a more sophisticated approach where we configure font
> names rather than file names in config.h. This would allow us to use the
> fontconfig library (probably what is used internally by
> gnome_font_face_find_closest) to translate those font names to file names
> for plfreetype.c to use.
> Finally, a lot of your potential questions about the new font infrastructure
> have already been answered by the new docbook documentation I committed on
> the subject. To get access to that, you should simply build the
> documentation for yourself on your own Linux box (and as a favour to others
> upload it to the website). Notes on how to do that are given in www/README.
> In your role as release manager you will also have to build the
> documentation for the cvs snapshot tarball releases and the final release so
> it would be an excellent idea to get familiar with the documentation build
> process now.
> Alan W. Irwin
> email: irwin@...
> phone: 250-727-2902
> 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); PLplot scientific plotting software
> package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
> Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
> Linux-powered Science
Thomas J. Duck <tomduck@...>
Department of Physics and Atmospheric Science, Dalhousie University,
Halifax, Nova Scotia, Canada, B3H 3J5.
Tel: (902)494-1456 | Fax: (902)494-5191 | Lab: (902)494-3813
Public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x17D965DB
Tier I CRC Chair in Atmospheric Science: http://www.atm.dal.ca/jobs/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----