July 2001 - Wine-Devel - list.winehq.org

Re: Any use for glyph bounding boxes in printer driver?

by Travis Michielsen

--- Ian Pilcher <ian.pilcher(a)home.com> wrote: > Currently, the Wine PostScript driver stores the bounding box (xMin, > yMin, xMax, yMax) for every glyph in every font. This information is > not currently used, and I'd like to get rid of it. (Note: this is > distinct from the advance width of each glyph, which is certainly > required.) > > From what I can tell, there is no API that a Win32 application or the > Windows GDI can use to get this information from a printer driver. > Since I'm not that familiar with either, however, I figure I should try > to confirm that this is indeed the case. > > So, does anyone know of any API that an application or the GDI can use > to get the dimensions of an individual glyph from a "real" Windows > printer driver? (I have verified that calling the GetTextExtentPoint > functions with a one-character string returns the height of the font, > not the height of the glyph. For example, it returns the same height > for 'A' and '_'.) > > Thanks! > -- > ======================================================================== > Ian Pilcher ian.pilcher(a)home.com > ======================================================================== > What about GetCharABCWidth* what does this function use? (or could it use this?) I see the function still shows a fixme (or atleast the last time I checked). - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

July 27, 2001

Re: Dose wine people hate Solaris?

by Francois Gouget

On Thu, 26 Jul 2001, EriK W wrote: > > What does not work? Do you have unicode/libwine_unicode.so or not? > > Does the following command run or does it say it cannot find > > libwine_unicode.so? > > > I does have the libwine_unicode.so > but it just don't go to ~unicode directory to search for it, it always > report " can't find it in /usr/local/lib" I don't know why, I am using bash, > so I just simply copied libwine_unicode.so over to make it happy. I was wondering if it was the shell not exporting the environment variable or something. Since you're using bash it should be all fine. So you have to figure out why setting LD_LIBRARY_PATH does not work. It's supposed to work. I'm 99.9% sure I did use it on Sparc Solaris so I really don't see why it would not work on Solaris x86. Plus LD_LIBRARY_PATH is such an important thing that it would be very surprising if it really did not work and nothing else was broken in your system. Did you try specifying an absolute path like: LD_LIBRARY_PATH=/export/home/system/wine-20010629/unicode ./tools/winebuild/winebuild What does 'echo $LD_LIBRARY_PATH' normally say? Is it empty? [...] > take it out? > Can I do that by commenting " > LIBPROGRAMS = \ > debugger/winedbg" ? The following patch should do that nicely: --- cut here --- Index: Makefile.in =================================================================== RCS file: /home/wine/wine/debugger/Makefile.in,v retrieving revision 1.24 diff -u -r1.24 Makefile.in --- Makefile.in 2000/12/29 05:38:00 1.24 +++ Makefile.in 2001/07/27 01:39:15 @@ -3,7 +3,7 @@ TOPOBJDIR = .. SRCDIR = @srcdir@ VPATH = @srcdir@ -MODULE = winedbg +MODULE = #winedbg C_SRCS = \ break.c \ --- Makefile.orig Thu Jul 26 19:03:36 2001 +++ Makefile Thu Jul 26 19:00:53 2001 @@ -3,7 +3,7 @@ TOPSRCDIR = .. TOPOBJDIR = .. SRCDIR = . -MODULE = winedbg +MODULE = #winedbg C_SRCS = \ break.c \ --- cut here --- -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

July 27, 2001

Re: Dose wine people hate Solaris?

by EriK W

> What does not work? Do you have unicode/libwine_unicode.so or not? > Does the following command run or does it say it cannot find > libwine_unicode.so? > I does have the libwine_unicode.so but it just don't go to ~unicode directory to search for it, it always report " can't find it in /usr/local/lib" I don't know why, I am using bash, so I just simply copied libwine_unicode.so over to make it happy. > > [...] > > gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou > > ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o > On my system r_debug is defined in '/usr/include/link.h'. According > to dpkg this is part of libc6-dev. So the problem is that the Solaris C > library does not define it. The link.h header says: > > Data structure for communication from the run-time dynamic linker for > loaded ELF shared objects. > > The easy way out is to say that winedbg is not essential to get > Wine working. So you could decide not to compile it at all. take it out? Can I do that by commenting " LIBPROGRAMS = \ debugger/winedbg" ? > A better approach would be to either provide this r_debug structure > somehow if it is relevant on Solaris, or remove all the related stuff on > Solaris. I'm not a winedbg expert so I've reached my limit here. Maybe > Eric Pouech could advise you better. OK, then I think I probably should be a quite beaver to sit and wait Eric Pouech to figure it out. :) Millions thanks, Francois!! > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

