Hi everyone
I’m looking for a way to quickly get a characters advance, The only
function that seems to be able to give this value is the PfGetOutline
function, which is way too slow and I don’t need the outline data.
I’m trying to calculate the width for invidual characters, right now i’m
using PfExtent, but it returns the full width of the character, and when
using italic fonts, the value is too big and the cursor gets missplaced.
Any hints?
TIA
/Johan Björk
Johan Björk <phearbear@home.se> wrote:
Hi everyone
I’m looking for a way to quickly get a characters advance, The only
function that seems to be able to give this value is the PfGetOutline
function, which is way too slow and I don’t need the outline data.
I’m trying to calculate the width for invidual characters, right now i’m
using PfExtent, but it returns the full width of the character, and when
using italic fonts, the value is too big and the cursor gets missplaced.
Any hints?TIA
/Johan Björk
PfExtentTextCharPositions will provide the pixel pen draw positions,
or cursor positions (no next character bearingX applied). If
you need better example code, I may have some lying around.
This is the routine that the library uses to prevent clipping
to the bearingX and MaxX of a glyph.
If you actually need true metric data, there is no quick method.
Regards.
Derek Leach wrote:
Johan Björk <> phearbear@home.se> > wrote:
Hi everyone
I’m looking for a way to quickly get a characters advance, The only
function that seems to be able to give this value is the PfGetOutline
function, which is way too slow and I don’t need the outline data.
I’m trying to calculate the width for invidual characters, right now i’m
using PfExtent, but it returns the full width of the character, and when
using italic fonts, the value is too big and the cursor gets missplaced.
Any hints?
TIA
/Johan Björk
PfExtentTextCharPositions will provide the pixel pen draw positions,
or cursor positions (no next character bearingX applied). If
you need better example code, I may have some lying around.
This is the routine that the library uses to prevent clipping
to the bearingX and MaxX of a glyph.If you actually need true metric data, there is no quick method.
Regards.
Hi
Using the PfExtentFracTextCharPositions().
I Use the above func with only 1 char at a time, (might be able to
change it so it gives the whole string , hoping to find another solution
though.)
When drawing on the other hand, I give the full string.
Been looking at the values i’m getting
writing only ‘o’ s
PfExtentFractTextCharPositions → 10
the callback from PfRenderCx FontRender->width
‘o’ 11
‘oooo’ 41
‘ooooo’ 52
‘oooooooooo’ 103
etc resulting in my cursor more and more off the more I write…
Any Ideas?
/Johan
Johan Björk <phearbear@home.se> wrote:
Derek Leach wrote:
Johan Björk <> phearbear@home.se> > wrote:
[snip]
Hi
Using the PfExtentFracTextCharPositions().
I Use the above func with only 1 char at a time, (might be able to
change it so it gives the whole string , hoping to find another solution
though.)
You should do the entire string, because if the first character
has a left bearing, it will throw your values off. What are
you actually trying to do, write your own graphics driver, or
port some other GUI library?
When drawing on the other hand, I give the full string.
Been looking at the values i’m getting
writing only ‘o’ s
PfExtentFractTextCharPositions → 10
the callback from PfRenderCx FontRender->width
‘o’ 11
‘oooo’ 41
‘ooooo’ 52
‘oooooooooo’ 103
etc resulting in my cursor more and more off the more I write…
Ahh, your hurting my brain … the ‘width’ value is similar to the
advance, but the granularity of the ‘width’ pen position is too coarse …
The ‘width’ value, along with the ‘offset.x’ value, is used in the low
level rendering libraries to perform multi-pass rendering. The default
render buffer is only 32K, therefore the low level rendering API has
to sometimes perform multiple passes to complete the render request.
Why are you just trying the draw one character at a time?
What are you trying to accomplish with such low level APIs?
Regards.
Johan Bjork <phearbear@home.se> wrote:
Found another much worse problem with PfExtentFracTextCharPositions()
Seems the caching of font metrics is broken when using the Fractional
Scaling parameters, First time I request the metrics of a char, I get
the correct size with the Scaling factor applied, Requesting same
char/font with only the scaling factor changed and I seem to get the
same size as the first request./Johan Bjork
Ouch, please post a small test case.
Thank You.
Derek Leach <dleach@qnx.com> wrote:
Johan Bjork <> phearbear@home.se> > wrote:
Found another much worse problem with PfExtentFracTextCharPositions()
Seems the caching of font metrics is broken when using the Fractional
Scaling parameters, First time I request the metrics of a char, I get
the correct size with the Scaling factor applied, Requesting same
char/font with only the scaling factor changed and I seem to get the
same size as the first request./Johan Bjork
Ouch, please post a small test case.
Thank You.
Fractional characters do not seem to be cached at all,
but it could be in the setup of the transformation
matrix. If you could provide a test case, I would
appreciate it.
Regards.
Johan Björk wrote:
Derek Leach wrote:
Johan Björk <> phearbear@home.se> > wrote:
Hi everyone
I’m looking for a way to quickly get a characters advance, The only
function that seems to be able to give this value is the PfGetOutline
function, which is way too slow and I don’t need the outline data.
I’m trying to calculate the width for invidual characters, right now
i’m using PfExtent, but it returns the full width of the character,
and when using italic fonts, the value is too big and the cursor gets
missplaced.
Any hints?
TIA
/Johan Björk
PfExtentTextCharPositions will provide the pixel pen draw positions,
or cursor positions (no next character bearingX applied). If
you need better example code, I may have some lying around.
This is the routine that the library uses to prevent clipping
to the bearingX and MaxX of a glyph.If you actually need true metric data, there is no quick method.
Regards.
Hi
Using the PfExtentFracTextCharPositions().
I Use the above func with only 1 char at a time, (might be able to
change it so it gives the whole string , hoping to find another solution
though.)
When drawing on the other hand, I give the full string.
Been looking at the values i’m getting
writing only ‘o’ s
PfExtentFractTextCharPositions → 10
the callback from PfRenderCx FontRender->width
‘o’ 11
‘oooo’ 41
‘ooooo’ 52
‘oooooooooo’ 103
etc resulting in my cursor more and more off the more I write…Any Ideas?
/Johan
\
Found another much worse problem with PfExtentFracTextCharPositions()
Seems the caching of font metrics is broken when using the Fractional
Scaling parameters, First time I request the metrics of a char, I get
the correct size with the Scaling factor applied, Requesting same
char/font with only the scaling factor changed and I seem to get the
same size as the first request.
/Johan Björk
Derek Leach wrote:
Johan Björk <> phearbear@home.se> > wrote:
Derek Leach wrote:
Johan Björk <> phearbear@home.se> > wrote:
[snip]
Hi
Using the PfExtentFracTextCharPositions().
I Use the above func with only 1 char at a time, (might be able to
change it so it gives the whole string , hoping to find another solution
though.)
You should do the entire string, because if the first character
has a left bearing, it will throw your values off. What are
you actually trying to do, write your own graphics driver, or
port some other GUI library?
When drawing on the other hand, I give the full string.
Been looking at the values i’m getting
writing only ‘o’ s
PfExtentFractTextCharPositions → 10
the callback from PfRenderCx FontRender->width
‘o’ 11
‘oooo’ 41
‘ooooo’ 52
‘oooooooooo’ 103
etc resulting in my cursor more and more off the more I write…
Ahh, your hurting my brain … the ‘width’ value is similar to the
advance, but the granularity of the ‘width’ pen position is too coarse …
The ‘width’ value, along with the ‘offset.x’ value, is used in the low
level rendering libraries to perform multi-pass rendering. The default
render buffer is only 32K, therefore the low level rendering API has
to sometimes perform multiple passes to complete the render request.Why are you just trying the draw one character at a time?
What are you trying to accomplish with such low level APIs?Regards.
Sorry bout the hurting in the brain, Mine has been doing that for quite
a while too. I don’t draw each character one by one, I measure them.
This seems to be done for BiDi to work by quickly looking at the layout
code. I will probably be able to change this though. Thanks
I’m working on the QNX port of AbiWord(www.abisource.com)
There seem to be no other choice then using those functions when I need
the scaling.
I’ll see if I can do a small testcase for the zoom problem…
/Johan Björk
Johan Bjork <phearbear@home.se> wrote:
[snip]
Sorry bout the hurting in the brain, Mine has been doing that for quite
a while too. I don’t draw each character one by one, I measure them.
This seems to be done for BiDi to work by quickly looking at the layout
code. I will probably be able to change this though. ThanksI’m working on the QNX port of AbiWord(> www.abisource.com> )
There seem to be no other choice then using those functions when I need
the scaling.I’ll see if I can do a small testcase for the zoom problem…
/Johan Bjork
What version of Rtp are you using (uname -a)?
Derek Leach wrote:
Johan Bjork <> phearbear@home.se> > wrote:
Found another much worse problem with PfExtentFracTextCharPositions()
Seems the caching of font metrics is broken when using the Fractional
Scaling parameters, First time I request the metrics of a char, I get
the correct size with the Scaling factor applied, Requesting same
char/font with only the scaling factor changed and I seem to get the
same size as the first request.
/Johan Bjork
Ouch, please post a small test case.Thank You.
Hi again
Attached a little test case, unfortunatly it shows the same problem 
(
Any workaround or something? Be able to force it to clean the cache or
something parhaps?
/Johan
me Derek Leach wrote:
Johan Bjork <> phearbear@home.se> > wrote:
[snip]Sorry bout the hurting in the brain, Mine has been doing that for quite
a while too. I don’t draw each character one by one, I measure them.
This seems to be done for BiDi to work by quickly looking at the layout
code. I will probably be able to change this though. Thanks
I’m working on the QNX port of AbiWord(> www.abisource.com> )
There seem to be no other choice then using those functions when I need
the scaling.
I’ll see if I can do a small testcase for the zoom problem…
/Johan Bjork
What version of Rtp are you using (uname -a)?
6.2.1 beta
QNX buffelboff 6.2.1 2003/01/08-02:05:12est x86pc x86
Johan Björk <phearbear@home.se> wrote:
What version of Rtp are you using (uname -a)?
6.2.1 beta
QNX buffelboff 6.2.1 2003/01/08-02:05:12est x86pc x86
OK, I will have to review it. I cannot look at it today,
but will post when I find something. As per a work around,
no there is none. If you are using local metrics (PfLoadMetrics),
try not using that. If that changes anything, let me know.
Regards.
Derek Leach <dleach@qnx.com> wrote:
Johan Björk <> phearbear@home.se> > wrote:
What version of Rtp are you using (uname -a)?6.2.1 beta
QNX buffelboff 6.2.1 2003/01/08-02:05:12est x86pc x86OK, I will have to review it. I cannot look at it today,
but will post when I find something. As per a work around,
no there is none. If you are using local metrics (PfLoadMetrics),
try not using that. If that changes anything, let me know.Regards.
Well, the other issue I was working on was quite frustrating (memory
corruption), so I reviewed this problem. How does the following look?
$ ./a.out
scale = 1310720 , penpos[0] = 15 and rectmagic : 15
scale=327680 , penpos[0] = 4 and rectmagic : 4
The fractional pen routine in the font manager set everything up
correctly, but invoked a non-fractional routine to retrieve the
glyph metrics. Talk about defeating the purpose. This was not
an issue on the HEAD branch, since it is a different architecture.
I will submit a PR for 6.2.1A, and hopefully it will get approved.
Otherwise, I may be able to get a experimental package posted.
Regards.
Johan Bjork <phearbear@home.se> wrote:
[snip]
Well, the other issue I was working on was quite frustrating (memory
corruption), so I reviewed this problem. How does the following look?ugh, goodluck >
Thanks.
$ ./a.out
scale = 1310720 , penpos[0] = 15 and rectmagic : 15
scale=327680 , penpos[0] = 4 and rectmagic : 4Looks excellent >
The fractional pen routine in the font manager set everything up
correctly, but invoked a non-fractional routine to retrieve the
glyph metrics. Talk about defeating the purpose. This was not
an issue on the HEAD branch, since it is a different architecture.
I will submit a PR for 6.2.1A, and hopefully it will get approved.
Otherwise, I may be able to get a experimental package posted.Ew, so this means it’s in the fontserver itself then? Dammit, was hoping
Yep.
that it was in libph, then I’d parhaps would have been able to link
statically with a bugfixed lib… Oh well, guess i’ll revert to the old
code for now…Thanks, another bug bites the dust
I appreciate you posting the bug.
Regards.
Derek Leach wrote:
Derek Leach <> dleach@qnx.com> > wrote:
Johan Björk <> phearbear@home.se> > wrote:
What version of Rtp are you using (uname -a)?
6.2.1 beta
QNX buffelboff 6.2.1 2003/01/08-02:05:12est x86pc x86
OK, I will have to review it. I cannot look at it today,
but will post when I find something. As per a work around,
no there is none. If you are using local metrics (PfLoadMetrics),
try not using that. If that changes anything, let me know.
Regards.
Well, the other issue I was working on was quite frustrating (memory
corruption), so I reviewed this problem. How does the following look?ugh, goodluck >
$ ./a.out
scale = 1310720 , penpos[0] = 15 and rectmagic : 15
scale=327680 , penpos[0] = 4 and rectmagic : 4Looks excellent >
The fractional pen routine in the font manager set everything up
correctly, but invoked a non-fractional routine to retrieve the
glyph metrics. Talk about defeating the purpose. This was not
an issue on the HEAD branch, since it is a different architecture.
I will submit a PR for 6.2.1A, and hopefully it will get approved.
Otherwise, I may be able to get a experimental package posted.Ew, so this means it’s in the fontserver itself then? Dammit, was hoping
that it was in libph, then I’d parhaps would have been able to link
statically with a bugfixed lib… Oh well, guess i’ll revert to the old
code for now…
Thanks, another bug bites the dust 
Regards.