I am trying to use IPrintOemUni::ImageProcessing combined
with soft fonts to use unidrv to drive a printer which
requires custom compression of low resolution (images,
lineart) data as well as custom compression of high
resolution (ie font) data. I was hoping to compress the
low-res data in ImageProcessing() and then use the
TTDOWNLOAD_TTOUTLINE option of TTDownloadMethod() to get
the font data separately through calls to OutputCharStr().

However when I try this I find that OutputCharStr() is
never called and the text is always rendered at the low
resolution. Is what I want to do possible? I have tried
all the options to TTDownloadMethod(), and none of them
seem to make a difference.

Regards,
Hank Jones

RE: Using IPrintOemUni::ImageProcessing and soft fonts by ashwinn

ashwinn
Wed Jul 30 15:28:55 CDT 2003

------=_NextPart_0001_4661BD04
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

If you implement ImageProcessing, the code path in Unidrv changes
drastically. So I wouldn't be surprised if your font management callbacks
are no longer being called. What are you returning from ImageProcessing? If
you are dumping the data yourself, none of your other callbacks are going
to be called. Even if you are passing the data back to Unidrv, the code
path will differ. Since all you need to implement is custom compression
apart from your font management, I suggest that you implement
IPrintOemUni::Compression instead.

- Ashwin

This posting is provided "AS IS" with no warranties, and confers no rights.

------=_NextPart_0001_4661BD04
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 If you implement ImageProcessing, the code path in Unidrv changes drastically. So I wouldn't be surprised if your font management callbacks are no longer being called. What are you returning from ImageProcessing? If you are dumping the data yourself, none of your other callbacks are going to be called. Even if you are passing the data back to Unidrv, the code path will differ. Since all you need to implement is custom compression apart from your font management, I suggest that you implement IPrintOemUni::Compression instead.
\par
\par - Ashwin
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par }
------=_NextPart_0001_4661BD04--


Re: Using IPrintOemUni::ImageProcessing and soft fonts by ashwinn

ashwinn
Tue Aug 05 13:03:36 CDT 2003

------=_NextPart_0001_359A6AC8
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

All I said was that a lot of things can change in the code path when
ImageProcessing is implemented. Anyway, good to hear that you are now
getting called in your font mgmt callbacks. As for your other 2 problems...

- Are you also emitting the correct command when called in CommandCallback
for CmdXMoveAbsolute and CmdYMoveAbsolute? I cannot say for sure what the
problem is in your case without having a repro and doing some debugging.
But this is something that typically works. I would remove all the other
code from your plug-in and see if just having the CommandCallback for these
2 commands still causes the problem you are seeing. I just tested this with
a driver here and it worked just fine.

- The sizLogResPpi member in FONTOBJ only specifies the resolution of the
device for which the font has been realized. It doesn't specify the dpi of
the font itself. Unidrv's private PDEV has two separate POINTL members
named ptGrxRes and ptTextRes. These are filled based on what you specify in
the GPD. So from what I can see in the code, *TextDPI is not ignored even
if you implement the font callbacks. I think you are interpreting the
meaning of sizLogResPpi incorrectly.

- Ashwin

This posting is provided "AS IS" with no warranties, and confers no rights.

------=_NextPart_0001_359A6AC8
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 All I said was that a lot of things can change in the code path when ImageProcessing is implemented. Anyway, good to hear that you are now getting called in your font mgmt callbacks. As for your other 2 problems...
\par
\par - Are you also emitting the correct command when called in CommandCallback for CmdXMoveAbsolute and CmdYMoveAbsolute? I cannot say for sure what the problem is in your case without having a repro and doing some debugging. But this is something that typically works. I would remove all the other code from your plug-in and see if just having the CommandCallback for these 2 commands still causes the problem you are seeing. I just tested this with a driver here and it worked just fine.
\par
\par - The sizLogResPpi member in FONTOBJ only specifies the resolution of the device for which the font has been realized. It doesn't specify the dpi of the font itself. Unidrv's private PDEV has two separate POINTL members named ptGrxRes and ptTextRes. These are filled based on what you specify in the GPD. So from what I can see in the code, *TextDPI is not ignored even if you implement the font callbacks. I think you are interpreting the meaning of sizLogResPpi incorrectly.
\par
\par - Ashwin
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par }
------=_NextPart_0001_359A6AC8--


Re: Using IPrintOemUni::ImageProcessing and soft fonts by hankjones11

hankjones11
Tue Aug 05 20:00:35 CDT 2003