July 27, 2001

RE: winapi update

by Francois Gouget

On Fri, 27 Jul 2001, Patrik Stridvall wrote: [...] > PS. It filters the make messages and only display important messages. Ah, ok. I tried it. The first run gave me a number of errors: $ ./tools/winapi/make_filter make Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in pattern match (m//) at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in concatenation (.) or string at tools/winapi/make_parser.pm line 30, <IN> line 1. make_filter: : can't parse output: 'Make.rules.in is newer than Make.rules, please rerun ./configure!' Would it be possible to have the messages pass through as-is when they are not recognized (with the current directory for context)? So I ran ./configure and tried again and it was much better. What is a bit strange is that it did not leave a single message around. A third run on a file that I know generates a warning gave me the following: $ ./tools/winapi/make_filter make make_filter: gcc: can't parse output: 'd3ddevice/mesa.c:817: warning: unused variable `xvis'' It looks like there's an incompatibility with colorgcc. Colorgcc is a perl script that you can wrap around gcc and g++ and which colorizes the resulting output. So warnings appear in yellow, errors in red, some other items in cyan, ... It works pretty well as long as your xterm background is black like in the latest Debian. To use colorgcc you simply add symlinks to colorgcc in your path: $ ll /usr/local/bin/gcc /usr/local/bin/g++ lrwxrwxrwx 1 root staff 17 Apr 27 12:37 /usr/local/bin/g++ -> /usr/bin/colorgcc* lrwxrwxrwx 1 root staff 17 Apr 27 12:37 /usr/local/bin/gcc -> /usr/bin/colorgcc* So it must be the controls characters added by colorgcc that confuse make_filter. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

July 27, 2001

Re: Dose wine people hate Solaris?

by Francois Gouget

On Thu, 26 Jul 2001, EriK W wrote: > > The only message I see from you is the one you posted on wine-devel > > the 24th, two *days* ago. > > Actually, before this I posted it to comp.emulators-windows.wine couple > times without even a reply. :) Yes, I suspected as much. I sometimes read cemw but my ISPs news server is real bad. Not as bad as the news feed of Corel who's hosting wine-users. It's been over a month now that the link between wine-users and cemw has been severed :-( [...] > > winebuild is linked with 'libwine_unicode.so' which should have been > > compiled previously and should be in 'wine/unicode'. So the > > LD_LIBRARY_PATH setting seems correct and yet it seems winebuild cannot > > execute because that library cannot be found. > > So: > > * does unicode/libwine_unicode.so exist? > > * in the compilation process you should see Wine go into the unicode > > subdirectory and compile stuff there. Do you indeed see something like > > that? > > * try to start winebuild manually. When in Wine's root directory type > > "./tools/winebuild/winebuild'. Does it work? If not try to tweak > > LD_LIBRARY_PATH to get it to work. Maybe absolute paths work better than > > relative ones? > Doesn't work, I guess there is a problem in Makefile. What does not work? Do you have unicode/libwine_unicode.so or not? Does the following command run or does it say it cannot find libwine_unicode.so? LD_LIBRARY_PATH="unicode:$LD_LIBRARY_PATH" ./tools/winebuild/winebuild Btw, what is your default shell? [...] > gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou > ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o > stabs.c > stabs.c:1271: warning: `struct r_debug' declared inside parameter list > stabs.c:1271: warning: its scope is only this definition or declaration, > which is probably not what you want. On my system r_debug is defined in '/usr/include/link.h'. According to dpkg this is part of libc6-dev. So the problem is that the Solaris C library does not define it. The link.h header says: Data structure for communication from the run-time dynamic linker for loaded ELF shared objects. The easy way out is to say that winedbg is not essential to get Wine working. So you could decide not to compile it at all. A better approach would be to either provide this r_debug structure somehow if it is relevant on Solaris, or remove all the related stuff on Solaris. I'm not a winedbg expert so I've reached my limit here. Maybe Eric Pouech could advise you better. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

July 26, 2001

RE: Even more misc fixes

by Patrik Stridvall

> [...] > > > Most of these are because of the transition to making > HANDLE a void* > > > and compiling with STRICT. > > > > Yes, I notice this was the case with TIMERPROC casts. > > However it is no so with the HOOKPROC casts, > > and yes it is the same with the real Windows headers. > > ??? > AFAICS there are two versions of HOOKPROC: one for -DSTRICT and a > FARPROC one. Hmm. I looked again and it seems you are right. Must have missed it somehow. Strange. > [...] > > But OK I will try and compile with -DSTRICT and see what happends. > > IIRC somebody tried that but it didn't turn out so well. > > That would be me, probably. I started the conversion to -DSTRICT but > then other priorities came up and now it's on the back burner. I will > get back to it eventually but at the current rate it's hard > to know when > that will be :-( > Compiling with -DSTRICT is not that bad: with a relatively simple > patch it compiles (see attachement). Or at least, it used to. > But there > are tons of warnings, which means tons of places that need > attention and > possibly fixing. That's where the work is. OK. Will look at it later.

July 26, 2001

RE: winapi update

by Patrik Stridvall

> Btw, what does make filter do? > > Your post to wine-patches says it's nice an all but it does not say > what it does. Try and run it it is self describing. :-) Since Alexandre didn't apply the Makefile patch, running it is a little awkwark. Will fix that it later versions though. Try do: cd wine ./tools/winapi/make_filter make You can also give it parameters like ./tools/winapi/make_filter make clean Warning "make clean" doesn't look that good currently. PS. It filters the make messages and only display important messages. It might not always work 100% though, but I will fix problems as I find them. I wrote it many months ago and have run it from time to time since, so most issues have been fixed. The reason I wrote it was that I was irritated that important messages scrolled of screen. > If it's nice isn't it worth advertising to the Wine > developper community? I had intended to do that if but since I was unsure that Alexandre would apply my Makefile patch I decided to wait until it could present a better "user interface". But by all means test it.

July 26, 2001

RE: Even more misc fixes

by Francois Gouget

On Fri, 27 Jul 2001, Patrik Stridvall wrote: [...] > > The volatile stuff in dplay.h is part of the Windows header, you > > cannot remove it. > > No it isn't. I'm not sure why it was added in the first place. I don't have it in my VC6 headers either. But it may be in some more recent DirectX headers (7 or 8). [...] > > Most of these are because of the transition to making HANDLE a void* > > and compiling with STRICT. > > Yes, I notice this was the case with TIMERPROC casts. > However it is no so with the HOOKPROC casts, > and yes it is the same with the real Windows headers. ??? AFAICS there are two versions of HOOKPROC: one for -DSTRICT and a FARPROC one. [...] > But OK I will try and compile with -DSTRICT and see what happends. > IIRC somebody tried that but it didn't turn out so well. That would be me, probably. I started the conversion to -DSTRICT but then other priorities came up and now it's on the back burner. I will get back to it eventually but at the current rate it's hard to know when that will be :-( Compiling with -DSTRICT is not that bad: with a relatively simple patch it compiles (see attachement). Or at least, it used to. But there are tons of warnings, which means tons of places that need attention and possibly fixing. That's where the work is. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

July 26, 2001

RE: Even more misc fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No it isn't. I'm not sure why it was added in the first place. > > It is neither used by Wine, nor defined by Windows. > > It is in the Windows headers I have. It is not in my Microsoft Visual C++ 6.0 header, but perhaps you have a newer version? DPlay using volatile seems a little strange, so I thought is was wrong especially since it was not in my version, but then I have seen stranger things. :-) > > As you wish, but as I said HOOKPROC can't be fixed with STRICT. > > Why not? Because it would be incompatible (warning wise) with Winelib applications compile with -DSTRICT since Windows doesn't provide a special -DSTRICT version of HOOKPROC. The application might pass a FARPROC to it and expect it to work. Well, of course it works but it would generate a warning.

July 26, 2001

Re: winapi update

by Francois Gouget

On 26 Jul 2001, Alexandre Julliard wrote: > Patrik Stridvall <ps(a)leissner.se> writes: > > > The make_filter.diff patch is quite nice. > > > > Try it after applying it with by running: > > make filter > > I'm not sure about the portability of the wildcard rule. Why don't you > have make_filter call make instead of the other way around? This > would avoid the need for changing the makefiles at all. Btw, what does make filter do? Your post to wine-patches says it's nice an all but it does not say what it does. If it's nice isn't it worth advertising to the Wine developper community? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

July 26, 2001