All,
We are writing a rendering plugin for unidrv.dll and we are seeing some
strange things when we are looking at the GLYPHPOS structures being sent to
our hooked OEMTextOut call…
The glyphs start out their positioning just fine, but about the time when
the pgp.ptl.y coordinates start approaching 800, we:
- get a negative number for the y coordinate and a duplication of the last
set of glyphs / last enumeration of the STROBJ…
- the offsets for the y coordinates restart at low numbers
- when they approach around 800 again, the line is duplicated, and the y
coordinates start over again…
Has anyone else seen this happen?
In pseudocode our function (called from OEMTextOut) is:
/********************************************/
STROBJ_vEnumStart(pstro);
do {
if (enumeration needed) {
call STROBJ_bEnumPositionsOnly
}
else {
use the STROBJ parameters
}
for (each glyph we have)
{
print out the coordinates of the glyph
}
} while (more glyphs to enumerate);
/********************************************/
Simple and compact… We don’t care about the actual glyph bits, hence
calling STROBJ_bEnumPositionsOnly… we’re just trying to capture the
coordinates for the glyphs… and 800 is far short of the max that a ptl
structure can hold…
Any help would be greatly appreciated…
Thanks,
sean
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hi,
I am not sure why you are seeing this strange behavior. Your basic algo
seems to be fine unless there is some mistake in the actual call to
STROBJ_bEnumPositionsOnly. Your pseudocode has the typical steps that
are used by developers and as far as I know there has been no problem
with it. Are you able to repro this if you add your code to the
otherwise unmodified oemuni sample?
-----Original Message-----
From: xxxxx@stg.com [mailto:xxxxx@stg.com]
Sent: Tuesday, October 30, 2001 11:40 AM
To: NT Developers Interest List
Subject: [ntdev] oemuni.dll/OEMTextOut glyph position question
All,
We are writing a rendering plugin for unidrv.dll and we are seeing
some
strange things when we are looking at the GLYPHPOS structures being sent
to
our hooked OEMTextOut call…
The glyphs start out their positioning just fine, but about the time
when
the pgp.ptl.y coordinates start approaching 800, we:
- get a negative number for the y coordinate and a duplication of the
last
set of glyphs / last enumeration of the STROBJ…
- the offsets for the y coordinates restart at low numbers
- when they approach around 800 again, the line is duplicated, and the y
coordinates start over again…
Has anyone else seen this happen?
In pseudocode our function (called from OEMTextOut) is:
/********************************************/
STROBJ_vEnumStart(pstro);
do {
if (enumeration needed) {
call STROBJ_bEnumPositionsOnly
}
else {
use the STROBJ parameters
}
for (each glyph we have)
{
print out the coordinates of the glyph
}
} while (more glyphs to enumerate);
/********************************************/
Simple and compact… We don’t care about the actual glyph bits, hence
calling STROBJ_bEnumPositionsOnly… we’re just trying to capture the
coordinates for the glyphs… and 800 is far short of the max that a ptl
structure can hold…
Any help would be greatly appreciated…
Thanks,
sean
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Ashwin,
Thanks for the response… The code is actually the only change to the
otherwise umodified sample… so the only thing that changes is that we are
spitting out the character codes and their coordinates…
It seems like the restarting of the y coordinates within the page may be
due to banding within the page (I’m a graphics driver guy trying to help
fix a problem with the generic text driver, so this is new to me :). Should
the coordinates restart with each band within a page (ie: each time
OEMNextBand is called)?
Thanks,
sean
On 10/31/01, ““Ashwin Needamangala” ” wrote:
> Hi,
>
> I am not sure why you are seeing this strange behavior. Your basic algo
> seems to be fine unless there is some mistake in the actual call to
> STROBJ_bEnumPositionsOnly. Your pseudocode has the typical steps that
> are used by developers and as far as I know there has been no problem
> with it. Are you able to repro this if you add your code to the
> otherwise unmodified oemuni sample?=20
>
> - Ashwin
>
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hi Sean,
Have you enabled banding in your driver? Although you do not have
absolute control over whether banding occurs or not, I doubt if banding
is occuring in your case. Is OEMNextBand called at all? Depending on the
type of documents being printed, banding might occur - for memory
efficiency. Are you sure that banding is occuring?
-----Original Message-----
From: xxxxx@stg.com [mailto:xxxxx@stg.com]
Sent: Thursday, November 01, 2001 1:31 AM
To: NT Developers Interest List
Subject: [ntdev] RE: oemuni.dll/OEMTextOut glyph position question
Ashwin,
Thanks for the response… The code is actually the only change to the
otherwise umodified sample… so the only thing that changes is that we
are
spitting out the character codes and their coordinates…
It seems like the restarting of the y coordinates within the page may
be
due to banding within the page (I’m a graphics driver guy trying to help
fix a problem with the generic text driver, so this is new to me :).
Should
the coordinates restart with each band within a page (ie: each time
OEMNextBand is called)?
Thanks,
sean
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com