ashwinn@online.microsoft.com ("Ashwin [MS]") wrote in message news:<lWl1lv3WDHA.2192@cpmsftngxa06.phx.gbl>...
> All I said was that a lot of things can change in the code path when
> ImageProcessing is implemented. Anyway, good to hear that you are now
> getting called in your font mgmt callbacks. As for your other 2 problems...
>
> - Are you also emitting the correct command when called in CommandCallback
> for CmdXMoveAbsolute and CmdYMoveAbsolute? I cannot say for sure what the
> problem is in your case without having a repro and doing some debugging.
> But this is something that typically works. I would remove all the other
> code from your plug-in and see if just having the CommandCallback for these
> 2 commands still causes the problem you are seeing. I just tested this with
> a driver here and it worked just fine.

I am pretty sure the data I am seeing is not something that my plug-in
dll is emitting, as I commented out all the DrvWriteSpoolBuf() calls
in my code and it still occurs (in fact I turned my dll into nothing
but a shell and it still occurs). I am not unique in seeing this, see:

http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&threadm=OepkTvu5BHA.368%40tkmsftngp05&rnum=2&prev=/groups%3Fsourceid%3Dnavclient%26q%3DCmdYMoveAbsolute

I am guessing that it is an inconsistency in my GPD file that is
causing the problem, but nothing jumps out at me so I have printed it
below.

------- BEGIN GPD FILE

*GPDSpecVersion: "1.0"
*GPDFileVersion: "1.0"
*Include: "StdNames.gpd"
*ModelName: "NT 5 OEM Unidrv Customization Sample"
*MasterUnits: PAIR(1600, 1600)
*ResourceDLL: "unires.dll"
*PrinterType: PAGE
*MaxCopies: 99
*PrintRate: 8
*PrintRateUnit: PPM
*PrintRatePPM: 8

*Macros: MyCommands
{
START_JOB: 1
END_JOB: 2
START_PAGE: 3
END_PAGE: 4
SET_ORIENTATION: 5
SET_INPUTBIN: 6
SET_RESOLUTION: 7
SET_PAPERSIZE: 8
SET_MEDIATYPE: 9
SET_COLORMODE: 10
SET_COPIES: 11
CMD_MOVEX: 12
CMD_MOVEY: 13
CMD_CR: 14
CMD_LF: 15
CMD_FF: 16
CMD_SEND_BLOCK_DATA: 17
COLOR_IPID : 1
}


*Feature: Orientation
{
*rcNameID: =ORIENTATION_DISPLAY
*DefaultOption: PORTRAIT
*Option: PORTRAIT
{
*rcNameID: =PORTRAIT_DISPLAY
*Command: CmdSelect
{
*Order: DOC_SETUP.6
*CallbackID: =SET_ORIENTATION
}
}
*Option: LANDSCAPE_CC90
{
*rcNameID: =LANDSCAPE_DISPLAY
*Command: CmdSelect
{
*Order: DOC_SETUP.6
*CallbackID: =SET_ORIENTATION
}
}
}
*Feature: InputBin
{
*rcNameID: =PAPER_SOURCE_DISPLAY
*DefaultOption: UPPER
*Option: UPPER
{
*rcNameID: =UPPER_TRAY_DISPLAY
*Command: CmdSelect
{
*Order: DOC_SETUP.9
*CallbackID: =SET_INPUTBIN
}
}
}
*Feature: Resolution
{
*rcNameID: =RESOLUTION_DISPLAY
*DefaultOption: Option1
*Option: Option1
{
*Name: "320 x 320 " =DOTS_PER_INCH
*DPI: PAIR(320, 320)
*TextDPI: PAIR(320, 320)
*SpotDiameter: 100
*Command: CmdSendBlockData { *CallbackID: =CMD_SEND_BLOCK_DATA
}
*Command: CmdSelect
{
*Order: DOC_SETUP.4
*CallbackID: =SET_RESOLUTION
}
}
}

*Feature: PaperSize
{
*rcNameID: =PAPER_SIZE_DISPLAY
*DefaultOption: LETTER
*Option: LETTER
{
*rcNameID: =RCID_DMPAPER_SYSTEM_NAME
*PrintableArea: PAIR(12800, 16640)
*PrintableOrigin: PAIR(0, 0)
*Command: CmdSelect
{
*Order: DOC_SETUP.10
*CallbackID: =SET_PAPERSIZE
}
}
}
*Feature: MediaType
{
*rcNameID: =MEDIA_TYPE_DISPLAY
*DefaultOption: STANDARD
*Option: STANDARD
{
*rcNameID: =PLAIN_PAPER_DISPLAY
*Command: CmdSelect
{
*Order: DOC_SETUP.14
*CallbackID: =SET_MEDIATYPE
}
}
}

*Feature: ColorMode
{
*rcNameID: =COLOR_PRINTING_MODE_DISPLAY
*DefaultOption: Color
*Option: Color
{
*rcNameID: =24BPP_DISPLAY
*DevNumOfPlanes: 0
*DevBPP: 0
*DrvBPP:24
*Color? : TRUE
*ColorPlaneOrder: LIST(YELLOW, MAGENTA, CYAN, BLACK)
*RasterMode: DIRECT
*IPCallbackID: =COLOR_IPID
*Command: CmdSelect
{
*Order: DOC_SETUP.90
*CallbackID: =SET_COLORMODE
}
}
}


