[PATCH] winspool.drv: Fallback to the first found printer as default printer [try 2]
---
dlls/winspool.drv/info.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
Detlef Riekenberg wrote:
Sorry, I misinterpreted the Patch because of the subject.
I'm fine with your Patch, when you fix your typo:
+if (hadprinter !haddefault)
+WINSPOOL_SetDefaultPrinter(dests[0].name, dests[i].name, TRUE);
With greetings from Copy and Paste: [i] = [0]
For the subject, I suggest to include Fallback:
winspool.drv: Fallback to the first found printer as default printer
Thank you for your comments, and sorry for the typo and the ambiguous
subject…
- Pedro.
# [PATCH] winspool.drv: Fallback to the first found printer as default printer
---
dlls/winspool.drv/info.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c
index 822fde4..7ec5830 100644
--- a/dlls/winspool.drv/info.c
+++ b/dlls/winspool.drv/info.c
@@ -419,7 +419,7 @@ static void *cupshandle;
static BOOL CUPS_LoadPrinters(void)
{
int i, nrofdests;
-BOOL hadprinter = FALSE;
+BOOL hadprinter = FALSE, haddefault = FALSE;
cups_dest_t *dests;
PRINTER_INFO_2A pinfo2a;
char *port,*devline;
@@ -497,9 +497,13 @@ static BOOL CUPS_LoadPrinters(void)
HeapFree(GetProcessHeap(),0,port);
hadprinter = TRUE;
-if (dests[i].is_default)
+if (dests[i].is_default) {
WINSPOOL_SetDefaultPrinter(dests[i].name, dests[i].name, TRUE);
+haddefault = TRUE;
+}
}
+if (hadprinter !haddefault)
+WINSPOOL_SetDefaultPrinter(dests[0].name, dests[0].name, TRUE);
RegCloseKey(hkeyPrinters);
return hadprinter;
}
--
1.4.4.2
Re: [PATCH] WINSPOOL.DRV: Choose first printer found as the default
Detlef Riekenberg wrote: On Di, 2007-07-03 at 14:06 -0300, Pedro Araujo Chaves Jr. wrote: # [PATCH] WINSPOOL.DRV: Choose first printer found as the default Why do you think, that you need this? Different default Printers (CUPS and Wine) confuse most Users. Unless I'm mistaken: 1. The patch only sets a printer as the default if CUPS doesn't define one itself; 2. Windows always has a default printer, unless none is installed — of course, the user may change the default from Windows' first choice; 3. On Windows, if the default printer is deleted, another one is automatically assigned as default (and thus #2 above is always true); 4. This fixes bugs #8475 [1] and #8476 [2]. (Those two applications are kinda critical here in my company.) [1] http://bugs.winehq.org/show_bug.cgi?id=8475 [2] http://bugs.winehq.org/show_bug.cgi?id=8476 - Pedro. -- It is assumed that the reader is reasonably familiar with the dpkg System Administrator's manual. Unfortunately this manual does not yet exist. (Debian Packaging Manual)
Enforcing charset/codepage (was: Commit 37591409b28c2000e70bd0d3c654a3a7559a4a26 breaks accentuation)
Follow-up... I recall that forcing the charset to be ANSI_CHARSET instead of DEFAULT_CHARSET [1] fixed bug 7571 [2] here, and from that rose an idea: would it be possible to add an option to winecfg to enforce a particular charset/codepage, much like it is already done in web browsers? That way, we here wouldn't have to face 7571 while the fix isn't ready. Is such a thing acceptable? TIA, - Pedro. [1] http://www.winehq.org/pipermail/wine-patches/2007-March/036538.html [2] http://bugs.winehq.org/show_bug.cgi?id=7571 P.S.: TMTC, I'm still working on 7571; 7703's been taking a lot of my time...
Re: Regression in Lotus Notes R5 between wine-0.9.27 and wine-0.9.28
On 3/6/07, Alexandre Julliard [EMAIL PROTECTED] wrote: Try this patch: diff --git a/dlls/wineps.drv/init.c b/dlls/wineps.drv/init.c index bd9c16c..23b6cfd 100644 --- a/dlls/wineps.drv/init.c +++ b/dlls/wineps.drv/init.c Yeah, that dit it; thanks! Can I expect to see this in 0.9.33, then? Cheers, - Pedro.
Commit 37591409b28c2000e70bd0d3c654a3a7559a4a26 breaks accentuation
Hi all, After some regression testing, I found out that commit 37591409b28c2000e70bd0d3c654a3a7559a4a26 by Dmitry Timoshkov breaks accentuation - at least for Brazilian Portuguese in Lotus Notes R5. I did some testing and found out that only TrueType fonts are affected - that is, the fonts Notes lists as 'default foo' without the double-T icon are all accented properly. To make matters worse, the affected fonts don't behave the same way. For example, the string áéíóú ÁÉÍÓÚ àèìòù ÀÈÌÒÙ ãõ ÃÕ âêîôû ÂÊÎÔÛ äëïöü ÄËÏÖÜ renders as įéķóś ĮÉĶÓŚ ąčģņł ĄČĢŅŁ ćõ ĆÕ āźīōū ĀŹĪŌŪ äėļöü ÄĖĻÖÜ with Trebuchet MS. You can see they're pretty different - well, most of you, at least. However, that's only a display-and-print issue, as I can copy the text and paste it elsewhere, and the accents are in their right places (and in the right letters, for that matter) - as one would expect. Regarding Microsoft fonts, by the way, Calibri, Candara, Consolas, Constantia, Corbel, Segoe Print, and Segoe Script (couldn't test Cambria) all behave exactly like Trebuchet MS, whereas Segoe UI behaves just like Times New Roman, which shows problems only with graves and tildes. However the behavior is kinda random among the many other fonts (from many unrelated sources, of course) I tested, so I (still) didn't do an exhaustive check for a pattern. Would anybody have any word on this? Cheers, Pedro.
Re: Commit 37591409b28c2000e70bd0d3c654a3a7559a4a26 breaks accentuation
On 2/27/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Please open a bug report regarding this problem, with all the appropriate info: an aplication that shows the problem, the fonts used, etc. If you could add a test to the existing tests in the above mentioned commit that shows the problem that would be great. Been there, done that: http://bugs.winehq.org/show_bug.cgi?id=7571 In order to clarify things, please see the attachment: http://bugs.winehq.org/attachment.cgi?id=5133action=view There I provided links for many of the fonts I used (all legal, AFAIK). Cheers, Pedro.
Re: Bug 50
Hi all, I'm writing just to ask why my patch and test case for Bug 50 (the text justification issue) weren't committed yet, so that I can take the proper measures in order that they can be. Regards, Pedro.
Re: Test case for Bug 50 [Was: Bug 50]
I've just finished writing a test case for Bug 50, but I'm missing *a single thing* that prevents it from working under Windows: I still don't know how to get the width of the text output by ExtTextOutW(). MSDN isn't helping much, and I haven't found the optimal Google query yet... ;-) Would anybody out there have a clue? I'm ready to submit patch and test, but without that info, I can't... Thanks in advance! - Pedro.
Re: Test case for Bug 50 [Was: Bug 50]
On 2007-01-29, Duane Clark wrote: GetTextExtentPoint32 For some examples in Wine, look at almost any control in comctl32. I was afraid somebody would answer that... Thanks for the quick reply, but that isn't exactly what I need. Here's the picture: when an application calls TextOut() for printing text, the usual (at least in my case) call sequence in Wine is TextOut() TextOutA() ExtTextOutA() ExtTextOutW() (the one I patched) GetTextExtentPointW() GetTextExtentPoint32W() (the wide-char version of the one you mentioned) GetTextExtentExPointW() WineEngGetTextExtentExPoint() (the one that actually gets the individual character widths) That is, at some point, TextOut() indirectly uses GetTextExtentPoint32() to get the dimensions, okay. But what I need is to check the text width *after* it was output by TextOut() -- in other words, after the function has returned, to see if it output the text properly. In Wine, I tried the trick of making ExtTextOutW() return the said value, and the tests passed without a hitch, which means the text is being properly justified. The problem is that such is not an acceptable way of doing things, and, to use Dan Kegel's words, that is not going to fly on Windows. To be a bit clearer, in my tests I do call GetTextExtent32() in order to compute the remaining white space for the justification part, and what I want to check is whether TextOut() understood it right or not. - Pedro.
Re: Test case for Bug 50 [Was: Bug 50]
Update... I thought I had managed to get Keith's idea and make up a patch, but, to great grief -- and not so great a surprise --, I have just discovered that my patch for bug 50 is not as effective on Lotus Notes 6.5.3 as it was in Notes R5 and the Petzold justify1 example. Well, I'm checking some traces here, and noticed that version 6.5.3 uses a rather odd -- at least to me -- method for justifying a paragraph... below is a section of the trace grepped to show only the relevant calls. Here Notes is trying to justify the first paragraph of a message, being the first line Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam tellus pede, semper id, convallis a, tincidunt ut, augue. That's a single line -- or rather extent --, but here is what the log says (ignore the excess of repetitions, I was trying to be thorough): LOG SECTION STARTS HERE trace:font:SetTextJustification (hdc=0xaa60, breakExtra=7, breakCount=7) trace:font:GetTextExtentPoint32W (0xaa60 LLorem ipsum dolor sit amet, consectetuer adipiscing elit 56 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, LLorem ipsum dolor sit amet, consectetuer adipiscing elit, 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, LLorem ipsum dolor sit amet, consectetuer adipiscing elit, 56, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=333, cy=19, nfit=56 trace:font:GetTextExtentExPointW returning cx=333, cy=19, nFit=0 trace:font:SetTextJustification (hdc=0xaa60, breakExtra=0, breakCount=0) trace:font:GetTextExtentPoint32W (0xaa60 L. 1 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L., 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L., 1, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 trace:font:SetTextJustification (hdc=0xaa60, breakExtra=1, breakCount=1) trace:font:GetTextExtentPoint32W (0xaa60 L 1 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L , 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L , 1, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 trace:font:SetTextJustification (hdc=0xaa60, breakExtra=0, breakCount=0) trace:font:SetTextJustification (hdc=0xaa60, breakExtra=13, breakCount=9) trace:font:GetTextExtentPoint32W (0xaa60 LEtiam tellus pede, semper id, convallis a, tincidunt ut, augue 62 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, LEtiam tellus pede, semper id, convallis a, tincidunt ut, augue, 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, LEtiam tellus pede, semper id, convallis a, tincidunt ut, augue, 62, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=355, cy=19, nfit=62 trace:font:GetTextExtentExPointW returning cx=355, cy=19, nFit=0 trace:font:SetTextJustification (hdc=0xaa60, breakExtra=0, breakCount=0) trace:font:GetTextExtentPoint32W (0xaa60 L. 1 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L., 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L., 1, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 trace:font:GetTextExtentPoint32W (0xaa60 L 1 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L , 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L , 1, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 trace:font:GetTextExtentPoint32W (0xaa60 L 1 0x34c184): returning 3457464 x 0 trace:font:GetTextExtentExPointW (0xaa60, L , 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457464, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L , 1, 0, 0x34c184 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 LOG SECTION ENDS HERE Btw, that last period was *not* painted. I'm having some ideas here, but they don't seem very nice right now... what about you? Keith? TIA, - Pedro.
Re: Test case for Bug 50 [Was: Bug 50]
I think I've managed to patch [1] bug 50 [2], but I'm having a little trouble coming up with a proper test case... I'm already at it, studying and investigating, but could someone test that, too? [1] http://bugs.winehq.org/attachment.cgi?id=4543action=view [2] http://bugs.winehq.org/show_bug.cgi?id=50 TIA, - Pedro.
