nanogui: Thread: Font usage/setup


[<<] [<] Page 3 of 3 [>] [>>]
Subject: RE: [nanogui] Font usage/setup
From: "Martin Kajdas" ####@####.####
Date: 13 Jan 2006 00:11:53 +0000
Message-Id: <CF2BB830A62F914F848E5AD5FFF57AC22914A2@mkmail.MKPROD.COM>

I am using 565 mode.
It only happens with TTF fonts. Fixed fonts are OK.
If I change the foreground color to 1, it (TTF) works and is black enough for me.
Something magical is with foreground=0 and TTF

I will check X11 and GrSetGCUseBackground and get back with the info, but X11 worked the last time I checked.
Martin


-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Thursday, January 12, 2006 4:02 PM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] Font usage/setup


> it does not like foreground color=0 (background color is also 0 (actually
0xFFFF0000) but it is ignored; transparent).
The color=0 should print black and it works correctly with fixed fonts on
nano-X and on X11 (all fonts).

Hmmm..  0xFFFF0000 isn't 0, are hw color format are you running, RGB or 565?
I'm confused by these values.


> When I forced the foreground color (in Text.c of nxlib) to be something
else it displayed correctly.
It must be a bug in nxlib, but where?

Since you're running CVS, it isn't the transparent color bug then, since
that's
known fixed.  Look for usage of GrSetGCUseBackground, that should probably
always be set to TRUE.

Does this happen only with TTF fonts, and not with fixed?  Always works
on X11 but not on your target?

Regards,

Greg

Subject: Re: [nanogui] Font usage/setup
From: "Greg Haerr" ####@####.####
Date: 13 Jan 2006 00:41:13 +0000
Message-Id: <01fd01c617da$0a5156d0$6401a8c0@winXP>

> It only happens with TTF fonts. Fixed fonts are OK.
If I change the foreground color to 1, it (TTF) works and is black enough
for me.
Something magical is with foreground=0 and TTF

I will check X11 and GrSetGCUseBackground and get back with the info, but
X11 worked the last time I checked.


If X11 works, but framebuffer doesn't, then it could be a driver issue.
You'll want to grep for the GdArea call in the TTF font driver, where
it takes a bitmap that has been created from the TTF library in
nano-X format, which then blits it.  I'm thinking perhaps the blit
routine is drawing pixel-by-pixel, and that's where the problem
is, possibly with the transparent color.

Regards,

Greg

Subject: RE: [nanogui] Font usage/setup
From: "Martin Kajdas" ####@####.####
Date: 13 Jan 2006 18:44:40 +0000
Message-Id: <CF2BB830A62F914F848E5AD5FFF57AC22914A3@mkmail.MKPROD.COM>

I checked the font_freetype.c code and there (line 352) is a statement:
FIXME: GdArea problem if fg == bg

This certainly would qualify when they are both zero.
I guess the magic is not really when foreground==0 but when foreground==background (which I never tried other than zero).
At this point I have no idea how to fix this.
Any pointers,
Martin


-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Thursday, January 12, 2006 4:41 PM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] Font usage/setup


> It only happens with TTF fonts. Fixed fonts are OK.
If I change the foreground color to 1, it (TTF) works and is black enough
for me.
Something magical is with foreground=0 and TTF

I will check X11 and GrSetGCUseBackground and get back with the info, but
X11 worked the last time I checked.


If X11 works, but framebuffer doesn't, then it could be a driver issue.
You'll want to grep for the GdArea call in the TTF font driver, where
it takes a bitmap that has been created from the TTF library in
nano-X format, which then blits it.  I'm thinking perhaps the blit
routine is drawing pixel-by-pixel, and that's where the problem
is, possibly with the transparent color.

Regards,

Greg

Subject: Re: [nanogui] Font usage/setup
From: "Greg Haerr" ####@####.####
Date: 16 Jan 2006 17:13:01 +0000
Message-Id: <002101c61ac0$16aa9980$6401a8c0@winXP>

