- Wine-Devel - list.winehq.org

DrawText
by Travis Michielsen July 17, 2001

July 17, 2001

Hi all, I have put together a quick patch that SHOULD fully implement the DrawText functions. However, I have not had time to thoroughly tested most of the logic so I thought I would post it here rather than sending it directly to the patches list. I welcome any/all comments/suggestions. - Travis Michielsen Index: wine/dlls/user/text.c =================================================================== RCS file: /home/wine/wine/dlls/user/text.c,v retrieving revision 1.12 diff -u -r1.12 text.c --- wine/dlls/user/text.c 2001/07/17 00:51:00 1.12 +++ wine/dlls/user/text.c 2001/07/17 13:55:22 @@ -235,6 +235,7 @@ int prefix_x = 0; int prefix_end = 0; TEXTMETRICW tm; + int lmargin = 0, rmargin = 0; int x = rect->left, y = rect->top; int width = rect->right - rect->left; int max_width = 0; @@ -242,10 +243,8 @@ TRACE("%s, %d , [(%d,%d),(%d,%d)]\n", debugstr_wn (str, count), count, rect->left, rect->top, rect->right, rect->bottom); - if(dtp) { - FIXME("Ignores params:%d,%d,%d,%d\n", dtp->cbSize, - dtp->iTabLength, dtp->iLeftMargin, dtp->iRightMargin); - } + if (dtp) TRACE("Params: iTabLength=%d, iLeftMargin=%d, iRightMargin=%d\n", + dtp->iTabLength, dtp->iLeftMargin, dtp->iRightMargin); if (!str) return 0; if (count == -1) count = strlenW(str); @@ -258,8 +257,17 @@ else lh = tm.tmHeight; + if (dtp) + { + lmargin = dtp->iLeftMargin * tm.tmAveCharWidth; + rmargin = dtp->iRightMargin * tm.tmAveCharWidth; + if (!(flags & (DT_CENTER | DT_RIGHT))) + x += lmargin; + dtp->uiLengthDrawn = 0; //This param RECEIVES number of chars processed + } + if (flags & DT_TABSTOP) - tabstop = flags >> 8; + tabstop = dtp ? dtp->iTabLength : flags >> 8; if (flags & DT_EXPANDTABS) { @@ -292,7 +300,7 @@ if (flags & DT_SINGLELINE) { - if (flags & DT_VCENTER) y = rect->top + + if (flags & DT_VCENTER) y = rect->top + (rect->bottom - rect->top) / 2 - size.cy / 2; else if (flags & DT_BOTTOM) y = rect->bottom - size.cy; @@ -312,7 +320,7 @@ if (flags & DT_WORD_ELLIPSIS) flags |= DT_WORDBREAK; - if (flags & DT_PATH_ELLIPSIS) + if (flags & DT_PATH_ELLIPSIS) { WCHAR* lastBkSlash = NULL; WCHAR* lastFwdSlash = NULL; @@ -320,14 +328,11 @@ line[totalLen] = '\0'; lastBkSlash = strrchrW(line, BACK_SLASHW[0]); lastFwdSlash = strrchrW(line, FORWARD_SLASHW[0]); - fnameDelim = lastFwdSlash ? lastFwdSlash : lastBkSlash; - if (lastBkSlash && lastFwdSlash) /* which is last? */ - if (lastBkSlash > lastFwdSlash) - fnameDelim = lastBkSlash; + fnameDelim = lastBkSlash > lastFwdSlash ? lastBkSlash : lastFwdSlash; if (fnameDelim) fnameLen = &line[totalLen] - fnameDelim; - else + else fnameDelim = (WCHAR*)str; strcpyW(swapStr, ELLIPSISW); @@ -343,16 +348,16 @@ } len = MAX_STATIC_BUFFER; - TEXT_NextLineW(hdc, swapStr, &count, line, &len, width, flags); + TEXT_NextLineW(hdc, swapStr, &count, line, &len, width, flags); /* if only the ELLIPSIS will fit, just let it be clipped */ len = max(3, len); GetTextExtentPointW(hdc, line, len, &size); /* FIXME: - * NextLine uses GetTextExtentPoint for each character, + * NextLine uses GetTextExtentPoint for each character, * rather than GetCharABCWidth... So the whitespace between - * characters is ignored in the width measurement, and the + * characters is ignored in the width measurement, and the * reported len is too great. To compensate, we must get * the width of the entire line and adjust len accordingly. */ @@ -365,10 +370,10 @@ if (fnameLen < len-3) /* some of the path will fit */ { /* put the ELLIPSIS between the path and filename */ - strncpyW(swapStr, &line[fnameLen+3], len-3-fnameLen); + strncpyW(swapStr, &line[fnameLen+3], len-3-fnameLen); swapStr[len-3-fnameLen] = '\0'; - strcatW(swapStr, ELLIPSISW); - strncpyW(swapStr+strlenW(swapStr), &line[3], fnameLen); + strcatW(swapStr, ELLIPSISW); + strncpyW(swapStr+strlenW(swapStr), &line[3], fnameLen); } else { @@ -382,12 +387,15 @@ line[len] = '\0'; strPtr = NULL; } + if (flags & DT_MODIFYSTRING) + strcpyW(str, swapStr); } } if (!(flags & DT_CALCRECT)) { - if (!ExtTextOutW(hdc, x, y, (flags & DT_NOCLIP) ? 0 : ETO_CLIPPED, - rect, line, len, NULL )) return 0; + if (!ExtTextOutW( hdc, x, y, + ( (flags & DT_NOCLIP) ? 0 : ETO_CLIPPED ) | ( (flags & DT_RTLREADING) ? 0 : ETO_RTLREADING ), + rect, line, len, NULL )) return 0; if (prefix_offset != -1) { HPEN hpen = CreatePen( PS_SOLID, 1, GetTextColor(hdc) ); @@ -410,20 +418,35 @@ break; } } + if (dtp) + dtp->uiLengthDrawn += len; } while (strPtr); + if (flags & DT_CALCRECT) { rect->right = rect->left + max_width; rect->bottom = y; + if (dtp) + rect->right += lmargin + rmargin; } return y - rect->top; } /*********************************************************************** - * DrawTextA (USER32.@) + * DrawTextW (USER32.@) */ -INT WINAPI DrawTextA( HDC hdc, LPCSTR str, INT count, LPRECT rect, UINT flags ) +INT WINAPI DrawTextW( HDC hdc, LPCWSTR str, INT count, + LPRECT rect, UINT flags ) +{ + return DrawTextExW(hdc, str, count, rect, flags, NULL); +} + +/*********************************************************************** + * DrawTextExA (USER32.@) + */ +INT WINAPI DrawTextExA( HDC hdc, LPCSTR str, INT count, + LPRECT rect, UINT flags, LPDRAWTEXTPARAMS dtp ) { WCHAR *wstr; INT ret = 0; @@ -437,32 +460,19 @@ { MultiByteToWideChar( CP_ACP, 0, str, count, wstr, wcount ); ret = DrawTextExW( hdc, wstr, wcount, rect, flags, NULL ); + if (flags & DT_MODIFYSTRING) + WideCharToMultiByte( CP_ACP, 0, wstr, -1, str, count, NULL, NULL ); HeapFree(GetProcessHeap(), 0, wstr); } return ret; } /*********************************************************************** - * DrawTextW (USER32.@) - */ -INT WINAPI DrawTextW( HDC hdc, LPCWSTR str, INT count, - LPRECT rect, UINT flags ) -{ - return DrawTextExW(hdc, str, count, rect, flags, NULL); -} - -/*********************************************************************** - * DrawTextExA (USER32.@) + * DrawTextA (USER32.@) */ -INT WINAPI DrawTextExA( HDC hdc, LPCSTR str, INT count, - LPRECT rect, UINT flags, LPDRAWTEXTPARAMS dtp ) +INT WINAPI DrawTextA( HDC hdc, LPCSTR str, INT count, LPRECT rect, UINT flags ) { - TRACE("(%d,%s,%d,%p,0x%08x,%p)\n",hdc,debugstr_an(str,count),count,rect,flags,dtp); - if(dtp) { - FIXME("Ignores params:%d,%d,%d,%d\n",dtp->cbSize, - dtp->iTabLength,dtp->iLeftMargin,dtp->iRightMargin); - } - return DrawTextA(hdc,str,count,rect,flags); + return DrawTextExA( hdc, str, count, rect, flags, NULL ); } /*********************************************************************** __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

1 0

Re: another debugstr patch
by Alexandre Julliard July 17, 2001

July 17, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > BTW, Alexandre, why didn't you apply my "debugstr patch" from Jun 04 ? It got lost somewhere; I've applied it now. BTW for everybody, when you submitted a patch and didn't see it applied and didn't hear anything about it, *please* resubmit or ask me what's going on. Patches can get dropped for multiple reasons, and it's your responsibility to follow what happens to your patch, until it is either applied or you know why it wasn't. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Mouse trouble
by Alexandre Julliard July 17, 2001

July 17, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I did consider that, but who's going to intercept and handle that message? > It's not an operation that is or should be known outside of the x11drv, so > sending the window a custom message will either conflict with some other > message, or get the message ignored (I doubt DefWindowProc passes custom > messages back to x11drv or anything). Or did you have any particular ideas > in this area? You can set a new window procedure to intercept the message, and pass all other messages straight through to the original window procedure. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Mouse trouble
by Alexandre Julliard July 17, 2001

July 17, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Known bug in the current CVS. Turn dxgrab off. If it's on, mouse events > are lost. I'm working on it, but have not yet thought of a way to fix it; > I need to run a procedure (GrabPointer) in the context of the thread that > owns the window that gets the grab. My latest idea was to queue an APC to > the owner of the window, but QueueUserAPC requires a thread handle, while > GetWindowThreadProcessId only returns a thread ID. I'd strongly suggest using some kind of SendMessage instead of QueueUserAPC. -- Alexandre Julliard julliard(a)winehq.com

2 1

fnt2bdf.c and font names
by Bill Medland July 16, 2001

July 16, 2001

I've just been playing with fonts (sserife and vgasys) to get things working. In the process I notice that fnt2bdf seems to do some strange stuff about choosing a font name, pixel size etc. I don't want to submit a patch that merely demonstrates my stupidity/lack of understanding but am willing to put in my suggested fix. This will result in for example the MS Sans Serif 8 pt font getting a name of -windows-MS Sans Serif-medium-r-normal-sans-13-80-96-96-p-50-microsoft-cp1252 SIZE 8 96 96 as opposed to the current -windows-MS Sans Serif-medium-r-normal-sans-13-130-72-72-p-50-microsoft-cp1252 SIZE 13 96 96 (I don't understand why the 72 dpi is hard-coded) Do I submit it or am I misunderstanding something Bill

1 0

Re: Added sanity check to WINPROC_CallWndProc
by Uwe Bonnes July 16, 2001

July 16, 2001

>>>>> "Jukka" == Jukka Heinonen <jhei(a)iki.fi> writes: Jukka> DeusEx causes Wine to crash (segmentation fault) because it calls Jukka> CallWindowProc and passes null in HWND parameter. While I Jukka> suspect that this is because some Wine function that should Jukka> return a valid HWND is returning a null pointer, the crashing can Jukka> be fixed simply by adding a sanity check to WINPROC_CallWndProc. How does Windows behave on those invalid arguments? Jukka> After this patch, both DeusEx installer and DeusEx dialog for Jukka> choosing rendering engine work. However, DeusEx still crashes Jukka> later because DeusEx for some reason generates a division by zero Jukka> FP exception. DeusEx handler for this exception calls Jukka> __CxxFrameHandler which is not implemented by Wine and thus Jukka> exception handling ends into infinite recursion. Luckily stack Jukka> overflow makes Wine to crash :) Native msvcrt has __CxxFrameHandler, but I aggree that wine-msvcrt needs exception facilities too. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Mouse trouble
by Daniel Bingham July 16, 2001

July 16, 2001

Hi, I just got the latest CVS and when I tried to run starcraft my mouse won't move. I have dxgrab turned on so as not to have my mouse going off the screen when I try to move. I am not very knowledgeable about wine or programming, so I thought I'd tell someone who was. If I have something set up wrong I can't find it and don't find any documentation to address it either. Any help would be much appreciated. Please email me directly because I get the digest and tend to ignore it. Thanks. Daniel Bingham db78(a)att.net

3 2

Re: Added sanity check to WINPROC_CallWndProc
by Jon Griffiths July 16, 2001

July 16, 2001

Hi, >Native msvcrt has __CxxFrameHandler, but I aggree that wine-msvcrt needs >exception facilities too. While I'm still on holiday, i just bought a laptop to do some wine coding on. I had improved the exception handling in builtin msvcrt but my last run of patches to it werent accepted due to using asm instead of register funcs. Once I get my old sources mailed to me I will begin hacking on it again. I'm interested in getting the konqueror/ActiveX stuff working with builtin msvcrt, since the dot.kde.org press release singled it out as non-functional (much to my shame <g>). Meanwhile I'm strolling through shlwapi and should have some patches for that soon. Its great to see the progress made since february though, very impressive. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

1 0

Significant change to WINEPS - please test!
by Ian Pilcher July 16, 2001

July 16, 2001

The attached patch makes a fundamental change to the way the PostScript driver deals with character encodings -- it ignores them. Instead, the driver now operates directly on 16-bit Unicode characters. This should be a more robust strategy for handling non-Latin, and especially multi-byte, character sets. I really have no idea, however, how the rest of Wine handles non-Latin characters. As an English speaker, I'm not well equipped to test it. So please give me your feedback. I particularly want to know if it breaks anything before I submit it. Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ======================================================================== diff -urN ../wine-20010714cvs/dlls/wineps/font.c ./dlls/wineps/font.c --- ../wine-20010714cvs/dlls/wineps/font.c Sun Jul 15 16:07:36 2001 +++ ./dlls/wineps/font.c Sun Jul 15 16:27:27 2001 @@ -5,6 +5,7 @@ * */ #include <string.h> +#include <stdlib.h> /* for bsearch() */ #include "winspool.h" #include "psdrv.h" #include "debugtools.h" @@ -294,6 +295,7 @@ return TRUE; } +#if 0 /*********************************************************************** * PSDRV_UnicodeToANSI */ @@ -321,9 +323,52 @@ return 0xff; } } +#endif + +/****************************************************************************** + * PSDRV_UVMetrics + * + * Find the AFMMETRICS for a given UV. Returns first glyph in the font + * (space?) if the font does not have a glyph for the given UV. + */ +static int MetricsByUV(const void *a, const void *b) +{ + return (int)(((const AFMMETRICS *)a)->UV - ((const AFMMETRICS *)b)->UV); +} + +const AFMMETRICS *PSDRV_UVMetrics(LONG UV, const PSDRV_PDEVICE *physDev) +{ + AFMMETRICS key; + const AFMMETRICS *needle; + + /* + * Ugly work-around for symbol fonts. Wine is sending characters which + * belong in the Unicode private use range (U+F020 - U+F0FF) as ASCII + * characters (U+0020 - U+00FF). + */ + + if ((physDev->font.afm->Metrics->UV & 0xff00) == 0xf000 && UV < 0x100) + UV |= 0xf000; + + key.UV = UV; + + needle = bsearch(&key, physDev->font.afm->Metrics, + physDev->font.afm->NumofMetrics, sizeof(AFMMETRICS), + MetricsByUV); + + if (needle == NULL) + { + WARN("No glyph for U+%.4lX in %s\n", UV, physDev->font.afm->FontName); + needle = physDev->font.afm->Metrics; + } + + return needle; +} + /*********************************************************************** * PSDRV_GetTextExtentPoint */ +#if 0 BOOL PSDRV_GetTextExtentPoint( DC *dc, LPCWSTR str, INT count, LPSIZE size ) { @@ -346,11 +391,30 @@ return TRUE; } +#endif +BOOL PSDRV_GetTextExtentPoint(DC *dc, LPCWSTR str, INT count, LPSIZE size) +{ + PSDRV_PDEVICE *physDev = (PSDRV_PDEVICE *)dc->physDev; + int i; + float width = 0.0; + + for (i = 0; i < count && str[i] != '\0'; ++i) + width += PSDRV_UVMetrics(str[i], physDev)->WX; + + width *= physDev->font.scale; + + size->cx = GDI_ROUND((FLOAT)width * dc->xformVport2World.eM11); + size->cy = GDI_ROUND((FLOAT)physDev->font.tm.tmHeight * + dc->xformVport2World.eM22); + + return TRUE; +} /*********************************************************************** * PSDRV_GetCharWidth */ +#if 0 BOOL PSDRV_GetCharWidth( DC *dc, UINT firstChar, UINT lastChar, LPINT buffer ) { @@ -365,7 +429,24 @@ return TRUE; } +#endif +BOOL PSDRV_GetCharWidth(DC *dc, UINT firstChar, UINT lastChar, LPINT buffer) +{ + PSDRV_PDEVICE *physDev = (PSDRV_PDEVICE *)dc->physDev; + UINT i; + + if (lastChar > 0xffff || firstChar > lastChar) + { + SetLastError(ERROR_INVALID_PARAMETER); + return FALSE; + } + + for (i = firstChar; i < lastChar; ++i) + *buffer++ = PSDRV_UVMetrics(i, physDev)->WX * physDev->font.scale; + + return TRUE; +} /*********************************************************************** * PSDRV_SetFont diff -urN ../wine-20010714cvs/dlls/wineps/ps.c ./dlls/wineps/ps.c --- ../wine-20010714cvs/dlls/wineps/ps.c Sun Jul 15 16:07:36 2001 +++ ./dlls/wineps/ps.c Sun Jul 15 16:25:12 2001 @@ -115,6 +115,9 @@ static char psshow[] = /* string */ "(%s) show\n"; +static const char psglyphshow[] = /* glyph name */ +"/%s glyphshow\n"; + static char pssetfont[] = /* fontname, xscale, yscale, ascent, escapement */ "/%s findfont\n" "[%d 0 0 %d 0 0]\n" @@ -634,6 +637,7 @@ return TRUE; } +#if 0 BOOL PSDRV_WriteShow(DC *dc, LPCWSTR str, INT count) { char *buf, *buf1; @@ -671,6 +675,32 @@ return TRUE; } +#endif + +BOOL PSDRV_WriteShow(DC *dc, LPCWSTR str, INT count) +{ + char buf[128]; + int i; + + for (i = 0; i < count; ++i) + { + LPCSTR name; + int l; + + name = PSDRV_UVMetrics(str[i], (PSDRV_PDEVICE *)dc->physDev)->N->sz; + l = snprintf(buf, sizeof(buf), psglyphshow, name); + + if (l < sizeof(psglyphshow) - 2 || l > sizeof(buf) - 1) + { + WARN("Unusable glyph name '%s' - ignoring\n", name); + continue; + } + + PSDRV_WriteSpool(dc, buf, l); + } + + return TRUE; +} BOOL PSDRV_WriteFill(DC *dc) { diff -urN ../wine-20010714cvs/dlls/wineps/psdrv.h ./dlls/wineps/psdrv.h --- ../wine-20010714cvs/dlls/wineps/psdrv.h Tue May 29 17:06:11 2001 +++ ./dlls/wineps/psdrv.h Sun Jul 15 16:11:36 2001 @@ -421,6 +421,7 @@ GLYPHNAME *PSDRV_GlyphName(LPCSTR szName); VOID PSDRV_IndexGlyphList(); BOOL PSDRV_GetTrueTypeMetrics(); +const AFMMETRICS *PSDRV_UVMetrics(LONG UV, const PSDRV_PDEVICE *physDev); #endif

1 0

RE: Documentation fixes
by Patrik Stridvall July 15, 2001

July 15, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > What kludge? Ugly OK, that is your subjective opinion, but kludge? > > Even if we only see it from a purely C language perspective, > > it solves the problem of making sure that the C library functions > > have the prototypes we expect them to have. There is no other > > way to solve that problem that I can think of so it is certainly > > not a kludge. > > Not only is it not a problem we need to solve, but it's more likely to > actually cause new problems. I wouldn't be surprised at all if your > patch broke compile on some platforms that have some slight > differences in prototypes (like char* vs. const char*). Well, believe it or not the thought actually occured to me before I submitted the patch, so I actually tested it on Solaris, FreeBSD and Linux, and the only thing I had to change was the include order or stdarg.h to make it work on all platforms. The thing is that if it actually breaks on some platform it is a red light that something might be (and probably is) wrong. We can always fix it with #ifdef:s and winapi_{check,extract,fixup} or whatever can use the #ifdef to generate a correct entry for that platform if need be. Of course the more likely scenario will be that it serves as a reminder that we really can't export the C library function directly because of platform incompabillities and simply don't do it. And no, I don't believe const/non-const is a problem. Beside even if it turn out I'm wrong we can just add a "#define const /* nothing */" at the top of each externs.c file. That, I admit, is a kludge but only a very small and harmless one. > > If you are not convinced now, you never will be. > > I think we agree on this one ;-) Probably. I don't have much hope of convincing you with the statement above either.

1 0