*Command: CmdStartDoc
{
*Order: DOC_SETUP.5
*CallbackID: =START_JOB
}
*Command: CmdStartPage
{
*Order: PAGE_SETUP.1
*CallbackID: =START_PAGE
}
*Command: CmdEndPage
{
*Order: PAGE_SETUP.1
*CallbackID: =END_PAGE
}
*Command: CmdEndJob
{
*Order: JOB_FINISH.1
*CallbackID: =END_JOB
}
*Command: CmdCopies
{
*Order: DOC_SETUP.11
*CallbackID: =SET_COPIES
}
*XMoveUnit: 1600
*YMoveUnit: 1600
*Command: CmdXMoveAbsolute { *CallbackID: 21 }
*Command: CmdYMoveAbsolute { *CallbackID: 22 }
*Command: CmdCR { *CallbackID: =CMD_CR }
*Command: CmdLF { *CallbackID: =CMD_LF }
*Command: CmdFF { *CallbackID: =CMD_FF }

*FontFormat: OEM_CALLBACK

------ END GPD FILE

The output of printing a sting of "aaaaaaaaaaaaaa" from word through
my shell driver is a file containing about 1000 '\0' characters. If I
change the Move Absolute Commands to:

*Command: CmdXMoveAbsolute { *Cmd : %d{ DestX } "X " }
*Command: CmdYMoveAbsolute { *Cmd : %d{ DestY } "Y " }

Then the NULL characters disappear and I get the expected "..X" and
"..Y", however this is obviously not what I want.

> - The sizLogResPpi member in FONTOBJ only specifies the resolution of the
> device for which the font has been realized. It doesn't specify the dpi of
> the font itself. Unidrv's private PDEV has two separate POINTL members
> named ptGrxRes and ptTextRes. These are filled based on what you specify in
> the GPD. So from what I can see in the code, *TextDPI is not ignored even
> if you implement the font callbacks. I think you are interpreting the
> meaning of sizLogResPpi incorrectly.

Turns out that I misrepresented the problem. I think the problem is
that when (*TextDPI != *DPI) then Unidrv follows a different code path
so that DownloadCharGlyph() is never called.

When they are equal I see the following code path for text (with my
responses):

TTDownloadMethod() call: I set *pdwResult = TTDOWNLOAD_TTOUTLINE and
return S_OK;
DownloadFontHeader() call: I set *pdwResult = 1 and return S_OK;
DownloadCharGlyph() call: By calling UFO_GETINFO_FONTOBJ I can get the
glyph bitmap and it is correct. I then set *pdwResult=1 and return
S_OK;
OutputCharStr() call: I return S_OK;

However if *TextDPI != *DPI I just get the TTDownloadMethod() call,
and no matter what I return I never get any subsequent calls. (Set DPI
to 200 and TextDPI to 400 with the above GPD file to reproduce).

Thanks for your help.

Hank Jones

Re: Using IPrintOemUni::ImageProcessing and soft fonts by ashwinn

ashwinn
Wed Aug 06 13:52:38 CDT 2003

------=_NextPart_0001_3AEDC248
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

What is the data size you are specifying for CmdSendBlockData? We recently
found a bug where Unidrv would emit incorrect data (which had a bunch of
NULL characters) when the data size specified here was 0. This problem
looks really close to the one you are experiencing.

As for your second question, it could very well be by design. But I need to
do some debugging in order to determine the root cause for the behavior you
are seeing. If this is a serious enough problem for you that you want us to
investigate this further, I suggest that you open a support incident with
us. If it does turn out to be a bug, you will not be charged for the
incident. You can find support options at
http://support.microsoft.com/default.aspx?scid=fh;en-us;Prodoffer11a.

- Ashwin

This posting is provided "AS IS" with no warranties, and confers no rights.

------=_NextPart_0001_3AEDC248
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 What is the data size you are specifying for CmdSendBlockData? We recently found a bug where Unidrv would emit incorrect data (which had a bunch of NULL characters) when the data size specified here was 0. This problem looks really close to the one you are experiencing.
\par
\par As for your second question, it could very well be by design. But I need to do some debugging in order to determine the root cause for the behavior you are seeing. If this is a serious enough problem for you that you want us to investigate this further, I suggest that you open a support incident with us. If it does turn out to be a bug, you will not be charged for the incident. You can find support options at http://support.microsoft.com/default.aspx?scid=fh;en-us;Prodoffer11a.
\par
\par - Ashwin
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par
\par }
------=_NextPart_0001_3AEDC248--