Not set dc_top should not affect printing failed
From: liuchenghao linkmecry@gmail.com
--- dlls/wineps.drv/printproc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/wineps.drv/printproc.c b/dlls/wineps.drv/printproc.c index 34b3ec897a4..7f572e0770c 100644 --- a/dlls/wineps.drv/printproc.c +++ b/dlls/wineps.drv/printproc.c @@ -2287,7 +2287,7 @@ static int WINAPI hmf_proc(HDC hdc, HANDLETABLE *htable, PSDRV_SetTextColor(data->ctx, GetTextColor(hdc));
if (p->iRelative >= 0 || data->saved_dc_top + p->iRelative < 0) - return 0; + return ret; data->saved_dc_top += p->iRelative; data->break_extra = data->saved_dc[data->saved_dc_top].break_extra; data->break_rem = data->saved_dc[data->saved_dc_top].break_rem;
What are the values of `p->iRelative` and `data->saved_dc_top` when the condition fails and what is the sequence of `EMR_SAVEDC` / `EMR_RESTOREDC` records that leads to that?
p->iRelative = -1,data->saved_dc_top = 0 when the condition fails
When the error is only EMR_RESTOREDC
When the error is only EMR_RESTOREDC
I'm struggling to see how a `EMR_RESTOREDC` record could get written without a preceeding `EMR_SAVEDC` - that looks like the real bug.
Because I print two pages in a row, has been received EMR_SAVEDC->EMR_RESTOREDC->EMR_RESTOREDC
I'm struggling to see how a `EMR_RESTOREDC` record could get written without a preceeding `EMR_SAVEDC` - that looks like the real bug.
FWIW, most of EMF recording happens before state validation that would be required for skipping the buggy report. I don't remember if I checked this particular case, but I tested a number of similar cases and Windows usually both returns an error and records the buggy call. AFAICS, the same will happen on Wine if application does an extra unmatched RestoreDC call. For example, commit 972cfaca1fd58bf399e033ee0b576e789404797a shows that that's how path functions work.
I printing two page, when viewed from the code to print the first page of the saved_dc_top = iRelative, saved_dc_top to 0, so in the second page of the print time failed
In continuous printing, printing the second page didn't receive the EMR_SAVEDC only received a EMR_RESTOREDC
What is the app actually doing? Could you map out the calls it makes to `SaveDC()`, `RestoreDC()` as well as `{Start,End}Doc()` and `{Start,End}Page()` ?
On Wed Jun 28 02:03:33 2023 +0000, Huw Davies wrote:
What is the app actually doing? Could you map out the calls it makes to `SaveDC()`, `RestoreDC()` as well as `{Start,End}Doc()` and `{Start,End}Page()` ?
Here are three consecutive I print page the complete process, can be a little longer. StratDocPrinterW->StartPagerPinter->EndPagePrinter->StartPagerPinter->EndPagePrinter->StartPagerPinter->EndPagePrinter->EndDocPrinterW->StartDocPrinterW->EnumEnhMetaFile->SaveDC->SaveDC->RestoreDC->RestoreDC->SaveDC->EnumEnhMetaFile->RestoreDC->fail
Huw Davies (@huw) gitlab@winehq.org 于2023年6月27日周二 08:55写道:
On Wed Jun 28 02:17:28 2023 +0000, 张顾在 wrote:
Here are three consecutive I print page the complete process, can be a little longer. StratDocPrinterW->StartPagerPinter->EndPagePrinter->StartPagerPinter->EndPagePrinter->StartPagerPinter->EndPagePrinter->EndDocPrinterW->StartDocPrinterW->EnumEnhMetaFile->SaveDC->SaveDC->RestoreDC->RestoreDC->SaveDC->EnumEnhMetaFile->RestoreDC->fail At last, the printer output only a page Huw Davies (@huw) gitlab@winehq.org 于2023年6月27日周二 08:55写道:
Some of these look more like the calls that Wine is making internally (e.g. `StartDocPrinterW()` doesn't tend to get called by applications directly). Is this really the case here?
Perhaps an easier question to ask is could you write a simple test that demontrates the issue (ideally as part of Wine's test suite, but a stand-alone program would also be ok)?