PfGlyph() doesn't work properly

Hello everybody!

I try to write some code to display rotated text. To get it work I have to
access the glyph-bitmap (FontRender) returned by PfGlyph(). But the
returned bitmap always returns a non-antialiased glyph (FontRender.bpp =

  1. although I turned on antialiasing via PF_STYLE_ANTIALIAS while creating
    font name.

Anyone familiar with PfGlyph() ?

thanks in advance!

mirtch <mirtschink@xsys.de> wrote:

Hello everybody!

I try to write some code to display rotated text. To get it work I have to
access the glyph-bitmap (FontRender) returned by PfGlyph(). But the
returned bitmap always returns a non-antialiased glyph (FontRender.bpp =

  1. although I turned on antialiasing via PF_STYLE_ANTIALIAS while creating
    font name.

Anyone familiar with PfGlyph() ?

thanks in advance!

Current versions of the fontserver do not support anti-aliased glyph fetching.
In reality, it is very unlikely you would be satisified with the results.
Anti-aliasing does the following:

  1. Affects, or turns off the delta hinting.
  2. Produces an alpha-map, not a graymap. Therefore the values
    within the middle of the range (0x00 0xFF) do not necessarily
    end up being the same as a straight graymap.

If you really want the alphamaps, use PfRenderCx. In order to process
an alphamap correctly, you need to read the hardware pixel values in order
to apply the alpha correctly.

I strongly recommend using straight bitmaps for your purpose, especially when
using a delta-hinted/hinted font(s) such as PrimaSans BT (TextFont), Swis721 BT,
basically all the core fonts shipped with Momentics.

Regards.

Hi Derek!

You recommend me using bitmaps because nearly all qnx-fonts are
delta-hinted. But I have to concentrate on a third-party font in my work,
so it would be nice if I get some kind of alphamap. By the way, I didn’t
expect, the bitmap would be a graymap…I thought that there was a 4-bit
alpha-value stored per pixel.

However, when I use PfRenderCx(): where should be the alphamap there?

Why does this not work? (there’s always invalid argument in PfRenderCx())

void renderGlyph (void *data, const PhPoint_t *pos, const FontRender
*metrics)
{
printf(“renderGlyph()\n”);
printf(“bitmap is of size %dx%d\n”, metrics->size.x, metrics->size.y);
printf(“bpp: %d\n”,metrics->bpp);
}

PtInit (NULL);
if( (fontSvrCtxt = PfAttach(NULL, -1)) == NULL)
{
printf(“PfAttach() failed\n”);
PtExit(EXIT_FAILURE);
}

if(PfGenerateFontName(“Helvetica”,
PF_STYLE_ANTIALIAS,
18,
szFont) == NULL)
return(Pt_CONTINUE);

if(PfRenderCx(fontSvrCtxt,
(void*)“test”,
szFont,
0,
0,
“m”,
strlen(“m”),
0,
&pos,
&clipRect,
renderGlyph)==-1)
{
perror(“PfRenderCx()”);
}

Derek Leach wrote:

mirtch <> mirtschink@xsys.de> > wrote:
Hello everybody!

I try to write some code to display rotated text. To get it work I have to
access the glyph-bitmap (FontRender) returned by PfGlyph(). But the
returned bitmap always returns a non-antialiased glyph (FontRender.bpp =

  1. although I turned on antialiasing via PF_STYLE_ANTIALIAS while creating
    font name.

Anyone familiar with PfGlyph() ?

thanks in advance!

Current versions of the fontserver do not support anti-aliased glyph
fetching.
In reality, it is very unlikely you would be satisified with the results.
Anti-aliasing does the following:

  1. Affects, or turns off the delta hinting.
  2. Produces an alpha-map, not a graymap. Therefore the values
    within the middle of the range (0x00 0xFF) do not necessarily
    end up being the same as a straight graymap.

If you really want the alphamaps, use PfRenderCx. In order to process
an alphamap correctly, you need to read the hardware pixel values in order
to apply the alpha correctly.

I strongly recommend using straight bitmaps for your purpose, especially when
using a delta-hinted/hinted font(s) such as PrimaSans BT (TextFont), Swis721
BT,
basically all the core fonts shipped with Momentics.

Regards.

mirtch wrote:

Hi Derek!

You recommend me using bitmaps because nearly all qnx-fonts are
delta-hinted. But I have to concentrate on a third-party font in my work,
so it would be nice if I get some kind of alphamap. By the way, I didn’t
expect, the bitmap would be a graymap…I thought that there was a 4-bit
alpha-value stored per pixel.

However, when I use PfRenderCx(): where should be the alphamap there?

Why does this not work? (there’s always invalid argument in PfRenderCx())

void renderGlyph (void *data, const PhPoint_t *pos, const FontRender
*metrics)
{
printf(“renderGlyph()\n”);
printf(“bitmap is of size %dx%d\n”, metrics->size.x, metrics->size.y);
printf(“bpp: %d\n”,metrics->bpp);
}

PtInit (NULL);
if( (fontSvrCtxt = PfAttach(NULL, -1)) == NULL)
{
printf(“PfAttach() failed\n”);
PtExit(EXIT_FAILURE);
}

if(PfGenerateFontName(“Helvetica”,
PF_STYLE_ANTIALIAS,
18,
szFont) == NULL)
return(Pt_CONTINUE);

if(PfRenderCx(fontSvrCtxt,
(void*)“test”,
szFont,
0,
0,
“m”,
strlen(“m”),
0,
&pos,
&clipRect,
renderGlyph)==-1)
{
perror(“PfRenderCx()”);
}

Derek Leach wrote:


mirtch <> mirtschink@xsys.de> > wrote:

Hello everybody!


I try to write some code to display rotated text. To get it work I have to
access the glyph-bitmap (FontRender) returned by PfGlyph(). But the
returned bitmap always returns a non-antialiased glyph (FontRender.bpp =

  1. although I turned on antialiasing via PF_STYLE_ANTIALIAS while creating
    font name.


    Anyone familiar with PfGlyph() ?


    thanks in advance!


    Current versions of the fontserver do not support anti-aliased glyph

fetching.

In reality, it is very unlikely you would be satisified with the results.
Anti-aliasing does the following:

\

  1. Affects, or turns off the delta hinting.
  2. Produces an alpha-map, not a graymap. Therefore the values
    within the middle of the range (0x00 0xFF) do not necessarily
    end up being the same as a straight graymap.


    If you really want the alphamaps, use PfRenderCx. In order to process
    an alphamap correctly, you need to read the hardware pixel values in order
    to apply the alpha correctly.


    I strongly recommend using straight bitmaps for your purpose, especially when
    using a delta-hinted/hinted font(s) such as PrimaSans BT (TextFont), Swis721

BT,

basically all the core fonts shipped with Momentics.


Regards.

\

another one bites the same bug, if you havn’t already, update this in
the docs :slight_smile:

You must allocate shared memory storage with PfAttach for PfRenderCx to
work.


/Johan Björk

Johan Björk <phearbear@home.se> wrote:

another one bites the same bug, if you havn’t already, update this in
the docs > :slight_smile:

You must allocate shared memory storage with PfAttach for PfRenderCx to
work.



/Johan Björk

But the docs do say this, under PfRenderCx:

When a request to construct the bitmap is sent to the font server, the string
bitmap is returned, for efficiency, in the shared-memory area created through
the initial call to PfAttach().

Under PfAttach is states:

size
The size of an area in shared memory to set up between the task and the
server for returning text bitmaps (normally only required by graphics
drivers). If this argument is -1, the value of the PHFONTMEM
environment variable is used; if size is 0, no such memory area is created.

I do not know how one would make it any clearer, unless something like this
was added to documentation for PfRenderCx:

WHEN INVOKING PfAttach, MAKE SURE YOU PASS A NON-ZERO VALUE FOR THE ‘size’
PARAMETER IN ORDER TO CREATE A RENDER BUFFER.

Is this what you want?

Regards.

Derek Leach wrote:

Johan Björk <> phearbear@home.se> > wrote:

another one bites the same bug, if you havn’t already, update this in
the docs > :slight_smile:


You must allocate shared memory storage with PfAttach for PfRenderCx to
work.



/Johan Björk


But the docs do say this, under PfRenderCx:

When a request to construct the bitmap is sent to the font server, the string
bitmap is returned, for efficiency, in the shared-memory area created through
the initial call to PfAttach().

Under PfAttach is states:

size
The size of an area in shared memory to set up between the task and the
server for returning text bitmaps (normally only required by graphics
drivers). If this argument is -1, the value of the PHFONTMEM
environment variable is used; if size is 0, no such memory area is created.

I do not know how one would make it any clearer, unless something like this
was added to documentation for PfRenderCx:

WHEN INVOKING PfAttach, MAKE SURE YOU PASS A NON-ZERO VALUE FOR THE ‘size’
PARAMETER IN ORDER TO CREATE A RENDER BUFFER.

Well, ^_^…
Is this what you want?

Regards.

Hi

Oups, really sorry about that.
I meant when using PfRenderCtx, the ‘default’ fontcontext created with
PtInit normally isn’t created with shared memory area.
A specific explaination on the errno returned saying that it means that
there is no shared memory area allocated might be a good idea.

That’s really something that’d I’d appricate in other places in the
documentation too, sometimes you get errno values that doesn’t initially
make sense at all.
A few functions have those explainations already and they are great.

Thank you

/Johan Björk aka phearbear

Johan Björk <phearbear@home.se> wrote:

Hi

Oups, really sorry about that.

No need to be.

I meant when using PfRenderCtx, the ‘default’ fontcontext created with
PtInit normally isn’t created with shared memory area.
A specific explaination on the errno returned saying that it means that
there is no shared memory area allocated might be a good idea.

That’s really something that’d I’d appricate in other places in the
documentation too, sometimes you get errno values that doesn’t initially
make sense at all.
A few functions have those explainations already and they are great.

Thank you

/Johan Björk aka phearbear

Well you will be happy to know, that I just slogged through
the entire libfont (6.3), not too long ago and documented as
many errno combinations as possible. Now, there is a possibility
of getting the same errno for two different problems, but the
duplicates are documented. With this approach, the documentation
can then be synced with the source.

Example of what will be available:

/** Decompose the text string in the given font to a bitmap.

    • Description: Send text render message to the font server.
    • Arguments:
  •  - context : Font context.
    
  •  - ctx : Context to pass to ctxfunc draw callback.
    
  •  - font : Font stem to use for render.
    
  •  - adata : Fractional 16.16 horizontal size.
    
  •  - bdata : Fractional 16.16 vertical size.
    
  •  - str : String to process.
    
  •  - len : Length, in bytes, of 'str'.
    
  •  - flags : Flags describing format of str (utf- 8, 16- bit wchar, 32- bit wchar),
    
  •            and type of extent, normal, or fractional.
    
  •  - pos : Offset which to apply to render (required).
    
  •  - clip : Rectangle to whcih to clip render.
    
  •  - func : Context (ctx) draw callback.
    
    • Returns : 0 on success (or str == NULL), -1 on error (errno set).
    • Errors (common):
  •  - ESRCH : Unable to locate device.
    
  •  - EBADF : Connection has gone stale, or device error occurred.
    
  •  - ENETUNREACH : Bad message buffer.
    
  •  - ELIBACC : Unable to locate render plugin for specified font.
    
  •  - ENOMEM : Insufficient memory to allocate scaling resources.
    
  •  - ENOTSUP : Desired processing is not supported by particular render plugin.
    
  •  - EFAULT : If fractional request, scaling values are less than zero.
    
  •  - ERANGE : Unable to satisfy extension request for fractional processing.
    
  •  - EFAULT : Unable to locate font description.
    
  •  - ENOENT : Unable to locate suitable base font entry.
    
  •  - EINVAL : Fixed width font has invalid size.
    
    • Errors (render):
  •  - EINVAL : Invalid render buffer type.
    
  •  - ENOSPC : Request too large for render buffer.
    
    • Errors (extent):
  •  - EINVAL : Failure to load resources for specified font.
    
  •  - ENOSPC : Render plugin does not support string truncation.
    

*/
int PfRenderCx(struct _Pf_ctrl * context, void *ctx, const char *font, …);

This ought to remove some of the confusion. I hope to get a chance
to flush out the descriptions more if necessary.

Regards.