I'm having trouble printing using CUPS. When I try and print in notepad
I get a dialog saying:
Cannot print the Untitled file. Be sure that your printer is connected
properly and use Control Panel to verify that the printer is configured
properly.
My setup is Redhat 7.3 with the following CUPS packages:
cups-libs-1.1.14-15
cups-drivers-hpijs-1.1-0.20020313.3
cups-devel-1.1.14-15
cups-drivers-pnm2ppa-1.1-0.20020313.3
cups-1.1.14-15
cups-drivers-1.1-0.20020313.3
I am printing to a HP Laserjet 1100 using the "HP LaserJet 1100,
Foomatic + gimp-print" driver. This is setup to print using IPP to a
print server that is also running CUPS(same version). I have not
modified any of the printing or fonts options in the wine config file,
since the instructions say it is automatic. I am printing from Notepad.
Doing a trace of the PSDRV, it reads all of the AFM files and detects
the fonts ok. Also, during ParsePPD it finds all of the paper sizes
correctly. But then I get a message:
trace:psdrv:PSDRV_FindPrinterInfo No 'Paper Size' for printer 'hplj1100'
trace:psdrv:PSDRV_FindPrinterInfo No 'FontSubTable' for printer
'hplj1100'
And then when it tries to print:
trace:psdrv:PSDRV_CreateDC (WINEPS hplj1100 LPT1: (nil))
trace:psdrv:PSDRV_UpdateDevCaps ImageableArea = 0,0 - 0,0: PageSize =
0x0
trace:psdrv:PSDRV_UpdateDevCaps devcaps: horzSize = -2147483648mm,
vertSize = -2147483648mm, horzRes = 0, vertRes = 0
Which doesn't seem right. It then selects the pen and brush, and looks
like it will print, and the it calls DeleteDC. I have attached the full
trace, with +psdrv and +commdlg.
It really seems like it is almost working, but something is wrong with
the paper size. How can I find why it sets everything up and then
deletes the DC? Anyone have any ideas?
Mason Kidd
Hi Jason,
I tried to compile your directx8 code.(try 3)
For now it doesn't compile, complaining about wine_gl.h.
Relevant part of 'make depend' log :
make[2]: Entre dans le répertoire `/home/wine/dlls/d3d8'
../../tools/makedep -I. -I. -I../../include -I../../include -C.
d3d8_main.c directx.c device.c resource.c vertexbuffer.c indexbuffer.c
volume.c swapchain.c surface.c basetexture.c texture.c cubetexture.c
volumetexture.c
wine_gl.h: No such file or directory
wine_gl.h was first included from d3d8_private.h:9
d3d8_private.h was first included from d3d8_main.c:25
Where could I find this file ? I have latest CVS and didn't find it.
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Hi folks,
As I was browsing aimlessly (not quite, but for the purpose of the
story, it'll do :)) through windows/win.c, I run into this:
/*******************************************************************
* GetWindowTextW (USER32.@)
*/
INT WINAPI GetWindowTextW( HWND hwnd, LPWSTR lpString, INT nMaxCount )
{
if (WIN_IsCurrentProcess( hwnd ))
return (INT)SendMessageW( hwnd, WM_GETTEXT, nMaxCount, (LPARAM)lpString );
/* when window belongs to other process, don't send a message */
if (nMaxCount <= 0) return 0;
get_server_window_text( hwnd, lpString, nMaxCount );
return strlenW(lpString);
}
My question is: shouldn't we alwas call WM_GETTEXT here, and do the
switch between current process/other process in the lower levels?
What if the application sends the WM_GETTEXT message, and bypasses
the GetWindowTextW? Then it wouldn't work, right? Just curious how
all these are gonna play out...
--
Dimi.
Anyone able to tell me what I am doing wrong here before I spend days trying
to figure it out?
My winelib wrapper wants to call MultiByteToWideChar and DOSFS_GetFullName.
As far as I am aware they are available from ntdll.dll (ntdll.dll.so)
So I want to to get the build to "link" to ntdll.dll
I thought it should simply require "-intdll" in the argument to winemaker,
but during the link I still get complaints about not finding those two
functions.
What am I doing wrong?
Bill
p.s. Thanks to Francois for the fixes to Winemaker
OK,
This DLL stuff is a bit confusing. In dlls/user/user32.spec we have
409 pascal16 InitThreadInput(word word) InitThreadInput16
so the exported name is InitThreadInput, right?
Then how come in ./dlls/x11drv/desktop.c we call it like so:
win->hmemTaskQ = InitThreadInput16( 0, 0 );
Shouldn't this yield an error?
--
Dimi.
Hi folks,
In my relentless quest for speed :), I discovered that we don't send
a WM_STYLECHANGED message when we flip the WS_VISIBLE, or WS_VSCROLL,
and maybe a bunch of others, I haven't checked.
Shouldn't we send such a message, when we touch *any* WS_[EX_]* bits?
--
Dimi.
OK, I did this:
Index: configure
===================================================================
RCS file: /home/wine/wine/configure,v
retrieving revision 1.341
diff -u -r1.341 configure
--- configure 25 Sep 2002 03:29:55 -0000 1.341
+++ configure 27 Sep 2002 15:20:40 -0000
@@ -1998,7 +1998,7 @@
CFLAGS=$ac_save_CFLAGS
elif test $ac_cv_prog_cc_g = yes; then
if test "$GCC" = yes; then
- CFLAGS="-g -O2"
+ CFLAGS="-gstabs -O2"
else
CFLAGS="-g"
fi
and sure enough, debug symbols loaded for me. The only
remaining annoyance: winedbg doesn't automagically find the
sources like gdb. Presumably, I can fix this by issuing "dir"
commands to winedbg. So I'm happy (although it'd be nice
to not have to issue those "dir" commands). Thanks!
Can anyone think of a reason not to submit this as a patch?
I tried -gstabs in gcc 2.96 (the only other gcc readily available
to me) and it was happy, so presumably its pretty portable, and
it looks like the configure change above would only apply to gcc,
which seems like precisely the right thing to me.
Now one other question for y'all wine gurus out there:
I was looking for the alignment issue I mentioned before,
and it turns out not to be an "-malign=" problem like I was
suspecting. Instead, I was seeing "8 as alignment is
not supported" warnings from include/pshpack8.h:
# if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) || defined(_MSC_VER)
# pragma pack(8)
# warning "8 as alignment is not supported"
# elif !defined(RC_INVOKED)
# error "Adjusting the alignment is not supported with this compiler"
# endif
I don't understand, if the alignment isn't supported, why the
#pragma pack(8) is there...? Anyhow, since it looks like
everybody using gcc gets the same warning, it's probably not
a gcc3.2 bug... but I was wondering if anyone could clarify
what's going on, and whether this indicates a problem
in crypt32.dll.so (the affected wine dll).
Thanks for your patience and help,
-gmt
--
"Waiting periods are only a step. Registration is only a step.
The prohibition of private firearms is the goal."
-U.S. Attorney General Janet Reno, December 1993
Francois Gouget <fgouget(a)codeweavers.com> writes:
> However, looking for wine in bindir does not make sense:
> * I don't install the Winelib applications I compile using Winelib. So
> * I leave prefix to the default value: /usr/local
>
> * I always build my application using a Wine source tree. This means
> * that there is strictly nothing of interest in /usr/local/bin.
>
> * configure.ac goes to great length to figure out where wrc, winebuild
> * and *wine* are located. So at the end of configure.ac we know very
> * well what the path to wine is. It's '$WINE'.
There seems to be some confusion here. We have two very different
problems: one is how to make things work on the build machine, and one
is how to make things work when installed. configure can only detect
where things are on the build machine, but in general that's not the
right paths to put in the installed binaries. The installed stuff goes
in $(prefix), and I think it makes sense to expect that Wine itself
will be installed there too.
Note that in Wine wineapploader is only used for make install; running
from inside the tree is a different problem and is done by a different
script. I think winemaker should do the same thing.
--
Alexandre Julliard
julliard(a)winehq.com
Eric POUECH wrote...
> but I assume you double checked that more likely, aren't you using gcc 3.2
> by any chance ? if so, you need to force ELF symbol emission, not
> Dwarf II which became default in 3.2
Bingo. Guilty as charged. Thank you SO MUCH for this, I should have figured gcc3.2 was the culprit,
that thing is feisty! I'll take a look at whether I can find a generic solution to this and post a patch.
Now that you mention it, I think gcc3.2 has some other interesting warnings, something about
some alignment thingys not supported anymore (probably I just change "-m$X" to "-f$X" to fix),
I'll see about those too, could well be important...
-gmt
--
"Waiting periods are only a step. Registration is only a step.
The prohibition of private firearms is the goal."
-U.S. Attorney General Janet Reno, December 1993
