Skip to content
Snippets Groups Projects

wineps: Handle EMR_EXTTEXTOUTW record in spool files.

Merged Piotr Caban requested to merge piotr/wine:wineps into master
1 unresolved thread

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
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;
  • Comment on lines +1806 to +1808

    What's the plan with this - how does this work when we switch the driver interface to the unix-side?

  • Author Developer

    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
  • Author Developer

    It's not really important since we don't create such records but there's EMR_SMALLTEXTOUT record that is similar to EMR_EXTTEXTOUT but doesn't contain the offsets.

  • Yeah, I think we can ignore that (for now at least) since, as you say, we don't create it.

  • Please register or sign in to reply
  • Piotr Caban marked this merge request as ready

    marked this merge request as ready

  • Huw Davies approved this merge request

    approved this merge request

  • Alexandre Julliard approved this merge request

    approved this merge request

  • Please register or sign in to reply
    Loading