wineps: Handle EMR_EXTTEXTOUTW record in spool files.
Merge request reports
Activity
requested review from @huw
1749 1803 return NULL; 1750 1804 } 1751 1805 data->pdev->dev.hdc = hdc; 1806 data->pdev->dev.next = &data->font_dev; 1807 data->font_dev.funcs = &font_funcs; 1808 data->font_dev.hdc = hdc; This is temporary, it's needed so e.g. following code can work while we still use wine_get_gdi_driver:
dev = GET_NEXT_PHYSDEV( dev, pGetTextMetrics ); return dev->funcs->pGetTextMetrics( dev, metrics );
After
wine_get_gdi_driver
path is removed, the code will be changed to:return GetTextMetricsW(dev->hdc, metrics);
(and
font_GetTextMetrics
will be removed, note that dev->hdc points to memory DC in this case).The alternative is to change the callers to something like:
if (dev.next) //we can mark what path is used in PSDRV_DEVICE to make it more explicit { dev = GET_NEXT_PHYSDEV( dev, pGetTextMetrics ); return dev->funcs->pGetTextMetrics( dev, metrics ); } else { return GetTextMetricsW(dev->hdc, metrics); }
I'm not sure if it answers your question. I was thinking that the plan is to implement small parts of user-mode DDI so the driver interface is not on the unix side. I was already doing some tests regarding how it's done for GetDeviceCaps call (and it's basically a matter of copying the caps to structure supplied by GDI). I guess it will be harder for device font related functions. If we end with some other solution this part may need to be changed.
Ok, if it's temporary that's of course fine.
I was hoping we could eliminate the
GetTextMetrics()
/GetTextExtentPointW()
calls at some point, since we always have the offset array in the EMF and we could likely do something on the gdi side to deal with the vertical case.Edited by Huw Davies