> I checked the font_freetype.c code and there (line 352) is a statement:
FIXME: GdArea problem if fg == bg
This certainly would qualify when they are both zero.
I guess the magic is not really when foreground==0 but when
foreground==background (which I never tried other than zero).

The if statement is there to optimize and not draw anything if the
fg and bg colors are the same.  The bg was already drawn earlier,
so there wouldn't be any need to draw the fg color.

Start by commenting out the if statement, just leaving the GdArea call.
Let me know if that makes things work.

Regards,

Greg

Subject: RE: [nanogui] Font usage/setup
From: "Martin Kajdas" ####@####.####
Date: 17 Jan 2006 17:47:26 +0000
Message-Id: <CF2BB830A62F914F848E5AD5FFF57AC22914A4@mkmail.MKPROD.COM>

I got my fonts working and I would like to summarize my findings/fixes for others to use.
Because, my application is FLTK based and uses nxlib to communicate with nano-X, many problems are mostly nxlib based and FLTK + X11 specific and will not show up with other applications.
That is why I tried to put my fixes into nxlib when possible instead of nano-X so not to break other people's code which is working.

Summary of what I found:

1. font_pcf.c in nano-X (engine) needs to be updated with patched file from microwindows web site which is still not included in CVS. This was necessary in order to use X11 fonts without GrCreateFont() hanging up.

2. font_freetype.c and font_t1lib.c in nano-X (engine) need to be fixed to work properly with gr_foreground == gr_background. The recommended fix (commented out) will not work as block outlines of letters are only printed. The background color must stay transparent and it does not with the fix.

3. Text.c in nxlib (XDrawString()) I modified to check foreground and background colors of the string and if they are the same, I increase the foreground color by 1. I did it here instead of modifying font_freetype.c and font_t1lib.c in nano-X.

4. LoadFont.c in nxlib needs to be fixed (_nxFindX11Font()) to properly match TTF font names (i.e. ...12-0-0...==...0-0-0... and size=12) and call GrCreateFont() with proper font size.

Once, the fonts are properly created, the main problem is with nano-X's Area draw function.
When foreground==background color, it is assumed that the background is already drawn and the foreground need not be.
This is a problem when the background is transparent and is not drawn and so is the foreground, resulting in nothing being drawn.
The nano-X's drawing algorithm needs to be fixed so this case is handled properly.
I will get into this next because I am having some problems with some images not being drawn (which I believe it is related to this) but I will start a separate email thread.

Martin



-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Monday, January 16, 2006 9:13 AM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] Font usage/setup


> I checked the font_freetype.c code and there (line 352) is a statement:
FIXME: GdArea problem if fg == bg
This certainly would qualify when they are both zero.
I guess the magic is not really when foreground==0 but when
foreground==background (which I never tried other than zero).

The if statement is there to optimize and not draw anything if the
fg and bg colors are the same.  The bg was already drawn earlier,
so there wouldn't be any need to draw the fg color.

Start by commenting out the if statement, just leaving the GdArea call.
Let me know if that makes things work.

Regards,

Greg

Subject: Re: [nanogui] Font usage/setup
From: Peter Barada ####@####.####
Date: 17 Jan 2006 18:11:34 +0000
Message-Id: <20060117181112.B6F0A98B92@baradas.org>

>I got my fonts working and I would like to summarize my
>findings/fixes for others to use. 

Can you make a patch available?

-- 
Peter Barada
####@####.####
Subject: RE: [nanogui] Font usage/setup
From: "Martin Kajdas" ####@####.####
Date: 17 Jan 2006 18:33:37 +0000
Message-Id: <CF2BB830A62F914F848E5AD5FFF57AC22914A5@mkmail.MKPROD.COM>

I can make a patch for LoadFont.c and Text.c in nxlib which together
with already available patched font_pcf.c (Greg, please review and
release into CVS) for nano-X make TTF fonts work for me.
I will clean up my code and do that within next couple of days.

