#2448: Fontconfig error with cairo on Windows
--------------------------+-------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.2
Component: Display | Version: 7.0.0
Resolution: | Keywords: font, text, legend, scale bar
CPU: Unspecified | Platform: MSWindows 8
--------------------------+-------------------------------------------
Comment (by hellik):
Replying to [comment:43 wenzeslaus]:
> Replying to [comment:42 annakrat]:
> > Replying to [comment:41 hellik]:
> > > I've done some research, file permissions changed a lot between
Windows versions (7,8,10).
> >
> > Unfortunately, no change. I wonder if the problem is something
different then permissions. The problem is I don't get any error during
installation. Maybe we could print more messages during the font
configuration? Thanks for all the work on this.
>
> What about that hardcoding of some fonts for MS Windows into a MS
Windows specific file? This is a great workaround and I have no idea how
it should be done but it seems that it is appropriate on a platform where
API is changing often and is under-documented.
-s Write font configuration file to standard output instead of
$GISBASE/etc
a feasable way may be:
- another flag e.g. to write fontcap file to %APPDATA%GRASS7 where already
the addons are stored
- all the modules which are working with fonts seems to search for the
fontcap file in $GISBASE/etc; adding a second search path (e.g.
%APPDATA%GRASS7) to these modules if the file is not available in
$GISBASE/etc
-s Write font configuration file to standard output instead of
$GISBASE/etc
a feasable way may be:
- another flag e.g. to write fontcap file to %APPDATA%GRASS7 where already
the addons are stored
- all the modules which are working with fonts seems to search for the
fontcap file in $GISBASE/etc; adding a second search path (e.g.
%APPDATA%GRASS7) to these modules if the file is not available in
$GISBASE/etc
Similar to this, I was just going to suggest why don't you set the GRASS_FONT_CAP environment variable to a path that *is* writable. Then g.mkfontcap, and all the modules that use the fontcap, will simply use that instead of the fontcap in $GISBASE/etc. This mechanism is explicitly designed for the situation where a user doesn't have write access to $GIBASE/etc and needs to override the system fontcap file.
However, I don't think this is a good solution if the installation is required to be available to other users on the same Windows machine as the writable path will likely only be available to that user, if I understand correctly.
- another flag e.g. to write fontcap file to %APPDATA%GRASS7 where
already
the addons are stored
- all the modules which are working with fonts seems to search for the
fontcap file in $GISBASE/etc; adding a second search path (e.g.
%APPDATA%GRASS7) to these modules if the file is not available in
$GISBASE/etc
Similar to this, I was just going to suggest why don't you set the
GRASS_FONT_CAP environment variable to a path that *is* writable. Then
g.mkfontcap, and all the modules that use the fontcap, will simply use
that instead of the fontcap in $GISBASE/etc. This mechanism is explicitly
designed for the situation where a user doesn't have write access to
$GIBASE/etc and needs to override the system fontcap file.
However, I don't think this is a good solution if the installation is
required to be available to other users on the same Windows machine as the
writable path will likely only be available to that user, if I understand
correctly.
Paul
thanks!
I wasn't aware of GRASS_FONT_CAP environment variable. [1]
GRASS_FONT_CAP
[g.mkfontcap, d.font, display drivers]
specifies an alternative location (to $GISBASE/etc/fontcap) for the font
configuration file.
using this variable may ease a lot this issue.
in Windows there is C:\Users\All Users availabe, where application stores
files etc which should be available for all users.