Hi,
d.font -l prints out 190 fonts on my system (happy me) but they aren't
sorted.
Could this be added to print_font_list() in display/d.font/main.c
?
Thanks
Markus
--
View this message in context: http://www.nabble.com/d.font--l%3A-please-sort-alphabetically-tf4138371.html#a11770995
Sent from the Grass - Dev mailing list archive at Nabble.com.
Hello Markus,
On Tue, 24 Jul 2007, Markus Neteler wrote:
d.font -l prints out 190 fonts on my system (happy me) but they aren't
sorted.
The list *is* sorted (see function compare_fonts() in general/g.mkfontcap/main.c), first by type (stroke font or freetype-compatible), and then by name. But it sorts case-insensitively on the long descriptive name (I thought this would be most logical for human-readable viewing), not on the short name. Unfortunately we haven't yet added the capability to d.font to also view the more descriptive name - Glynn mentioned that adding a d.font -L flag (capital L rather than lower-case l) might be a good idea for that. It isn't entirely simple though, but just needs some work. Do you think that would be enough? Or should we change the search to sort on the short name - case-insensitively perhaps? You could try that if you want and see if it gives you good results on your system - just change the two references to "longname" in that function to "name".
I'm not sure how much info the d.font -L flag should produce though - just the short name and long name, or the path to the file, index within the file etc.?
And funnily enough, just today I've been working on some tidying and improvements to the fontcap generation stuff. Main points being:
1) Add a text file to the lib/fonts/fonts directory to be installed into $GISBASE/etc/fonts, to identify a descriptive long name with each stroke font (actually copied from d.font man page)
2) Removed the capability from g.mkfontcap to generate an old-style freetypecap file, to simplify and reduce confusion
3) Adjusted "make install" to adjust the path to the stroke fonts in the fontcap file, when GRASS is installed to a different location on the local system
4) Adjusted the binary install script binaryInstall.src to run g.mkfontcap during the install process, to find all the fonts on the local system.
After some more local testing I should hopefully get these changes committed tomorrow. They don't affect the sorting of the d.font output though.
Paul
Paul Kelly wrote:
- Glynn mentioned that adding a d.font -L flag (capital L rather than
lower-case l) might be a good idea for that. It isn't entirely simple
though, but just needs some work. Do you think that would be enough? Or
should we change the search to sort on the short name - case-insensitively
perhaps? You could try that if you want and see if it gives you good
results on your system - just change the two references to "longname" in
that function to "name".I'm not sure how much info the d.font -L flag should produce though - just
the short name and long name, or the path to the file, index within the
file etc.?
I've added R_font_info(), which behaves like R_font_list() except that
each string is the entire fontcap entry rather than just the name.
I've also added a -L switch to d.font. Currently, this dumps the raw
string (with fields separated by the | character); some formatting
would probably be desirable.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Paul Kelly wrote:
- Glynn mentioned that adding a d.font -L flag (capital L rather than
lower-case l) might be a good idea for that. It isn't entirely simple
though, but just needs some work. Do you think that would be enough? Or
should we change the search to sort on the short name -
case-insensitively
perhaps? You could try that if you want and see if it gives you good
results on your system - just change the two references to "longname" in
that function to "name".I'm not sure how much info the d.font -L flag should produce though -
just
the short name and long name, or the path to the file, index within the
file etc.?I've added R_font_info(), which behaves like R_font_list() except that
each string is the entire fontcap entry rather than just the name.I've also added a -L switch to d.font. Currently, this dumps the raw
string (with fields separated by the | character); some formatting
would probably be desirable.--
Glynn Clements <glynn@gclements.plus.com>_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
Glynn,
I have tried but both -l and -L don't report anything (any more).
Doing a bit of debugging, I found that num_fonts is zero in
print_font_list() at:
for (i = 0; i < num_fonts; i++)
But
wc -l $GISBASE/etc/fontcap
268 /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/etc/fontcap
The debugger doesn't step into read_freetype_fonts(), not sure why (maybe
due to my lack of knowledge of ddd/gdb).
I didn't run "make distclean" if that matters.
Markus
--
View this message in context: http://www.nabble.com/d.font--l%3A-please-sort-alphabetically-tf4138371.html#a11799136
Sent from the Grass - Dev mailing list archive at Nabble.com.
Markus Neteler wrote:
I have tried but both -l and -L don't report anything (any more).
I didn't run "make distclean" if that matters.
It matters.
The architecture of the graphics subsystem is such that adding new
operations invariably requires substantial re-compilation. Unless
you're especially familiar[1] with the graphics subsystem, it's easier
to just start from scratch with "make distclean" than to figure out
what needs to be re-compiled.
[1] Actually, even if you are familiar, it's easy to get bitten. I
spent 10 minutes tracking down a problem caused by failing to run
"make -C lib headers" (which copies include/* to dist.<arch>/include)
after modifying include/graphics.h.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Markus Neteler wrote:
I have tried but both -l and -L don't report anything (any more).
I didn't run "make distclean" if that matters.
It matters.
The architecture of the graphics subsystem is such that adding new
operations invariably requires substantial re-compilation. Unless
you're especially familiar[1] with the graphics subsystem, it's easier
to just start from scratch with "make distclean" than to figure out
what needs to be re-compiled.[1] Actually, even if you are familiar, it's easy to get bitten. I
spent 10 minutes tracking down a problem caused by failing to run
"make -C lib headers" (which copies include/* to dist.<arch>/include)
after modifying include/graphics.h.
Also after full recompile, nothing yet. I am working on 64bit boxes
(RHEL4 and Mandriva2007.1).
Ah, found it through re-debugging!
static void read_freetype_fonts(int verbose)
{
char **list;
int count;
int i;
R__open_quiet();
if (R_open_driver() != 0)
return;
If the GRASS monitor isn't open, it silently exits at R_open_driver().
Maybe it should say that a monitor must be open (would be nice of course
to get it working also without monitor, but probably not possible?).
Markus
--
View this message in context: http://www.nabble.com/d.font--l%3A-please-sort-alphabetically-tf4138371.html#a11808978
Sent from the Grass - Dev mailing list archive at Nabble.com.
Markus Neteler wrote:
>> I have tried but both -l and -L don't report anything (any more).
>
>> I didn't run "make distclean" if that matters.
>
> It matters.
>
> The architecture of the graphics subsystem is such that adding new
> operations invariably requires substantial re-compilation. Unless
> you're especially familiar[1] with the graphics subsystem, it's easier
> to just start from scratch with "make distclean" than to figure out
> what needs to be re-compiled.
>
> [1] Actually, even if you are familiar, it's easy to get bitten. I
> spent 10 minutes tracking down a problem caused by failing to run
> "make -C lib headers" (which copies include/* to dist.<arch>/include)
> after modifying include/graphics.h.Also after full recompile, nothing yet. I am working on 64bit boxes
(RHEL4 and Mandriva2007.1).Ah, found it through re-debugging!
static void read_freetype_fonts(int verbose)
{
char **list;
int count;
int i;
R__open_quiet();
if (R_open_driver() != 0)
return;If the GRASS monitor isn't open, it silently exits at R_open_driver().
Maybe it should say that a monitor must be open (would be nice of course
to get it working also without monitor, but probably not possible?).
Not possible.
As part of the recent font changes (merging the handling of stroke and
freetype fonts), listing of fonts was moved from the client to the
driver. This means that you don't need fontcap-parsing code in both
the client and the driver; it also allows for the possibility of
driver-specific handling (e.g. the PS driver allowing the use of
PostScript fonts).
The use of R__open_quiet() is presumably a remnant of the time when
d.font parsed the freetypecap file itself. It should just be removed,
so that R_open_driver() generates warnings if no monitor is selected
or running.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, Jul 26, 2007 at 10:14:08PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
...
> Ah, found it through re-debugging!
>
> static void read_freetype_fonts(int verbose)
> {
> char **list;
> int count;
> int i;
>
> R__open_quiet();
> if (R_open_driver() != 0)
> return;
>
> If the GRASS monitor isn't open, it silently exits at R_open_driver().
> Maybe it should say that a monitor must be open (would be nice of course
> to get it working also without monitor, but probably not possible?).Not possible.
As part of the recent font changes (merging the handling of stroke and
freetype fonts), listing of fonts was moved from the client to the
driver. This means that you don't need fontcap-parsing code in both
the client and the driver; it also allows for the possibility of
driver-specific handling (e.g. the PS driver allowing the use of
PostScript fonts).The use of R__open_quiet() is presumably a remnant of the time when
d.font parsed the freetypecap file itself. It should just be removed,
so that R_open_driver() generates warnings if no monitor is selected
or running.
OK, I have removed the R__open_quiet() call in CVS, now it works as
expected from your explanations:
GRASS 6.3.cvs (nc_spm_05):~ > d.font -l
WARNING: No socket to connect to for monitor <x0>.
GRASS 6.3.cvs (nc_spm_05):~ > d.font -L
WARNING: No socket to connect to for monitor <x0>.
GRASS 6.3.cvs (nc_spm_05):~ > d.mon x0
using default visual which is TrueColor
ncolors: 16777216
Graphics driver [x0] started
GRASS 6.3.cvs (nc_spm_05):~ > d.font -l
cyrilc
gothgbt
...
umeplus-p-gothic
b018015l
...
z003034l
z003034l
a010013l
a010013l
a010033l
...
GRASS 6.3.cvs (nc_spm_05):~> d.font -L
cyrilc|cyrilc|0|/home/neteler/grass63/dist.x86_64-unknown-linux-gnu/fonts/cyrilc.hmp|0|utf-8|
gothgbt|gothgbt|0|/home/neteler/grass63/dist.x86_64-unknown-linux-gnu/fonts/gothgbt.hmp|0|utf-8|
...
a_d_mono|A.D. MONO Regular|1|/usr/share/fonts/ttf/western/a_d_mono.ttf|0|utf-8|
actionis|ActionIs Regular|1|/usr/share/fonts/ttf/decoratives/actionis.ttf|0|utf-8|
Adventure|Adventure Normal|1|/usr/share/fonts/ttf/western/Adventure.ttf|0|utf-8|
uming|AR PL ShanHeiSun Uni Regular|1|/usr/share/fonts/TTF/chinese/uming.ttf|0|utf-8|
ukai|AR PL ZenKai Uni Medium|1|/usr/share/fonts/TTF/chinese/ukai.ttf|0|utf-8|
This should include the updates from Paul today.
Ehm, would it be possible to sort the output (sorry for bothering)?
Generally, it is really nice to have this improved font infrastructure!
Now some tests:
# randomly grab a font
d.font actionis
echo "GRASS is green" | d.text
# PNG
d.out.file map form=png res=4
display map.png
# ... works nicely
# EPS
d.out.file map form=eps res=4
gv map.eps
ERROR: /unknownerror in --imagemask--ESP Ghostscript 815.03: Unrecoverable error, exit code 1
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- 5 3 %oparray_pop
Dictionary stack:
--dict:1123/1686(ro)(G)-- --dict:0/20(G)-- --dict:132/200(L)--
Current allocation mode is local
Last OS error: 2
Current file position is 4341
# PS
d.out.file map form=ps res=4
gv map.ps
# ... works, but it's an image, not vector (you will know that)
I tried the latter since you mentioned "the PS driver allowing the use of
PostScript fonts" - maybe that's yet future, I am not fully up to date
here.
Markus
On Thu, 26 Jul 2007, Markus Neteler wrote:
[...]
GRASS 6.3.cvs (nc_spm_05):~ > d.font -l
cyrilc
gothgbt
...
umeplus-p-gothic
b018015l
...
z003034l
a010013l
a010033l
...GRASS 6.3.cvs (nc_spm_05):~> d.font -L
cyrilc|cyrilc|0|/home/neteler/grass63/dist.x86_64-unknown-linux-gnu/fonts/cyrilc.hmp|0|utf-8|
gothgbt|gothgbt|0|/home/neteler/grass63/dist.x86_64-unknown-linux-gnu/fonts/gothgbt.hmp|0|utf-8|
...
a_d_mono|A.D. MONO Regular|1|/usr/share/fonts/ttf/western/a_d_mono.ttf|0|utf-8|
actionis|ActionIs Regular|1|/usr/share/fonts/ttf/decoratives/actionis.ttf|0|utf-8|
Adventure|Adventure Normal|1|/usr/share/fonts/ttf/western/Adventure.ttf|0|utf-8|
uming|AR PL ShanHeiSun Uni Regular|1|/usr/share/fonts/TTF/chinese/uming.ttf|0|utf-8|
ukai|AR PL ZenKai Uni Medium|1|/usr/share/fonts/TTF/chinese/ukai.ttf|0|utf-8|This should include the updates from Paul today.
The stroke fonts don't have descriptive long names in the above example (just a copy of the short name) - you may need to run "g.mkfontcap -o" to overwrite your fontcap file. I changed it so it won't automatically overwrite it when re-compiling, as I thought that was a bad idea in case someone might have manually edited their file (e.g. to include only the fonts they commonly used, in their preferred order 
But maybe sorting by short name is a better idea than long name, and it should be up to the GUI to sort on long name if that's a better option for it - the patch below will make the sort operate on the short name (you will need to re-run g.mkfontcap -o again):
RCS file: /home/grass/grassrepository/grass6/general/g.mkfontcap/main.c,v
retrieving revision 1.4
diff -u -r1.4 main.c
--- general/g.mkfontcap/main.c 26 Jul 2007 14:01:16 -0000 1.4
+++ general/g.mkfontcap/main.c 26 Jul 2007 22:01:56 -0000
@@ -195,8 +195,8 @@
return (aa->type > bb->type);
else
{
- const char *na = aa->longname;
- const char *nb = bb->longname;
+ const char *na = aa->name;
+ const char *nb = bb->name;
return G_strcasecmp(na, nb);
About the d.font -L output - I'd been thinking (shortly before Glynn implemented it) that it might be quite neat to have some kind of font_info() function that could be passed the name of a font from R_font_list(), and it would return a GFONT_CAP struct (defined in grass/freetypecap.h) with all the font info - and then d.font or other programs could take the font info from the members of this struct and format the output as they saw fit. But perhaps this would have been over-complicated to implement in the existing driver structure - I'm really not sure and also not sure how much use if any it would be for other modules.
Paul
On Fri, 27 Jul 2007, Markus Neteler wrote:
Hello Paul,
stupid question: what about a GRASS system fontcap file and
a user one? Then read in together and concatenate before
going ahead? Then accidential overwrite won't happen.
Hmmm, I think that might be over-complicating things a bit? I suppose the fontcap file can already be considered a "user" file as it reflects the fonts available on the user's local machine. And g.mkfontcap is like a tool to help the user create the file I suppose, e.g. it has an option to add extra directories to search for fonts.
I'm not sure what's best. But the file will always be re-generated after a make distclean anyway, and it's not likely to become out of date unless someone adds new fonts to their system - but maybe it should be clearly documented somewhere that g.mkfontcap needs to be run to pick up the new fonts? That is probably only relevant to GUI users anyway, who might get confused between the GRASS font list and the font list displayed in other GUI applications. "Scan local system for available fonts" could perhaps be an advanced option in the GUI somewhere, and it would simply run g.mkfontcap -o plus it could maybe have an option to specify extra directories to look for fonts in?
I think once the current changes settle down there won't really be an issue here, but it will be interesting to see if any further issues arise from the way the GUI uses the fonts.
Paul