I do not want to get into draw functions of nano-X where the source of
the problem lies, but I may have to to fix my image drawing problems.
Martin


-----Original Message-----
From: Peter Barada ####@####.####
Sent: Tuesday, January 17, 2006 10:11 AM
To: Martin Kajdas
Cc: ####@####.#### ####@####.####
Subject: Re: [nanogui] Font usage/setup



>I got my fonts working and I would like to summarize my
>findings/fixes for others to use. 

Can you make a patch available?

-- 
Peter Barada
####@####.####
Subject: Re: [nanogui] Font usage/setup
From: "Greg Haerr" ####@####.####
Date: 22 Sep 2006 01:04:37 +0100
Message-Id: <09f301c6ddda$af22f2b0$6401a8c0@winXP>

Hi Martin -

Here's your email solving the TTF (and PCF) font problems in
nano-X, last January.

I've finally figured the reason this isn't fixed in CVS is that I never
received (or at least, can't find or didn't find) a patch from
you for the NXLIB changes.  Can you please resend a patch against
the current CVS for NXLIB?  I'll then apply it and that will solve
Kiran's problems.

Also, if you could diff your font_pcf.c with my CVS version, I thought
I applied a fix there, but don't have any outstanding patches from you
on my system.

Regards,

Greg


----- Original Message ----- 
From: "Martin Kajdas" ####@####.####
To: "Greg Haerr" ####@####.#### ####@####.####
Sent: Tuesday, January 17, 2006 11:47 AM
Subject: RE: [nanogui] Font usage/setup


I got my fonts working and I would like to summarize my findings/fixes for
others to use.
Because, my application is FLTK based and uses nxlib to communicate with
nano-X, many problems are mostly nxlib based and FLTK + X11 specific and
will not show up with other applications.
That is why I tried to put my fixes into nxlib when possible instead of
nano-X so not to break other people's code which is working.

Summary of what I found:

1. font_pcf.c in nano-X (engine) needs to be updated with patched file from
microwindows web site which is still not included in CVS. This was necessary
in order to use X11 fonts without GrCreateFont() hanging up.

2. font_freetype.c and font_t1lib.c in nano-X (engine) need to be fixed to
work properly with gr_foreground == gr_background. The recommended fix
(commented out) will not work as block outlines of letters are only printed.
The background color must stay transparent and it does not with the fix.

3. Text.c in nxlib (XDrawString()) I modified to check foreground and
background colors of the string and if they are the same, I increase the
foreground color by 1. I did it here instead of modifying font_freetype.c
and font_t1lib.c in nano-X.

4. LoadFont.c in nxlib needs to be fixed (_nxFindX11Font()) to properly
match TTF font names (i.e. ...12-0-0...==...0-0-0... and size=12) and call
GrCreateFont() with proper font size.

Once, the fonts are properly created, the main problem is with nano-X's Area
draw function.
When foreground==background color, it is assumed that the background is
already drawn and the foreground need not be.
This is a problem when the background is transparent and is not drawn and so
is the foreground, resulting in nothing being drawn.
The nano-X's drawing algorithm needs to be fixed so this case is handled
properly.
I will get into this next because I am having some problems with some images
not being drawn (which I believe it is related to this) but I will start a
separate email thread.

Martin



-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Monday, January 16, 2006 9:13 AM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] Font usage/setup


> I checked the font_freetype.c code and there (line 352) is a statement:
FIXME: GdArea problem if fg == bg
This certainly would qualify when they are both zero.
I guess the magic is not really when foreground==0 but when
foreground==background (which I never tried other than zero).

The if statement is there to optimize and not draw anything if the
fg and bg colors are the same.  The bg was already drawn earlier,
so there wouldn't be any need to draw the fg color.

Start by commenting out the if statement, just leaving the GdArea call.
Let me know if that makes things work.

Regards,

Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####


[<<] [<] Page 3 of 3 [>] [>>]


Powered by ezmlm-browse 0.20.