- Wine-Devel - list.winehq.org

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

July 15, 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

Re: Handling X errors using exception handlers
by Alexandre Julliard July 15, 2001

July 15, 2001

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > When discussing with Ove yesterday on #WineHQ about the handling of X > errors, he told me about an idea of his : using exceptions to handle X > errors. The main problem with that is that I don't think you can jump out of Xlib without corrupting its state. Also you'd need to properly unlock the tsx11 lock in case of exception, which will probably require an finally handler around each X call. My idea was to have the following two functions: void X11DRV_expect_error( unsigned char request, unsigned char error, XID id ); int X11DRV_check_error(void); You'd call X11DRV_expect_error before doing an X call that can fail; then if an X error happens that matches what you expect, the X error handler will simply set a flag and ignore the error (if it doesn't match you get the standard error handling). Then after the call you use X11DRV_check_error to see if your error happened or not. Would this work for what you need? -- Alexandre Julliard julliard(a)winehq.com

2 1

Wine freshman class
by Paul Gaynor July 15, 2001

July 15, 2001

Hi, I am new to the development of wine, part of the wine freshman class :) I am really interested in developing wine for use with OpenGL hopefully to push the performance of the 3-D to window$ level. I am interested in making a striped build that just handles OpenGL strictly for gaming. Any pointers that any of you can give to get me started on my journey would be wonderfully appreciated. :) How much Win$/Linux programming experience is needed with the various tasks associated with developing wine? What are the different areas (and how much programming) is required for each task of developing wine? What do you think a good place for a beginning programmer/ developer to start? I am very excited that this group exists and I am looking forward to hacking on wine :) Paul Gaynor gpk2(a)uswest.net

2 1

re: small named pipe patch
by Mike McCormack July 14, 2001

July 14, 2001

Hi Ove, funny that, i had the same problems with install shield and thought about the same solution... but i don't know enough about COM to make it work. i'll have a go at implementing WaitForNamedPipe... it'd be great to have an interprocess COM implementation :-) Mike > I'm planning to use named pipes to implement a basic interprocess COM, to > support the stupid InstallShield v6 under Wine, so it would be nice if > they could be implemented fully (would e.g. be nice if someone implemented > WaitForNamedPipe for me, and things like that). > > (Would that be a good idea?) ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Documentation fixes
by Alexandre Julliard July 14, 2001

July 14, 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*). > If you are not convinced now, you never will be. I think we agree on this one ;-) -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: implement SetCommState16 using SetCommState
by lawson_whitney＠juno.com July 14, 2001

July 14, 2001

On Sat, 14 Jul 2001, Mike McCormack wrote: > > quickly checked. > > ChangeLog: > Rewrite SetCommState16 to use SetCommState > Okay, if you get this, juno 1.49 finds no fault in this patch either. Lawson ---cut here--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Win95 version fix
by Francois Gouget July 14, 2001

July 14, 2001

Hi, Bob Goodwin proposes the following change to misc/version.c as a fix for bug #232 (http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=232) --- cut here --- Index: misc/version.c =================================================================== RCS file: /home/wine/wine/misc/version.c,v retrieving revision 1.43 diff -u -r1.43 version.c --- misc/version.c 2001/07/02 19:59:49 1.43 +++ misc/version.c 2001/07/14 20:58:49 @@ -75,7 +75,7 @@ }, /* WIN95 */ { - 0x07005F03, + 0x07000304, 0xC0000004, { sizeof(OSVERSIONINFOA), 4, 0, 0x40003B6, --- cut here --- Note that the previous value for Win95 was the same as that for Win98 which is a bit strange. Can someone check the value proposed by Bob Goodwin? Or alternately, how would I check it myself? I have access to Win95/98/2000/Me so I could also check the value for Win2000 and even add one for Wine Me. Btw, if someone needs to check values for one of the above platforms and you can provide me with a simple test program, just let me know. I can probably help you. Of course, the simpler the program is to execute, the more likely I am to be able to help you. I can also accept source (Win32) so you can develop the test program with Winelib and just send me the source, I'll recompile it on Windows. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

1 0

RE: Documentation fixes
by Patrik Stridvall July 14, 2001

July 14, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > However I'm a little curious where the documentation, > > and yes I'm talking about real documentation not just > > the external name and the ordinal, should be placed. > > Sure you have the underlying Unix man pages at least > > if we are talking about the MSVCRT and NTDLL functions, > > but it would be nice to have a proper Windows style > > man page for them eventually. > > Given that nobody is writing documention for the Windows functions > anyway, I don't think the documentation of standard C library > functions is an issue at all. Well, lack of people writing documentation is a problem in most open source projects and Wine doesn't seem to be an exception. However, denying people the possiblity to do so for some functions doesn't help either. > > I can't fix winapi_check properly. I can kludge it yes, but fix no. > > Your proposed solution is not fixing it either, it's just moving the > kludge from winapi_check directly into the source. And that's not a > good thing IMO. 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. Of course you can always argue that it is a solution searching for a problem, but that is not a what I would call a kludge. Anyway, arguing about misuse of words is a waste of time and I don't think I have anything more to add that are likely to convince you. If you are not convinced now, you never will be.

1 0

Re: Documentation fixes
by Alexandre Julliard July 14, 2001

July 14, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > However I'm a little curious where the documentation, > and yes I'm talking about real documentation not just > the external name and the ordinal, should be placed. > Sure you have the underlying Unix man pages at least > if we are talking about the MSVCRT and NTDLL functions, > but it would be nice to have a proper Windows style > man page for them eventually. Given that nobody is writing documention for the Windows functions anyway, I don't think the documentation of standard C library functions is an issue at all. > I can't fix winapi_check properly. I can kludge it yes, but fix no. Your proposed solution is not fixing it either, it's just moving the kludge from winapi_check directly into the source. And that's not a good thing IMO. -- Alexandre Julliard julliard(a)winehq.com

1 0