On Aug 10, 2008, at 4:32 PM, Glynn Clements wrote:
BUT, GRASS also uses pkg-config to get cairo config info (the only
dep
in GRASS that does this). I find this unreasonable (at least for
OSX), so can we get alternative (and standard for GRASS) --with-
cairo-
includes and --with-cairo-libs flags, please?
This would also be useful on Windows.
The only potential problem is that cairo might need some -l flags.
There's currently no way to provide those via configure, and with
high-level libraries, it starts getting impractical to enumerate
candidate libraries until the linking test succeeds.
And there will be OSX-specific system frameworks needed for cairo.
OTOH, this is really only likely to be an issue if cairo is a static
library, or a dynamic library which lacks dependency information, both
of which are relatively unlikely.
Dynamic lib may be the way to go - at least my attempt to build a
static cairo today failed. It looks like it only has one library
target, and it's tailored to a shared lib since it passes -lpixman as
a flag. When I build pixman as static also, libtool tries to ar that
into cairo, but can't because it's not an object file.
So, I'm disabling the freetype backend and looking at the Cairo
quartz
font backend. I don't know how GRASS passes font details to Cairo,
so
I don't know if this will work. In general, how do you specify the
cairo backend to use (surface and font), from GRASS? From the GRASS
docs, it looks like file extension sets surface backend.
There's no inherent reason why it can't support multiple font
back-ends. Each provides a different mechanism to obtain a
cairo_font_face_t* which can be passed to cairo_set_font_face().
The main issue is that each back-end needs corresponding
platform-specific code to get the platform's font handle.
I'll see what you come up with for freetype fonts. Maybe I can make
sense of the OSX font API(s) and add Cairo/Quartz support. But it
will probably mean a complete overhaul of the fontcap setup:
On Aug 10, 2008, at 4:47 PM, Paul Kelly wrote:
ISTR a report that g.mkfontcap found some fonts on OS X that
fontconfig didn't detect (that was a pleasant surprise at the time).
Is that still the case and, if so, is it relevant? Probably avoiding
too much "DIY" is best - if g.mkfontcap just duplicates what
fontconfig does it can be done away with and Cairo can find the
fonts itself - but OTOH it does seem to have worked very well as a
cross-platform solution to finding available fonts.
mkfontcap detects font files in known system, and user-specified,
locations. This is much different than detecting "enabled" fonts in
the system, which is what the Cairo Quartz font support will want. A
font in OSX can be "installed" in one of many standard locations, but
is "enabled" by API calls. Normally, fonts are automatically enabled
when installed, but they can be disabled. Fonts can also be enabled
from random locations, which is what font managers do (Suitcase,
Linotype Fontexplorer, ...) and apps with internal fonts.
We may need to revise the fontcap setup for more platform-specific
behavior. On OSX it would have to detect "enabled" fonts at runtime,
and not installed fonts when g.mkfontcap is run. This may be easy to
do with python, since it (directly or wx?) probably already has some
such feature or extension.
Or, since it will still be possible to use freetype and native font
APIs together, leave the fontcap for use by freetype, and have a new
font list function for use by OS native font routines.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
First Pogril: Why is life like sticking your head in a bucket filled
with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a
bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?
-HitchHiker's Guide to the Galaxy
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
