Re: patch for selection of "MS Sans Serif" font face
Just add it as a font substitute in the registry ie [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes] ... "MS Sans Serif"="Microsoft Sans Serif" Huw. -- Huw Davies [EMAIL PROTECTED]
Re: patch for grid-fitting on Solaris
This is a freetype bug, do you still have the problem with FreeType 2.1.4 ? (sorry I can't easily include your path because it's an attachment). Huw.
Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
On Wed, Aug 27, 2003 at 07:30:32PM -0400, Todd Vierling wrote: > On Wed, 27 Aug 2003, Alexandre Julliard wrote: > > : It's not really a question of shuffling back and forth, it's that > : different users have different kernels; so if you want to ship a > : binary that works for everybody, with your method you have to stick to > : the lowest common denominator. With run-time checks you can have a > : binary that takes advantage of new kernel features, while still > : running everywhere. > > That's why there is a "#ifdef MAP_TRYFIXED". If this is available at > compile time, it is known to be available at runtime regardless of CPU > platform -- it's not an optional kernel feature. It's available on the machine that the binary is compiled on sure, but what about the machine of a friend/customer who you've shipped the binary to? Just because you have the new kernel feature on your build machine doesn't mean that everybody else does. If you test at run-time you avoid these problems. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: patch for underline and strikeout text in xrender
On Wed, Aug 27, 2003 at 06:12:44PM -0400, Dimitrie O. Paun wrote: > On Wed, 27 Aug 2003, Huw D M Davies wrote: > > > Actually you want to use the otmsUnderscoreSize, > > otmsUnderscorePosition, otmsStrikeoutSize and otmsStrikeoutPosition > > members of OUTLINETEXTMETRIC, rather than hard coding those 2s and 3.5s. > > > > You may also want to think about what happens when the text is rotated :) > > These are good points. But having common code makes all this a bit easier > to handle. I just made a trivial simplification, I don't pretend to > understand the problem. :) True, they were really comments for Dave. Your simplification however doesn't work if both lfUnderline and lfStrikeout are set... Huw.
Re: patch for underline and strikeout text in xrender
On Wed, Aug 27, 2003 at 05:34:53PM -0400, Dimitrie O. Paun wrote:
>
> What about we simplify this a bit:
>
> if (lf.lfUnderline || lf.lfStrikeOut) {
> long linePos = (lf.lfUnderline ? tm.tmDescent / 2 : - tm.tmAscent / 3.5);
>
> TSXSetForeground( gdi_display, physDev->gc, physDev->textPixel );
> TSXSetLineAttributes( gdi_display, physDev->gc, lineWidth,
> LineSolid, CapProjecting, JoinBevel );
> TSXDrawLine( gdi_display, physDev->drawable, physDev->gc,
> physDev->org.x + x, physDev->org.y + y + linePos,
> physDev->org.x + x + width, physDev->org.y + y + linePos );
> }
>
Actually you want to use the otmsUnderscoreSize,
otmsUnderscorePosition, otmsStrikeoutSize and otmsStrikeoutPosition
members of OUTLINETEXTMETRIC, rather than hard coding those 2s and 3.5s.
You may also want to think about what happens when the text is rotated :)
Huw.
Re: Two font problems
On Wed, Jul 09, 2003 at 10:32:22AM +0100, E Lea wrote: > I'm having what seem to be two unrelated font issues with a CAD program. > > The first is concerned with selecting a font. The program seems to use a > fairly non-standard intreface for doing this - you can set font size in mm > for example. When the dialog opens this message is printed to stdout: > > fixme:commdlg:CFn_WMInitDialog No founds found with truetype only, dropping > flag. > > I am assuming that this is a case for s/founds/fonts/ or not? The dialog > does give the option of TTFs, and previews them, although only very small, > possibly the smallest size available. > > The second problem occurs when the program actually tries to add the > specified text to the CAD drawing. This message is printed to stdout: > > err:font:XFONT_RealizeFont plf->lfHeight = -2048, Creating a 100 pixel font > and rescaling metrics > > and a windows error style message box is produced that has the message > "Error! GetGlyphOutline failed. Unable to get character outline.". The > program is clearly trying to convert the text to a vector graphic so that it > can treat it like any other shape, but failing. > > Should I file two bug reports about this? The software is commercial and so > I can not provide a copy for anyone to reproduce this error. You need to get client side font rendering working. Currently you're defaulting back to server side X11 fonts that will appear to the app as if they are device fonts. To get client side rendering working you need a working freetype config and some TrueType fonts in a directory listed in the [Fontdirs] section of the config file. A --debugmsg +font trace should tell you where things are going wrong. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: WWN: wn20030704_177.xml
On Thu, Jul 03, 2003 at 04:02:47PM -0700, Brian Vincent wrote: > It's main goal is to This should be 'Its main goal...'. And we appear not to have a main goal anyway :) Huw.
Re: Janitorial W->A cleanup objects/metafile.c dlls/gdi/mfdrv/init.c
On Sun, Mar 23, 2003 at 05:43:39PM -0700, Tony Lambregts wrote:
> This one was required more that a mop and pail. In the end what I had to do
> is convert MF_CreateMetaHeaderDisk to unicode.
>
> One burning question I have at this point is the relative merits of using
> RtlCreateUnicodeStringFromAsciiz vs MultiByteToWideChar
>
> Change Log: convert MF_CreateMetaHeaderDisk to unicode and W->A clean up
>
> Files Changed: objects/metafile.c dlls/gdi/mfdrv/init.c
>
> --
>
> Tony Lambregts
> Index: objects/metafile.c
> ===
> RCS file: /home/wine/wine/objects/metafile.c,v
> retrieving revision 1.57
> diff -u -r1.57 metafile.c
> --- objects/metafile.c27 Feb 2003 21:09:45 - 1.57
> +++ objects/metafile.c24 Mar 2003 00:49:27 -
> @@ -54,6 +54,9 @@
> #include "global.h"
> #include "wownt32.h"
> #include "wine/debug.h"
> +#include "file.h"
> +#include "winternl.h"
> +#include "wine/unicode.h"
>
> WINE_DEFAULT_DEBUG_CHANNEL(metafile);
>
> @@ -62,7 +65,7 @@
> {
> DWORD dw1, dw2, dw3;
> WORD w4;
> -CHAR filename[0x100];
> +WCHAR filename[MAX_PATHNAME_LEN];
> } METAHEADERDISK;
> #include "poppack.h"
This will break compatibility with 16bit metafiles where the mf handle
is a global memory handle to the above structure. See the comment at
the top of the file (hint, that's why this structure has elements
dw1,2,3)
Now you could create a new struct for 32bit only use if you want...
Huw.
--
Huw Davies
[EMAIL PROTECTED]
Re: Wine and XFree86 4.3.0
On Thu, Mar 20, 2003 at 05:01:36PM +0100, Ulrich Spoerlein wrote: > On Thu, 20.03.2003 at 13:47:05 +0000, Huw D M Davies wrote: > > > I'm running the newest WINE release on FreeBSD 4.8. > > What does the output of xdpyinfo say? > > I'm currently not (physically) at my machine, but I made sure the RENDER > extension is present (both with the nv and nvidia driver) > > Or were you referring to some other information? I think I'm interested in the entire output. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Wine and XFree86 4.3.0
On Thu, Mar 20, 2003 at 11:00:06AM +0100, Ulrich Spoerlein wrote:
> Hello,
>
> does anyone here have WINE running with XFree86 4.3.0? Everytime I start
> up wine it complains about a broken libXrender and the palette is
> completely screwed (or the window remains totally black).
>
> The failing test is at wine/dlls/x11drv/render.c:163
>
> screen_format = pXRenderFindVisualFormat(gdi_display, visual);
> if(!screen_format) { /* This fails in buggy versions of libXrender.so */
> wine_tsx11_unlock();
> WINE_MESSAGE(
> "Wine has detected that you probably have a buggy version\n"
> "of libXrender.so . Because of this client side font rendering\n"
> "will be disabled. Please upgrade this library.\n");
> X11DRV_XRender_Installed = FALSE;
> return;
> }
>
> XRenderVisualFormat changed only slightly between 4.2.1 and 4.3.0, so I
> guess the error is somewhere else.
>
> I'm running the newest WINE release on FreeBSD 4.8.
What does the output of xdpyinfo say?
Huw.
--
Huw Davies
[EMAIL PROTECTED]
Re: Music font problem
On Tue, Feb 18, 2003 at 10:02:09PM -0600, Andrew Johnson wrote: > I originally posted this to comp.emulators.ms-windows.wine, where it > was suggested I send a copy here. Please CC: replies to me as I'm not > subscribed to wine-devel. TIA! > > I have been using a shareware program called Noteworthy Composer for > many years on Windows, but am trying to switch to a Linux-only setup > and this is one the last obstacles. I don't want to switch to the > other Linux music programs as to my mind they don't provide as simple > an interface as NWC does, and I already have many song files in the > NWC format. The main problem with running this is that it uses its > own TrueType Font, which doesn't display properly under Wine - I just > get outline boxes instead of the note symbols. Hi, I'll try to take a look at this in the next few days. Huw.
Re: Implement font glyph rotation
On Thu, Feb 06, 2003 at 09:50:57AM -0500, [EMAIL PROTECTED] wrote:
>
>
>
> ChangeLog:
>
> Add support for font glyph rotation in GetGlyphOutline.
>
> Description:
>
> Fixed bad angle conversion from tenths of degree to FT_Fixed on
> big-endian machines.
>
> Fixed bad calculation of the gmCellIncY bounding box field
> in the case of a rotation. (just imagine what you would get
> as result from "-(vec.y+63) >> 6" when vec.y is zero... what
> we expect really is zero, not -1).
>
> Fixed wrong rotation matrix used to transform the outline.
>
> Rotate each point of the outline before it gets converted
> by FTVectorToPOINTFX in the GGO_NATIVE case.
>
> Warren Baird : [EMAIL PROTECTED]
> Dave Belanger
>
> diff -ur clean/wine/dlls/gdi/freetype.c wine/dlls/gdi/freetype.c
> --- clean/wine/dlls/gdi/freetype.c 24 Jan 2003 15:12:16 - 1.1.1.3
> +++ wine/dlls/gdi/freetype.c 28 Jan 2003 18:37:34 -
> @@ -1510,7 +1510,7 @@
> if(font->orientation) {
> FT_Matrix matrix;
> matrix.xx = matrix.yy = pFT_Cos(angle);
> - matrix.xy = -pFT_Sin(angle);
> + matrix.xy = pFT_Sin(angle);
> matrix.yx = -matrix.xy;
>
> pFT_Outline_Transform(&ft_face->glyph->outline, &matrix);
Hi,
Are you sure about this hunk? Iirc there was a vesion of FreeType
that incorrectly swapped the meaning of matrix.xy and matrix.yx, but
as I understand it this has now been corrected. Which version of
FreeType have you been using? We could probably add a run time check
to work around this bug if need be.
Huw.
Re: Map "MS Sans Serif" font -> "Microsoft Sans Serif"
On Wed, Feb 05, 2003 at 06:32:09PM -0500, [EMAIL PROTECTED] wrote: > > > > ChangeLog: > > Added a fixed alias mapping "MS Sans Serif" -> "Microsoft Sans Serif". > > Description: > > Some excel documents expect to be able to load an "MS Sans Serif" > font and were getting "Microsoft Sans Serif" instead. > Why don't you add a font substitution to the registry? Under HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\FontSubstitutes something of the form "MS Sans Serif"="Microsoft Sans Serif" should work. Huw.
Re: Underline and strikethrough support
On Wed, Feb 05, 2003 at 06:18:50PM -0500, [EMAIL PROTECTED] wrote: > > > ChangeLog: > > Add support for underline and strikethrough font in XRender. > > Description: > > Use lfUnderline or lfStrikeOut logical font field in > X11DRV_XRender_ExtTextOut to determine if we should draw a > line using TSXDrawLine across or under the font that just got > rendered. Hi, The problem with this code is that it won't work for rotated text. Also the line widths and positions should be obtained using from the OUTLINETEXTMETRICS structure. Huw.
Re: font metrics II
On Wed, Feb 05, 2003 at 03:05:21PM -0600, Scott Jackson wrote: > ok, here's a better question: > since my Japanese fonts don't puke under X11 (but do under wine :-P ), is there any >way I can get wine to ignore certain directories of fonts?? > This would help b/c wine crashes on one of my Kappa fonts. > Thanks! Even better would be for you to run wine with --debugmsg +font and send me the resulting logfile as well as a backtrace from the debugger of the crash. Then I can hopefully fix the problem rather than us trying to work around it. Huw.
Re: Font trouble in VB app "Yardi Property Management"
On Sat, Jan 25, 2003 at 12:48:25PM -0800, Dan Kegel wrote: > I ran a VB app from http://www.yardi.com with the command > > $ wine --dll compobj,storage,ole2,ole32=n Y.EXE > > It initially died because COMPOBJ.DLL didn't > implement ordinals COMPOBJ.201 and COMPOBJ.207, > so I copied compobj.dll from Windows Me, and that got rid > of the crash. > > However... there's a bit of font corruption in both the > splash screen and the opening file dialog box. I'm attaching > .png images for both. They're pretty much unreadable. > So I reran with --debugmsg +font, and am attaching the log > (compressed, this time!). > > Any suggestions? I could run the app under XP and > get traces or screen dumps if that would help. Hi Dan Wine only finds one font file (/home/dank/c/windows/Fonts/AdvMicr.ttf). My guess is that previously you'd been defaulting to X11 fonts and then some app installed this font, Wine now sees this and uses client side fonts. The problem is that things don't look great when you've only got one font to choose from, especially if it's a symbol type font :) If you add a [FontDirs] section to the config file with lines of the form: "dir1"="/unix/path/to/font/dir" "dir2"="/another/path/to/fonts" ... where the directories contain TrueType font files then hopefully things should look better. [Did I say that we should have libfontconfig support in Wine...] Huw.
Re: Non latin fonts and non local fonts
On Mon, Dec 09, 2002 at 11:50:06PM +0200, Shachar Shemesh wrote: > Hi list, > > http://bugs.winehq.com/show_bug.cgi?id=1157 > > It appears that when I'm copying the Windows fonts to C:\windows\Fonts, > setting LANG to he_IL is all it takes for Hebrew to be displayed in edit > controls and dialog boxes. > > When I try to copy the exact same fonts to /usr/lib/X11/fonts/windows, > and adding them to the XF86Config fonts dir, and running ttmkfdir, no > go. The fonts are available to Wine (and each is enumerated multiple > times in the fonts dialog), but Hebrew is not displayed by default. > > Sometimes, when I force the CHARSET to HEBREW_CHARSET, I get Hebrew > after all, but I'm not at all sure the same font is used then. > > In addition to this problem, I was wondering why we no longer enumerate > the X fonts the moment there is ONE font file in c:\windows\Fonts? Is > there a reason for them to magically disappear? The difference is between: 1. Wine rendering the glyph itself and transfering the bitmap to the XServer using either the RENDER extension or X11 pixmap core requests. (client side rendering) 2. Letting the XServer render and display the glpyh all through X11 font core requests (server side rendering). [Note whether the XServer actually renders the glyphs itself or calls out to a font server makes no difference - to the client it looks like the XServer is doing the work. Now the X11 font core requests just don't provide enough control to properly mimic the Windows font api. For example there's no way to do anti-aliasing; there's also no way for the client to learn about the outlines of scalable fonts which is needed for printing. This makes server side rendering much less preferable than client side rendering. However to use client side rendering Wine needs to have access to some font files; once it has these it'll switch to using client side rendering for all fonts and not even query the XServer about its own fonts. So as soon as you give it one font in c:\windows\fonts Wine will ignore any fonts installed solely on the XServer. Now if you want Wine to see these fonts either copy them into c:\windows\fonts or add a [Fontdirs] section to the config file and add lines like "dir1"="/unix/path/to/font/dir" "dir2"="/unix/path/to/another/font/dir" Huw.
Re: Help needed - CreateScalableFontResource
On Wed, Nov 27, 2002 at 07:08:08PM +0200, Shachar Shemesh wrote: > Works great for me. Thanks!! > > Is there any chance you'll submit the official fix to be included by the > time we have to present the software (Monday - Sunday evening if you are > in the US, as we are ahead of the US). I would like to be able to say > that "this is the out of the box Wine". I've sent the EnumFont16 fix off to wine-patches. Huw.
Re: Help needed - CreateScalableFontResource
On Tue, Nov 26, 2002 at 08:28:57PM +0200, Shachar Shemesh wrote:
> That did not work. Both CreateScalableFontResource and AddFontResource
> work. The application then goes on to enumerate the fonts, and
> X11Drv.EnumDeviceFonts fails to detect any "Amir" fonts. Output of +all
> of relevant part is at the end.
>
> Any idea why?
Yup, EnumFonts16 is broken. Could you give this untested patch a go?
Huw.
Index: objects/font.c
===
RCS file: /home/wine/wine/objects/font.c,v
retrieving revision 1.93
diff -u -r1.93 font.c
--- objects/font.c 25 Nov 2002 21:09:49 - 1.93
+++ objects/font.c 26 Nov 2002 20:11:51 -
@@ -71,6 +71,7 @@
LPENUMLOGFONTEX16 lpLogFont;
SEGPTRsegTextMetric;
SEGPTRsegLogFont;
+ DWORD dwFlags;
HDC hdc;
DC *dc;
PHYSDEV physDev;
@@ -524,6 +525,7 @@
{
FONT_EnumLogFontExWTo16(plf, pfe->lpLogFont);
FONT_NewTextMetricExWTo16(ptm, pfe->lpTextMetric);
+pfe->dwFlags |= ENUM_CALLED;
GDI_ReleaseObj( pfe->hdc ); /* release the GDI lock */
ret = FONT_CallTo16_word_llwl( pfe->lpEnumFunc, pfe->segLogFont,
pfe->segTextMetric,
@@ -590,36 +592,49 @@
DWORD dwFlags)
{
fontEnum16 fe16;
-INT16 retVal = 0;
+INT16 ret = 1, ret2;
DC*dc = DC_GetDCPtr( HDC_32(hDC) );
+NEWTEXTMETRICEX16 tm16;
+ENUMLOGFONTEX16 lf16;
+LOGFONTW lfW;
+BOOL enum_gdi_fonts;
if (!dc) return 0;
+FONT_LogFont16ToW(plf, &lfW);
+
fe16.hdc = HDC_32(hDC);
fe16.dc = dc;
fe16.physDev = dc->physDev;
+fe16.lpLogFontParam = plf;
+fe16.lpEnumFunc = efproc;
+fe16.lpData = lParam;
+fe16.lpTextMetric = &tm16;
+fe16.lpLogFont = &lf16;
+fe16.segTextMetric = MapLS( &tm16 );
+fe16.segLogFont = MapLS( &lf16 );
+fe16.dwFlags = 0;
+
+enum_gdi_fonts = GetDeviceCaps16(hDC, TEXTCAPS) & TC_VA_ABLE;
-if (dc->funcs->pEnumDeviceFonts)
+if (!dc->funcs->pEnumDeviceFonts && !enum_gdi_fonts)
{
-NEWTEXTMETRICEX16 tm16;
-ENUMLOGFONTEX16 lf16;
-LOGFONTW lfW;
-FONT_LogFont16ToW(plf, &lfW);
-
-fe16.lpLogFontParam = plf;
-fe16.lpEnumFunc = efproc;
-fe16.lpData = lParam;
-fe16.lpTextMetric = &tm16;
-fe16.lpLogFont = &lf16;
-fe16.segTextMetric = MapLS( &tm16 );
-fe16.segLogFont = MapLS( &lf16 );
-
-retVal = dc->funcs->pEnumDeviceFonts( dc->physDev, &lfW,
- FONT_EnumInstance16, (LPARAM)&fe16 );
-UnMapLS( fe16.segTextMetric );
-UnMapLS( fe16.segLogFont );
+ret = 0;
+goto done;
}
+
+if (enum_gdi_fonts)
+ret = WineEngEnumFonts( &lfW, FONT_EnumInstance16, (LPARAM)&fe16 );
+fe16.dwFlags &= ~ENUM_CALLED;
+if (ret && dc->funcs->pEnumDeviceFonts) {
+ ret2 = dc->funcs->pEnumDeviceFonts( dc->physDev, &lfW, FONT_EnumInstance16,
+(LPARAM)&fe16 );
+ if(fe16.dwFlags & ENUM_CALLED) /* update ret iff a font gets enumed */
+ ret = ret2;
+}
+done:
+UnMapLS( fe16.segTextMetric );
+UnMapLS( fe16.segLogFont );
if (fe16.hdc) GDI_ReleaseObj( fe16.hdc );
-return retVal;
+return ret;
}
/***
Re: Help needed - CreateScalableFontResource
On Mon, Nov 25, 2002 at 10:27:55PM +0200, Shachar Shemesh wrote: > Hi list, > > We have in Israel a lawyer who has cought on to the idea of open source, > and is helping "The Cause"(tm) here quite a lot. As part of his > activities he is wants to demonstrate a Hebrew law and precedance lookup > program at a conference on Dec 2nd using Wine, and he asked for my help. > > fixme:font:CreateScalableFontResourceA > (0,"C:\\PD_OR\\FONTS/AMIR.FOT","C:\\PD_OR\\FONTS/AMIR.TTF",(null)): > stub > fixme:font:CreateScalableFontResourceA > (0,"C:\\PD_OR\\FONTS/AMIRBLD_.FOT","C:\\PD_OR\\FONTS/AMIRBLD_.TTF",(null)): > stub > fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. > > The application then goes on to display a error message saying (In > hebrew) "The fonts for the application could not be found, please > reinstall...". > > The fonts are indeed available in C:\PD_OR\FONTS as TTF files. It seems > the application calls CreateScalableFontResource, and then tries to > register the fonts. Copying the TTF fonts to the fonts directory did not > solve this problem. > > I am looking for some solution, even a workaround, that will solve this > problem for me. I have contact with the application's developers, and > they are very interested in getting this to work (not interested enough > to actually install Linux, but they are interested enough to answer > technical questions about the app). > > My questions: > A. Is there any way I can patch Wine to fool the app into thinking that > part succeeds? Or is performing this test necessary, for some strange > reason, in order to use the TTF fonts? > B. It MAY be possible to ask the developers to actually modify their > code to a moderate degree, in order to get this app to work. Is there > anything in particular I can ask them? > C. Is anyone working on this API? I don't know the first thing about > font files and resources, and while I CAN learn, is someone with already > existing knowledge can do something about it, it would be much preferable. You could try hacking CreateScalableFontResource to return TRUE. The next thing the app will do is to call AddFontResource using the .FOT filename, this will also fail so you might have to fix the return value for that function too. However if you have the TTF files in c:\windows\fonts then hopefully the app will be happy. CreateScalableFontResource is on my todo list. Note that the app is also failing to load some 16bit user functions, so even with the fonts fixed you may have more problems later on... Huw.
Re: Get rid of W->A calls: LoadImageW
On Tue, Nov 19, 2002 at 09:10:31PM +0100, Stefan Leichter wrote:
> Changelog
>
> replaced CreateDCA by CreateDCW in LoadImageW to Get rid of W->A calls
>
> Index: wine/windows/cursoricon.c
> ===
> RCS file: /home/wine/wine/windows/cursoricon.c,v
> retrieving revision 1.56
> diff -u -r1.56 cursoricon.c
> --- wine/windows/cursoricon.c 13 Nov 2002 19:43:53 - 1.56
> +++ wine/windows/cursoricon.c 18 Nov 2002 21:38:42 -
> @@ -72,6 +72,8 @@
>
> static HDC screen_dc;
>
> +static WCHAR DISPLAYW[] = {'D','I','S','P','L','A','Y',0};
> +
> /**
> * ICONCACHE for cursors/icons loaded with LR_SHARED.
> *
> @@ -2052,7 +2054,7 @@
> return BITMAP_Load( hinst, name, loadflags );
>
> case IMAGE_ICON:
> -if (!screen_dc) screen_dc = CreateDCA( "DISPLAY", NULL, NULL, NULL );
> +if (!screen_dc) screen_dc = CreateDCW( DISPLAYW, NULL, NULL, NULL );
> if (screen_dc)
> {
> UINT palEnts = GetSystemPaletteEntries(screen_dc, 0, 0, NULL);
>
I don't see the point of this at all. Why does it matter that we're
calling CreateDCA here? it's not as if we're losing information by
converting a Unicode to an Ascii string.
Huw.
Re: Font selection - please review
On Fri, Nov 15, 2002 at 03:25:48PM +0200, Shachar Shemesh wrote:
> Hi all,
>
> I am thinking of submitting the attached patch. The problem is that I am
> not comfertable with the location I added it.
>
> As far as I could tell, there is nowhere in the whole of Wine where the
> selected language is matched with the charset to be used by default.
> This is what this patch comes to amend.
>
> There is a slight awkwardness that is inherent to the Win32 API, in
> which, in order to create the default font, you zero out a LOGFONT
> struct, fill in the struct length, and call "CreateFontIndirect".
> Looking at the resulting struct, however, reveals that what you have
> just asked for is a ANSI_CHARSET font. It appears that windows correctly
> understands that this is an uninitialized LOGFONT, apparently based on
> the fields tested.
Hi,
CHARSET_DEFAULT is translated to the charset assosicated with the
current ansi codepage in
dlls/gdi/freetype.c:WineEngCreateFontInstance(). This of course only
works if you're using client side rendered fonts (this becomes easier
as of last night as you don't even need a RENDER capable XServer
anymore). CreateFontIndirect is definitely the wrong place for these
kind of fixups since GetOject on the hfont always returns the original
logfont values. If you need to get this working for X11 fonts then
you'll have to poke around in graphics/x11drv/xfont.c somewhere...
I hadn't spotted the brokenness of the Win32 API with regard to
certain elements of logfont being set to zero giving a DEFAULT_CHARSET
font. In fact it turns out that even if lfFaceName[0] != 0 then you
still get this behaviour if the name doesn't match an installed
fontname. The attached patch should fix this.
Huw.
Index: dlls/gdi/freetype.c
===
RCS file: /home/wine/wine/dlls/gdi/freetype.c,v
retrieving revision 1.27
diff -u -r1.27 freetype.c
--- dlls/gdi/freetype.c 13 Nov 2002 23:54:50 - 1.27
+++ dlls/gdi/freetype.c 15 Nov 2002 15:21:40 -
@@ -1030,8 +1030,12 @@
not_found:
if(!family) {
/* If requested charset was DEFAULT_CHARSET then try using charset
-corresponding to the current ansi codepage */
-if(!csi.fs.fsCsb[0]) {
+ corresponding to the current ansi codepage. Also it appears if
+ various other elements of lf are set to zero then we should use
+ the current ACP's charset. */
+if(!csi.fs.fsCsb[0] || (lf.lfCharSet == 0 && lf.lfHeight == 0 &&
+lf.lfEscapement == 0 && lf.lfPitchAndFamily == 0 &&
+lf.lfWidth == 0)) {
INT acp = GetACP();
if(!TranslateCharsetInfo((DWORD*)acp, &csi, TCI_SRCCODEPAGE)) {
FIXME("TCI failed on codepage %d\n", acp);
Re: Opinions about univesal printer driver
On Mon, Sep 02, 2002 at 02:31:38AM +0200, Ilja Kamps wrote: > On Mon, Sep 02, 2002 at 02:17:41AM +0200, [EMAIL PROTECTED] wrote: > > I'm trying to imagine a method for using windows printer drivers under > > linux. As far as I know, from gdi's point of view it works like: > > LoadLibrary(driver) (drv appears to be a dll), > > some of 24 DDI functions which every printer driver should contain, > > Initialization = Enable, Control, next goes drawing functions like Output, > > Pixel. It doesn't have to access paralell ports - it can write to file > > (when printing under Windows you have this little checkbox, and gdi > > initializes driver telling this filename I think). Content of this file can > > be directly sent to port in Linux's way. I know that's not that simple, but > > I'm very interested in your opinions: what do you think about it having > > experience in dlling under linux :-) ? I know that wine doesn't run > > drivers, but it can run win dlls. Is it possible at all? Or this is just a > > linux-supports-every-printer dream? Perhaps someone tried this already? > > > Well, Wine once supported Windows printer drivers, (I belive the support got > broken in early 2001), but based on that you should be able to resurrect support > without too much trouble. There's some support for 16 bit printer drivers (note the drivers for win9x are 16 bit). The code is in dlls/gdi/win16drv/ but as you say this may well be broken at the moment. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Heap overruns
On Sun, Sep 01, 2002 at 11:33:55PM +0300, Shachar Shemesh wrote: > Marcus Meissner wrote: > > >On Sun, Sep 01, 2002 at 12:17:38PM +0300, Shachar Shemesh wrote: > > > > > >>Hi list, > >> > >>I am currently having some problems with a change I am working on, that > >>result in heap corruption as a result of buffer overrun. I was wondering > >>whether there was any builtin debug options to detect and help fix these > >>things. > >> > >>If there aren't, I am perfectly willing to sidetrack a little and write > >>them. Please let me know. > >> > >> > > > >If you run with -debugmsg +heap it will check the heaps at every access > >for corruption. > > > >Ciao, Marcus > > > > > Thanks, but this is not what I meant. > > Currently, when a buffer overruns, the free pointers right after get > corrupted, and when the next piece of block is allocated, the machine > will crash. This will tell me approximetly where the buffer overrun, but > is, generally speaking, too late. Enabling the debug messages detects > the error at the same place (i.e. - too late). > > What I am talking about is a compile time (or run time, no reason why > not) option that will add "hot zone" areas before and after each heap > allocated buffer. These zones should be: > A. Large enough so that the overrun doesn't reach the heap managment > structures themselves. This means that the program can keep on running > despite having the buffer overflow. > B. Identifiable, so that we know if a buffer has overwritten it. No, as Marcus says, enabling +heap debugging forces the entire heap to be checked for consistency on every HeapAlloc/Free/ReAlloc . So if you overwrite a block you'll get an error the next time you call a heap function (on the same heap) and not only when the system tries the alloc the next block. So, if you see heap corruption this way, you can assume that it occured somewhere between this point and the last time you called a heap function. Huw.
Re: PATCH: [Bug 19] - font enumeration problems for aliased gdi fonts
On Thu, Jul 25, 2002 at 12:43:37PM -0700, Rafael Kitover wrote: > Huw D M Davies wrote: > > What's exactly the problem here? Is it lack of support of 16bit EnumFonts ? > > > > Huw. > > The problem is this line in X11DRV_EnumDeviceFonts: > > if (physDev->dc->gdiFont) return FALSE; > > so if the font is "MS Sans Serif", it will return 0, and old VB apps at least > won't like that. But knowing the actual X11 font name given in the wine config, > from the alias table it's possible to enumerate it, so those apps will start, > that's what that patch does. > > That's all I really managed to understand here, if there is a better way to do > this I will. The alias table in the config file is used only by the old font scheme. Could you send me a relay trace of what's going on, I'd like to understand why VB apps have problems. Thanks, Huw. -- Huw Davies [EMAIL PROTECTED]
Re: 10072002 version - printing bug
On Wed, Jul 24, 2002 at 05:33:54PM +0800, leanne wrote: > Dear all, > > I found the 10072002 version of WINE that the layout of printout got > problems. > some letters overlap. This is probably a bug in the Type 42 font download code. Could you try editting your ppd file (by default generic.ppd) and chaging the line *TTRasterizer: Type42 to *TTRasterizer: None this will get Wine to download the fonts as Type 1 outlines instead. Let me know if it makes a difference. Huw.
Re: PATCH: [Bug 19] - font enumeration problems for aliased gdi fonts
On Tue, Jul 23, 2002 at 01:00:59PM -0700, Rafael Kitover wrote: > This patch fixes the "Invalid Property Value" message box that pops up > in older visual basic programs on startup when they try to call > ENUMFONTS on the default "MS Sans Serif" font for example. > > (reference: http://www.winehq.com/hypermail/wine-bugs/2002/05/0116.html) > > License: LGPL, X11 > > Changelog: > Rafael Kitover <[EMAIL PROTECTED]> > Fix ENUMFONTS on aliased gdi fonts What's exactly the problem here? Is it lack of support of 16bit EnumFonts ? Huw.
Re: PSDRV question
On Tue, Jul 09, 2002 at 04:45:56PM -0400, Carl Sopchak wrote: > I've been trying to get Quicken 2000 Deluxe running in wine. After I figured > out that it wasn't finding a DLL for the internet connection (and got that > fixed), I started testing the second-most important function of Quicken that > I need: check printing. > > All went well until I tried to print a sample check (to verify alignment), at > which point Wine crashed into winedbg. I figured out why: When reading the > ppd file, it sets up an *InputSlot for ManualFeed (even though it's not > really an InputSlot, but most Win programs treat it as one...). The problem > was that, in ppd.c, a Name wasn't given to the slot (but a FullName was), so > when ps.c tried to output the header for the InputSlot it crashed (since > strlen(NULL) causes a crash). > > I hacked the AddSlot call to name the slot "Manual", and this seems to work > OK. The question that I have is, is this the way that it should REALLY get > fixed (does the name matter?), or should something else be done? > > I'd be happy to correct my hack, if necessary. In either case, I can post the > patch to sourceforge, once I know "the right way" this should be handled. > > Thanks for the help, I'd suggest calling PSDRV_AddSlot with both Name and FullName set to "Manual Feed" Huw.
Re: [help] GDI text fonts
On Wed, Jul 03, 2002 at 04:54:18PM +0800, leanne wrote: > Huw D M Davies wrote: > > > > >It's still not clear to me whether you're using XServer rendered fonts > >or client side (Wine) rendered fonts. Could you send me the > >--debugmsg +font,+xrender log ? > > > >Huw. > > > Hello, > > I have checked cvs today and found that it supports to download tt > fonts to printer but the position of the text messes up. > Maybe it's a bug. > > I still find the font of the interface is very ugly, what do you think? > Attached please find the log and screenshot. > Very thanks. > > trace:font:DumpFontList Family: L"AR PL Mingti2L Big5" > trace:font:DumpFontList L"Reguler" > trace:font:DumpFontList Family: L"AR PL KaitiM Big5" > trace:font:DumpFontList L"Regular" There's a problem with Type42 font downloads, a workaround for this to edit generic.ppd and change the line *TTRasterizer: Type42 to *TTRasterizer: None this will tell Wine to send download the font as a Type 1 outline which should work. Do you mean that the roman (English) font is ugly (since I have no idea whether the Chinese characters look ok maybe you let me know how they look)? You only have two fonts installed (see the above fragment from the log), so the english text has to come from one of these fonts. What you may want to do is to install some fonts like Arial, Times New Roman etc. You could either copy these from a Windows installation (or add a line to the [FontDirs] section of config to point at an existing Windows partition font directory), or you can download a selection of the core Windows fonts from Microsoft's website. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Small 'let's prevent a crash' fix
On Tue, Jul 02, 2002 at 11:25:47PM +0200, Lionel Ulmer wrote: > > This does not fix the real problem (ie why does this DC not have a font even > > if the application called a 'SelectObject' on it), but well, it cannot harm > > to be more verbose and to prevent crashes if possible :-) > > OK, found the 'error' : the problem comes from the fact that I am using > client-side fonts (aka XRender) : so the 'font' part of the physDev > structure is always '0'. And that also means that we cannot use as is the > glXUseXFont function. > > So basically, I need to implement it myself using 'GetGlyphOutline' (should > not be that hard to do :-) ). > > Now my question : is 'GetGlyphOutline' always working even when not using > client-side fonts ? If yes, I will completely remove the call to > glXUseXFonts (I know, in that case, fonts displayed by OpenGL will be > different by the one displayed by X, but well, ...) and always use the > manual 'GetGlyphOutline' function. GetGylphOutline won't work if FreeType isn't available or if there are no TrueType fonts installed. At the moment the way to check for this is to look at dc->gdiFont, if this is non-NULL then gdi font rendering will work on this dc. In x11drv we do this test as well as a test for the RENDER extension at the top of X11DRV_SelectFont() and will fall back to X11 fonts if either is not present. Note though that if the dc is an x11drv dc for a non-RENDER enabled server, then dc->gdiFont will be NULL, since X11DRV_SelectFont will have returned TRUE which tells gdi to destroy any gdi font that it may have created. Huw.
Re: [help] GDI text fonts
On Tue, Jun 25, 2002 at 10:12:13AM +0800, leanne wrote: > Huw D M Davies wrote: > > >On Mon, Jun 24, 2002 at 11:05:04AM +0800, leanne wrote: > > > >>Dear all, > >> > >>When we are working on the Chinese support on WINE using Lotus Notes r5, > >>we found that the fonts display for the interface > >>is very ugly (attached the screepshot). I would like to change to have > >>different font when detected English or Chinese. > >>Could somebody point me where I could start with? > >> > I am sorry I missed them. > > 1. First, I use 2 Chinese fonts, Kai and Ming (bkai00mp.ttf and > bsmi00lp.ttf) as well as > fonts.dirluximb.ttf luxirbi.ttf luxirr.ttf luxisri.ttf > fonts.scale luximri.ttf luxirb.ttf luxisbi.ttf luxisr.ttf > luximbi.ttf luximr.ttf luxirri.ttf luxisb.ttf > > I start Lotus Notes and all Chinese can be displayed (because it is > using Chinese font by default, Ming) > English characters shown, however, are very ugly. > > > > > 2. When I copy the fonts from Windows and include the path, the > interface and > other fonts look good (using courier, helvetica and arial). I would > like to ask it's because > Lotus Notes default uses those fonts? > > > > > I want to display both Chinese and English, does WINE support > loading fontset? > or if I need to manually detect Chinese range and use Chinese font? > and could somebody > point me some hints? Thanks very much. It's still not clear to me whether you're using XServer rendered fonts or client side (Wine) rendered fonts. Could you send me the --debugmsg +font,+xrender log ? Huw. -- Huw Davies [EMAIL PROTECTED]
Re: [help] GDI text fonts
On Tue, Jun 25, 2002 at 12:40:15PM +0800, leanne wrote: > I have another question, when I try to print a document using > wordpad.exe, it doesn't use the font display. > > Arial changes to Helvetica. > Cooper changes to AvantGarde-Book > Kochi Gothic changes to AvantGarde-Book > > > > Why it could not set the correct font? no such fonts for printing? where > the code it changes to Helvetica/AvantGarde-Book? The code to download TT fonts to a printer was committed to the cvs yesterday, so please give this a go. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Getting CUPS printer to work in wine
On Sun, Jun 23, 2002 at 10:13:27PM -0400, Joshua Thielen wrote: > Joshua Thielen wrote: > > > After updating to the current CVS I get the following error message: > > > > trace:psdrv:PSDRV_CreateDC (WINEPS Printer LPT1: (nil)) > > To use WINEPS you need to install some AFM files. > > > > I believe this may be why I can't get printing to work. But do I > > really need AFM files to get printing to work? The printing doc says > > you don't need them for type 1 fonts. > > > > I've attached a trace of the printing errors just in case this isn't > > the cause of the problem. > > > > TIA for the help, > > > > Josh > > > > Well, first I forgot to attach the trace and then when I resent it with > the attachment it was too big (> 20 K). If anyone is interested in > looking at it, just let me know. Otherwise, I will debug it on my own > (if it isn't related to needing AFM files). I you need help then please let me know. You might want to open a bugzilla bug for this... Huw. -- Huw Davies [EMAIL PROTECTED]
Re: [help] GDI text fonts
On Mon, Jun 24, 2002 at 11:05:04AM +0800, leanne wrote: > Dear all, > > When we are working on the Chinese support on WINE using Lotus Notes r5, > we found that the fonts display for the interface > is very ugly (attached the screepshot). I would like to change to have > different font when detected English or Chinese. > Could somebody point me where I could start with? Unfortunately your attachment didn't make it. First you want to make sure that you're using client side rendered fonts, for this you'll need to have a version of the freetype library installed with version >= 2.0.5 you'll also require some TrueType fonts in c:\windows\Fonts. Make sure you're using the current cvs tip - there has been a big improvement for non ANSI_CHARSET fonts committed in the last few days. If you still have problems could you send me the output of --debugmsg +font,+xrender ? > Also, for a text document, the gdi text and font are used to store them, > I would like to ask where can I find the structure > to store and the code to manipulate it (e.g. send for display/print > (pExtTextOut? but where called pExtTextOut))? Well for fonts try objects/fonts.c and dlls/gdi/freetype.c for X11 text output try graphics/x11drv/text.c and dlls/x11drv/xrender.c Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Dynamically linking with a Unix library - or not
On Tue, Jun 18, 2002 at 07:32:58PM +0300, Shachar Shemesh wrote: > I am afraid that the consequence of B will be that no packager in his > right mind will use that option. As that works in direct contradiction > to the reason I entered the WINE project to begin with, I am trying to > opt for a better solution. I'm seeing two possible solutions to this > problem: > A. If Fribidi was present during compile, check for its existance during > run time. If not present, don't enable the run time option. > or > B. Copy (port?) Fribidi into the WINE code. It's LGPL, so the license > does allow that. > > The consequence of B is that I will need to keep an eye on Fribidi, and > keep it up to date whenever something changes there. I am very reluctant > to do so. I would much rather go for the "A" solution. The problem is > that I know how to do this in Windows, but not in Linux. Any help anyone > can offer me? Have a look at dlls/gdi/freetype.c where we use wine_dlopen and friends to do this with libfreetype.so Huw.
Re: Improvement for GetTimeZoneInformation
On Mon, May 27, 2002 at 11:12:07PM -0400, Vincent Béron wrote: > I need some help to finish this implementation. I don't have access to > an english version of Windows NT4 or 2K or XP, so I couldn't finish the > array of the timezones. COuld somebody help me a bit on this one? I'm > planning on actually writing the equivalence in Unix timezones, so you > only need to give me the names of the Windows timezones. I have a small > program to help you if you need it. > > Changelog: > - Improves the implementation of GetTimeZoneInformation. Missing some > Windows timezone names. In Windows there's a whole load of TimeZone information under \HLKM\Software\Microsoft\Windows\CurrentVersion\Time Zones I expect we should read the data from there rather than hardcode it; all we'd need to add would be a lookup table of Unix TZ names. Huw.
Re: Asian characters printing - not supported
On Wed, May 22, 2002 at 01:32:42PM -0500, Ian Pilcher wrote: > Huw D M Davies wrote: > > > > We've been working quite hard on making improvements to the PostScript > > driver and now have code that should print any character that can be > > displayed on the screen (assuming you're using client side font > > rendering anyway). The code downloads the TT font to the printer as > > either Type 42 (TT wrapped in PostScript) or for older printers the > > font gets converted to a Type 1 outline. > > > > A couple of suggestions/requests: > > 1. A lot of Wine users (the majority?) will be printing to non- > PostScript printers via Ghostscript. In this situation, embedding > the TrueType font in the output is unnecessary, as long as the > user has made Ghostscript aware of the font. Please enable the > user to turn font embedding off. I'm not sure how to neatly do this. I suppose the user could add the font to the ppd file and the font would then be treated as a builtin font. The cost of download isn't too bad since you only download the glyphs that you use and not the whole font file. > 2. Please don't disable the current (very kludgy) method of printing > TrueType fonts. Client-side font rendering is definitely the way > to go, but it currently causes Wine to crash on my system. Until > client-side rendering stabilizes, I (and others) need to use X- > based fonts but print TrueType fonts. Sounds like we need to fix the bug then. Could you open a bugzilla bug and include a +xrender,+font log? Thanks, Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Asian characters printing - not supported
On Wed, May 22, 2002 at 12:52:10PM +0800, leanne wrote: > Dear all, > > We tried to print Chinese on notepad but failed. > We found that WINE default only writes western characters > to postscript. Is that true? This doesn't solve your problem immediately but... We've been working quite hard on making improvements to the PostScript driver and now have code that should print any character that can be displayed on the screen (assuming you're using client side font rendering anyway). The code downloads the TT font to the printer as either Type 42 (TT wrapped in PostScript) or for older printers the font gets converted to a Type 1 outline. It needs a little more work before we submit it to winehq so please bear with us for a bit. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Fix for commdlg on Mingw
On Mon, May 13, 2002 at 07:01:56PM +0900, Dmitry Timoshkov wrote: > "Steven Edwards" <[EMAIL PROTECTED]> wrote: > > > And they say ignorance is bliss. I didn't really think about that and > > I was just looking at ntdll and msvcrt differences today. What would be > > proper > > Way to fix this? Once I have the idea, I can do the patches for the > > rest. > > I believe that ntdll should be used as a C run-time replacement as much > as possible, especially in the light of a more and more wide use of unicode > in Wine and necessity to have a direct way to manipulate unicode strings > and data. > > The only question I have: in what header file all those ntdll C run-time > functions should be prototyped? It seems that NT DDK does not have an answer > on that question. Last time I asked Alexandre this, he suggested ntddk.h . So that's where I put wcstol(). Huw.
Re: Attn: component owners list
On Thu, May 09, 2002 at 10:28:38AM -0700, Andriy Palamarchuk wrote: > * Huw Davies - TrueType support, printing Works for me. > Available components: > * gdi You can put me down for this too if you like. Huw.
Re: "Please report this"
On Thu, May 02, 2002 at 02:59:02PM -0700, Medland, Bill wrote: > err:clipping:CLIPPING_UpdateGCRegion. hVisRgn is zero. Please report this. > > Duly reported. > > Anyone know why we cared? It's been in the code since the initial revision. Due to Alexandre's recent dll separation changes. psdrv doesn't need an hVisRgn anyway, all it needs is a ClipRgn. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: xrender patch
On Thu, May 02, 2002 at 10:17:32AM -0400, Michael Cardenas wrote: > On Thu, May 02, 2002 at 12:04:04PM -0500, Jeremy White wrote: > > > That does fix it, though I was getting used to the client side fonts :( > > > What version of XFree86 is needed to get a good xrender? I am running > > > version 4.1.0. > > > > You need 4.2.0. You can also just build libXrender.so, > > Do you mean that he needs 4.2.0 just to get a good xrender? I've been > getting a lot of X errors lately, is that because I'm using 4.1.0.1 > ? He needs 4.2.0 or he can just build libXrender.so from 4.2.0 Huw. -- Huw Davies [EMAIL PROTECTED]
Re: xrender patch
On Wed, May 01, 2002 at 09:02:00PM -0700, Duane Clark wrote:
> The xrender CVS patch of 4/23 is causing one of my apps to crash:
>
> Unhandled exception: page fault on read access to 0x in 32-bit
> code (0x438198ee).
> In 32-bit mode.
> Symbol h_errno is invalid
> Symbol __strtol_internal is invalid
> 0x438198ee (_end+0x2ce2726 in libXrender.so): movl 0x0(%eax),%eax
> Wine-dbg>bt
> Backtrace:
> =>0 0x438198ee (_end+0x2ce2726 in libXrender.so) (ebp=405b60c4)
>1 0x40af71cf (X11DRV_XRender_ExtTextOut+0x1103(physDev=0x40399e44,
> x=0x0, y=0x2c, flags=0x0, lprect=0x0, wstr=0x4039a6b0, count=0xc,
I think you have a buggy version of libXrender.so. Could you check
that this patch stops the crash? Unfortunately it will disable client
side font rendering. Jeremy came up with a truely horrible hack to
workaround this problem but for some reason that I can't possibly
imagine Alexandre left it out when he committed the last xrender
changes .
Huw.
--
Huw Davies
[EMAIL PROTECTED]
Index: dlls/x11drv/xrender.c
===
RCS file: /home/wine/wine/dlls/x11drv/xrender.c,v
retrieving revision 1.6
diff -u -r1.6 xrender.c
--- dlls/x11drv/xrender.c 3 Apr 2002 22:08:27 - 1.6
+++ dlls/x11drv/xrender.c 2 May 2002 08:27:58 -
@@ -95,6 +95,14 @@
X11DRV_XRender_Installed = TRUE;
TRACE("Xrender is up and running error_base = %d\n", error_base);
screen_format = TSXRenderFindVisualFormat(gdi_display, visual);
+ if(!screen_format) { /* This fails in buggy versions of libXrender.so */
+ WINE_MESSAGE(
+"Wine has detected that you probably have a buggy version\n"
+"of libXrender.so . Because of this client side font rendering\n"
+"will be disabled. Please upgrade this library.\n");
+ X11DRV_XRender_Installed = FALSE;
+ return;
+ };
pf.type = PictTypeDirect;
pf.depth = 1;
pf.direct.alpha = 0;
@@ -102,7 +110,11 @@
mono_format = TSXRenderFindFormat(gdi_display, PictFormatType |
PictFormatDepth | PictFormatAlpha |
PictFormatAlphaMask, &pf, 0);
-
+ if(!mono_format) {
+ ERR("mono_format == NULL?\n");
+ X11DRV_XRender_Installed = FALSE;
+ return;
+ }
glyphsetCache = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(*glyphsetCache) * INIT_CACHE_SIZE);
Re: patch for cups printers
On Mon, Apr 29, 2002 at 03:39:46PM -0400, Michael Cardenas wrote:
> Changelog:
> This patch fixes printing on cups systems that don't have complete lpr
> implementations. It won't affect non cups systems.
>
> It changes the device listed in the registry for cups printers to CUPS:
> instead of LPR: and uses "lp -d" for a cups printer instead of "lpr -P".
>
> +if (!strncmp("CUPS:",pszOutput,4))
> + sprintf(psCmd,"|lp -d%s",pszOutput+4);
s/4/5/ ?
By the way the cups user manual seems to imply that it supplies both
lp and lpr commands. Of course we should probably send jobs to cups
via the cupsPrintFile() api but I guess that can wait.
Huw.
Re: cups support apparently broken
On Mon, Apr 29, 2002 at 09:51:00AM -0400, Michael Cardenas wrote: > On Sat, Apr 27, 2002 at 10:53:20PM +0200, Marcus Meissner wrote: > > Actually I just did a full recompile and I am still able to print. > > (Tested using standard 32bit notepad.exe.) > > I apologize for the erroneous bug report. I didn't have libcupsys2-dev > on my machine. Now that I have that and I did a full recompile, I can > get a print dialog from word with the correct printer description, but > when I click the print button, it doesn't print. > > Printing from notepad doesn't work either, it seems to do something, and > gives me an hourglass that goes away once you move the mouse. I've > attached the output of +psdrv to this email. > > > Are you still using the same test application? Did you compile in CUPS support? > > (ldd winspooldrv.so shoud show libcups.so referenced). > > I usually use word as my test application. > > Crossover office can actually print from word, excel, outlook and ie, > but not notepad. You might want to run with +print,+winspool to check that the job is being piped to the right command. Huw.
Re: The Euro symbol
On Tue, Apr 23, 2002 at 01:37:23PM -0700, Medland, Bill wrote: > I am looking into getting the Euro symbol (Cp1252 0x80 ie U20ac) to display > (and print) from Wine programs. I am running RedHat 7.1. From my quick > literature search it looks to me like it isn't going to be easy. > Am I being too pessimistic? > Are there people out there who have been using it for ages? Hi Bill, If you're using client side TT fonts and the euro symbol glyph is in the fonts then displaying on the XServer should just work. As for printing, I'm working on downloading TT fonts to the printer at the moment which will mean we'll be able to print the thing as well. Huw.
Re: unit test (C) with WINAPIV function
On Tue, Apr 23, 2002 at 09:18:45AM -0700, Medland, Bill wrote:
> Any chance of some help with this?
> static BOOL wsprintfWTest (void)
> {
> WCHAR buf[25];
> static const WCHAR fmt[] = {'%','0','1','0','l','d','\0'};
> WCHAR target[] = {'-','0','0','0','0','0','0','0','0','1'};
target's not '\0' terminated.
> printf ("%p %p\n", buf, fmt);
> ok ((wsprintfW (buf, fmt -1) == 10), "wsPrintfW length failure");
missing a ',' between fmt and -1.
> ok ((lstrcmpW (buf, target) == 0),
> "wsprintfW zero padded negative value failure\n");
>
> return TRUE;
> }
Huw.
Re: ChangeSet ID: 10178643640749867230924828 - oops.
On Sat, Apr 06, 2002 at 10:49:55PM -0500, [EMAIL PROTECTED] wrote: > Log message: > Huw D M Davies <[EMAIL PROTECTED]> > The horizontal dialog base unit is calculated as the straight average > of a-z,A-Z (tmAveCharWidth is supposed to be a weighted average > according to character usage, so we shouldn't use this). > > Good day! > > I don't pay much attention to GUI, or care much about it, but I noticed > this patch causes my app to display a progress bar (?) with the title > folded down into the progress bar, so it looks kind of lame. > > % xx > transferred: > > Without the patch, it looks more like: > > % transferred:xx > > I have no idea what this app looks like in Windows. I have never run it > with Windows, and I have no intention to buy Windows just to see, but I > think we might not want this bit of code to stay exactly as it is. > > I will gladly make any kind of traces you would like to see, or I can > live with it. The app is in fact obsolete win9x, but it is the most > recent version that can work a modem without requiring DUN or RAS or > some dam' thing. Hmmm, I wonder if a more recent version has the same > problem? Let me check... Hi Lawson, Are you using client side or server side (X11) fonts ? Huw.
Re: wine/objects text.c
On Sat, Apr 06, 2002 at 11:51:12AM +0900, Dmitry Timoshkov wrote: > "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote: > > > On April 5, 2002 07:37 pm, Alexandre Julliard wrote: > > > Log message: > > > Huw D M Davies <[EMAIL PROTECTED]> > > > Spout a FIXME if we try to call ExtTextOut on an open path. > > > > FIXME what? Is there some unimplemented functionality, or is it just illegal > > to call ExtTextOut on an open path? > > It's completely legal to do: > > BeginPath(hDC); > ExtTextOut(hDC, ...); > EndPath(hDC); > StrokePath(hDC); > > to get an outlined text output. Yup, this is what Word 2000 uses to get the 'Outline' effect you can select in Format->Font. Wine doesn't implement it yet hence the FIXME. It would essentially mean writing another ExtTextOut clone that gets the outlines of the glyphs and adds them to the path, as well as doing all the other stuff that ExtTextOut does. Huw.
Re: dynamic .fon conversion
On Tue, Apr 02, 2002 at 11:38:53PM +0900, Dmitry Timoshkov wrote: > "Huw D M Davies" <[EMAIL PROTECTED]> wrote: > > > >Now, IIRC (Huw will correct me if I'm wrong), it was said that > > > FreeType also supports Postscript fonts and .fon fonts. So the way to go > > > would be to extend Wine's FreeType support to .fon fonts. > > > > Yes, that's the idea. At the moment we ignore any font that isn't > > sfnt format (that's anything that isn't TT or OpenType). The issues > > are that we need to implement something sensible for GetGlyphOutline > > and GetOutlineTextMetrics for bitmap or Type1 fonts. > > I would expect that for at least very first time that functions will > fail for bitmap fonts and return glyph data in GGO_BEZIER format for > Type1 fonts. Later we can add cubic <-> quadratic spline conversion > routines and some special handling for bitmap fonts. Most applications > don't use or provide advanced vector graphics at all. As a side effect > of adding support for bitmap fonts will be retired x11drv font support. > and a possibility for real WYSIWYG in printing. For bitmap fonts to be useful GetGlyphOutline will have to return the bitmaps for GGO_BITMAP (this probably isn't what Windows does, but I think we can live with the difference). Of course once we do it for .fon's then .pcf/.bdf come almost for free. Actually I expect the hard bit is getting the TEXTMETRICs right. Huw.
Re: dynamic .fon conversion
On Sat, Mar 30, 2002 at 02:08:37AM -0800, Francois Gouget wrote: > On Sat, 30 Mar 2002, David Chow wrote: > > > Hi, > > > > I am new to Wine develop, I wish to investigate and join, the following > > is the topic I am interested in. > > > > Does Wine develpers planning to implement .fon files support? I mean > > loading it dynamically? Since Xfree86 4 supports true type fonts, and > > most of the Linux distribution are now using XFree86-4 . We can actually > > load these fonts into the Xsever dynamically at run time providing we > > have some dynamic conversion between the font files. > >This issue was raised during WineConf. Wine is now able to use > FreeType to perform client-side rendering of TrueType fonts. This > results in fonts that look really great, and you can even get > anti-aliasing. >Now, IIRC (Huw will correct me if I'm wrong), it was said that > FreeType also supports Postscript fonts and .fon fonts. So the way to go > would be to extend Wine's FreeType support to .fon fonts. Yes, that's the idea. At the moment we ignore any font that isn't sfnt format (that's anything that isn't TT or OpenType). The issues are that we need to implement something sensible for GetGlyphOutline and GetOutlineTextMetrics for bitmap or Type1 fonts. Huw.
Re: OT: Buggy fonts
On Tue, Mar 26, 2002 at 08:35:51AM -0800, Duane Clark wrote: > Huw D M Davies wrote: > > On Mon, Mar 25, 2002 at 08:26:31PM -0800, Duane Clark wrote: > >>The other problem I ran across is shown in these pictures, showing > >>server and client side rendering. My little hack above had no effect on > >>this particular problem. > >>http://www.leewardfpga.com/server.png > >>http://www.leewardfpga.com/client.png > >> > >>As can be seen, the vertical text is getting chopped off slightly. > > > > > > As Francois says this maybe a FreeType bug (versions < 2.0.6 have > > errors calculating the advance width of certain glyphs. If you could > > upgrade FreeType and test again that would be very helpful, if it's > > still a problem we'll take it from there. > > I was using FreeType 2.0.6, but I went ahead and upgraded to 2.0.9. It > still looks the same though (slightly cut off). Could you send me a --debugmsg +relay=gdi32,+font,+xrender,+text log for this please? Thanks, Huw.
Re: OT: Buggy fonts
On Mon, Mar 25, 2002 at 08:26:31PM -0800, Duane Clark wrote: > Huw D M Davies wrote: > > A much better way to do font rendering in Wine is to use the new > > client side rendering code. For this you need an XServer capable of > > supporting the RENDER extension (xdpyinfo will tell you whether you > > have such a beast) and a copy of the FreeType library version at least > > 2.0.5 (but the later the better). Add a [FontDirs] section to your > > ~/.wine/config file, with entries pointing at any directories that > > contain TT fonts... > > This got me to try out the client side rendering. Good, that was the idea :) > I came across two issues. The first is that virtually all dialogs and > some windows were being drawn too narrow. The window/dialog height was > normal. Actaully it's the code that calculates the size of the dialog units that's wrong. Give me a couple of days and I'll dig out my patch. > The other problem I ran across is shown in these pictures, showing > server and client side rendering. My little hack above had no effect on > this particular problem. > http://www.leewardfpga.com/server.png > http://www.leewardfpga.com/client.png > > As can be seen, the vertical text is getting chopped off slightly. As Francois says this maybe a FreeType bug (versions < 2.0.6 have errors calculating the advance width of certain glyphs. If you could upgrade FreeType and test again that would be very helpful, if it's still a problem we'll take it from there. Thanks, Huw.
Re: OT: Buggy fonts
On Mon, Mar 25, 2002 at 01:20:03PM +0100, Uwe Bonnes wrote: > >>>>> "Huw" == Huw D M Davies <[EMAIL PROTECTED]> writes: > > Huw> at least 2.0.5 (but the later the better). Add a [FontDirs] > Huw> section to your ~/.wine/config file, with entries pointing at any > Huw> directories that contain TT fonts > > Huw> eg [FontDirs] "dir1"="/usr/X11R6/lib/X11/fonts/TT" > Huw> "dir2"="/usr/share/fonts/TT" etc... > > Should the /font directory be listed in the FontsDirs Directory > too? No, it'll be searched by default in addition to any dirs listed in [Fontdirs]. Huw.
Re: BiDi support
On Mon, Mar 25, 2002 at 01:49:51PM +0200, Shachar Shemesh wrote: > >For simple bidi support you probably need to implement > >GetCharacterPlacement. (ExtTextOut has had some basic R->L support > >added to it only from Windows 2000). > > > I only tested this on Windows 2000, but on it ExtTextOut correctly > renders R->L characters, unless some of the flags are set (for example, > the flags that tells it that all language processing is already done. > But you'll probably find most programs don't rely on this and call GetCharacterPlacement to do the re-ordering, then pass the string in display order to ExtTextOut. So I'd have thought that the easiest thing to do would be to implement GetCharacterPlacement and have ExtTextOut call this if ETO needs to do reording. > One thing that I don't know how to make work is changing the default > codepage for a WINE application. Is that directly affected from the Unix > one? If not, how do I configure it? > > Like I said, I got DrawTextW to print Hebrew characters, but not > DrawTextA. I suspect that it interpreted the chars as ISO 8859-1, and > therefor printed accented latin. From my understanding of the Wine code, > this is not due to the X codepage, as Wine calls ExtTextOut for all its > text output, and ExtTextOutA simply converts to Unicode and calls > ExtTextOutW. > > I still feel like a novice in this area, as there are some pretty basic > stuff about Wine I feel I don't know. I am slowly getting up to speed to > be able to do this properly and with as little impact on the rest of the > code as possible. This doesn't quite answer you question, but if you do a CreateFontIndirect with lf.lfCharSet == HEBREW_CHARSET then calling ExtTextOutA should work as expected. [It looks to me like DrawTextA is broken. It simply does a MultiByteToWideChar using CP_ACP, I'd have guessed it should use the font's charset instead (equivalently it should call ExtTextOutA). I haven't tested this under Windows though so I could be wrong]. Huw.
Re: OT: Buggy fonts
On Mon, Mar 25, 2002 at 10:27:47AM +, Russell Howe wrote: > I'm afraid this is a little off-topic, but every time Wine starts, as it > builds the font metrics, xfs-xtt (the font server) dies. I'm assuming > there's a font (or few) in the system which it doesn't like, or which > are corrupt. > > It makes wine rather annoying to use (and means that if I kill wine and > restart the font server, it thinks the metrics are already done and > ignores most of my fonts!) > > Does anyone know an easy way to find out which fonts they are? Try deleting ~/.wine/cachedmetrics* , re-run wine with --debugmsg +font, the last font that gets listed before the crash should be the problem one. A much better way to do font rendering in Wine is to use the new client side rendering code. For this you need an XServer capable of supporting the RENDER extension (xdpyinfo will tell you whether you have such a beast) and a copy of the FreeType library version at least 2.0.5 (but the later the better). Add a [FontDirs] section to your ~/.wine/config file, with entries pointing at any directories that contain TT fonts eg [FontDirs] "dir1"="/usr/X11R6/lib/X11/fonts/TT" "dir2"="/usr/share/fonts/TT" etc... Huw.
Re: BiDi support
On Wed, Mar 20, 2002 at 05:51:47PM +0200, Shachar wrote: > Hi all, > > I am new to the mailing list. I am interested in helping out with > BiDirectional (Hebrew and Arabic) support. Is anyone currently working > on it? Are there any leads? I am quite willing to get a from scratch go > at it, but I don't want to fork the effort. Hi Shachar, Assuming you're using client side rendered fonts then most of the font support for Hebrew/Arabic/whatever should be in the tree, so that you should be able to render any glyph with a Unicode point that exists in the font (I'd like to konw of any problems you find in this direction). For simple bidi support you probably need to implement GetCharacterPlacement. (ExtTextOut has had some basic R->L support added to it only from Windows 2000). There's a Unicode standard bidi ordering algorithm explained in the Unicode book, probably we can borrow the code for this from a library like pango or freebidi. For more advanced text layout M$ has its Unscribe library see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/uniscrib_35k5.asp I'm very interested in getting non-roman languages working, so if you need any help please let me know. Huw.
Re: Wine engine fix
On Fri, Mar 22, 2002 at 10:16:09PM +0100, Andreas Mohr wrote: > On Fri, Mar 22, 2002 at 09:55:35PM +0100, Eric Pouech wrote: > > "Dimitrie O. Paun" a écrit : > > > > > > On March 22, 2002 02:58 pm, Eric Pouech wrote: > > > > usually fixed fonts are in MODERN family > > > [...[ > > > > +if (ptm->tmPitchAndFamily & TMPF_FIXED_PITCH) > > > > +ptm->tmPitchAndFamily |= FF_ROMAN; > > > > +else > > > > +ptm->tmPitchAndFamily |= FF_MODERN; > > > > > > Shouldn't this be the other way around? > > > > no... the TMPF_FIXED_PITCH is a f m API > > TMPF_FIXED_PITCH is set when the font isn't fixed... go figure > Well, then maybe better add a comment so that everyone never fails > to see this. There is one about 5 lines above this patch... [actually I have a better patch than this that uses the panose data to get the correct FF_* info, but that's another story] Huw.
Re: Font issue
On Sun, Feb 10, 2002 at 12:26:42PM +0100, Eric Pouech wrote:
> > Yes, we shouldn't enum X11 fonts if freetype/xrender is enabled. I'll
> > submit a patch for this soon.
>
> there's more than that. requesting a fixed pitch font should really
> return
> such a font... here's what I get (for the default fixed pitch hard wired
> to Courier New), widths gottent from GetCharExtent32 and compared to
> average width
> Char 1 (!) has wrong width: 10
> Char 2 (") has wrong width: 10
> Char 4 ($) has wrong width: 12
> Char 5 (%) has wrong width: 12
> Char 7 (') has wrong width: 10
> Char 10 (*) has wrong width: 10
> Char 11 (+) has wrong width: 12
> Char 14 (.) has wrong width: 10
> Char 15 (/) has wrong width: 10
> Char 16 (0) has wrong width: 10
> Char 17 (1) has wrong width: 10
> Char 21 (5) has wrong width: 12
> Char 23 (7) has wrong width: 10
> Char 24 (8) has wrong width: 10
>
> I tested it on windows 98 & nt2K and their TT fixed font really have a
> fixed
> pitch... (this the main reason for current rather strange output in
> wineconsole)
> however, the max char width is (at least on the fonts I tested on
> Windows)
> he average + 1 (which I don't really understand)
Yeah, I need to do something different with fixed pitched fonts. I'll look
into it.
Incidently the font enum logic in wineconsole will need to be changed
to cope with scalable fonts (you should give the user the ability to
pick the font size rather than just display the enumerated values).
> finally, when returing a fixed pitch font, it would be better
> to set the family to Modern rather than Roman
Yes, I've got a patch that correctly sets the tmPitchAndFamily field
in GetTextMetrics (and also therefore in EnumFontFamiliesEx).
Huw.
Re: Font issue
On Sat, Feb 09, 2002 at 05:44:55PM +0100, Eric Pouech wrote: > latest freetype patch severly breaks Wine: > - behavior between Windows TT fonts and X11 font isn't orthogonal. For > example, EnumFont can return X11 fonts, while realizing a font never > let you use a X11 font > - this leads to very interesting effects like asking for a fixed pitch > font and getting a variable pitch one > > so what would be the best fix ? either remove all X11 fonts in enum, > or allow X11 fonts to be realized even if freetype is enabled ? > any volunteer to fix it ? Yes, we shouldn't enum X11 fonts if freetype/xrender is enabled. I'll submit a patch for this soon. Huw.
Re: treeview2.c
On Thu, Jan 31, 2002 at 03:40:04PM -0600, Aric Stewart wrote: > Why where we setting the items text to NULL on GetItemW. > > This appears to implement what the person was trying to do within the if > 0 block. > > Changelog: fix to GetItemW to stop whipping out the items text > > -aric > Index: dlls/comctl32/treeview.c > === > RCS file: /home/wine/wine/dlls/comctl32/treeview.c,v > retrieving revision 1.95 > diff -u -u -r1.95 treeview.c > --- dlls/comctl32/treeview.c 2001/12/11 00:15:11 1.95 > +++ dlls/comctl32/treeview.c 2002/01/31 19:38:37 > @@ -1970,18 +1970,19 @@ ... > +MultiByteToWideChar(CP_ACP, 0, wineItem->pszText, > +strlen(wineItem->pszText), tvItem->pszText, > +tvItem->cchTextMax); Hi Aric, This won't copy the terminating '\0'. It'd be better to use -1 instead of the strlen. Huw.
Re: Compilation errors for Freetype support
On Thu, Jan 31, 2002 at 04:34:02PM +, Huw D M Davies wrote: > I'll add a configure test for the trig functions and disable FreeType > support if they're not present - there are other issues with 2.0.1 > that make it unusable anyway. How does this look? Huw. Index: configure.in === RCS file: /home/wine/wine/configure.in,v retrieving revision 1.253 diff -u -r1.253 configure.in --- configure.in2002/01/29 18:09:47 1.253 +++ configure.in2002/01/31 15:24:05 @@ -420,11 +420,13 @@ freetype/internal/sfnt.h) AC_TRY_CPP([#include #include ], -AC_DEFINE(HAVE_FREETYPE_FTTRIGON_H, 1, - [Define if you have the header file.])) +[AC_DEFINE(HAVE_FREETYPE_FTTRIGON_H, 1, + [Define if you have the header file.]) +wine_cv_fttrigon=yes], +wine_cv_fttrigon=no) CPPFLAGS="$ac_save_CPPFLAGS" dnl Check that we have at least freetype/freetype.h - if test "$ac_cv_header_freetype_freetype_h" = "yes" + if test "$ac_cv_header_freetype_freetype_h" = "yes" -a "$wine_cv_fttrigon" = +"yes" then AC_DEFINE(HAVE_FREETYPE, 1, [Define if FreeType 2 is installed]) wine_cv_msg_freetype=no @@ -1435,10 +1437,11 @@ then echo echo "*** Note: Your system appears to have the FreeType 2 runtime libraries" - echo "*** installed, but either 'freetype-config' is not in your PATH or" - echo "*** you do not have the FreeType include files. Install the" - echo "*** freetype-devel package (or its equivalent on your distribution) to" - echo "*** enable Wine to use TrueType fonts." + echo "*** installed, but either 'freetype-config' is not in your PATH," + echo "*** you do not have the FreeType include files or you have a version" + echo "*** of FreeType lower than 2.0.3. Install the freetype-devel package" + echo "*** (or its equivalent on your distribution) to enable Wine to use" + echo "*** TrueType fonts." fi echo
Re: Compilation errors for Freetype support
On Thu, Jan 31, 2002 at 07:32:53AM -0800, Bill Medland wrote: > So what ought to be done in the code? > 1. #else #error "This requires freetype 2.0.3 or later" > 2. #else zero degrees> #endif > 3. ifdefs around the use of FT_Angle etc to provide an alternative method of > achieving it or not supporting ot. > > I am interested because I am still trying to get a feel for the typical > thinking in Linux development where there are more independent libraries and > they tend to change more frequently, adding support as they go. Firstly sorry about the delay in replying to these problems; I've had problems with my subscription to wine-devel, things seem to be back to normal now though (thanks Andi!). I'll add a configure test for the trig functions and disable FreeType support if they're not present - there are other issues with 2.0.1 that make it unusable anyway. If you're upgrading then go straight to 2.0.6 - there's a bug in earlier versions that messes up inter-character spacing. Huw.
Re: Windows-format metafiles
On Wed, Oct 17, 2001 at 10:53:18AM -0500, Aric Stewart wrote: > Hello all, > > I am doing so work trying to flesh out he implementation of > SetWinMetaFileBits and as such need documentation on Windows-format > metafiles (not enhanced metafiles i have that) There must exist specs > and documentation from old 3.1 days, but I am having no luck finding it. > > Does anyone have pointers as to where i could find a spec for the > windows format metafiles to help me out? I don't think you want to do it this way. Create a emf dc with CreateEnhMetaFile and play the orig metafile onto it with PlayMetaFile(Record). You may need to trap the odd record before you play it but it should be a lot easier. Huw.
Re: InstallShield 6 again (debuggers requested)
On Mon, Oct 01, 2001 at 12:06:14AM +0200, Ove Kaaven wrote:
> Almost there, here's the current state of the patch, now with more hacks
> than ever before (but you also need the MoveFileEx and DispGetParam
> patches I've submitted to wine-patches). The current showstopper is a bug
> in Wine's SLTG typelib loader (it crashes reading the iuser.dll typelib
> resource). I think that once that typelib bug is fixed, it should only
> have minor issues left, or even work outright... I've already mailed Huw
> about the problem, but if anyone else wants to fix it, *I* don't mind...
For those of you playing along at home, this should fix it. A prettier
solution will be submitted to wine-patches when I become unjetlagged.
Huw.
PS The line nos. will probably be off, but I'm sure the interested will be able
to sort that out.
--- dlls/oleaut32/typelib.c Mon Sep 24 18:55:13 2001
+++ dlls/oleaut32/typelib.c Mon Oct 1 17:07:42 2001
@@ -2399,13 +2401,13 @@
first letter. So let's take one char off paramName and if we're
pointing at an alpha-numeric char. Got that? */
- if(*pArg == 0x) /* If we don't have a name the type seems to
- always follow. FIXME is this correct? */
+ if(*pArg == 0x || *pArg == 0xfffe)
paramName = NULL;
pArg++;
- if(paramName && !isalnum(*(paramName-1))) { /* the next word is an
+
+ if(*(pArg-1) == 0xfffe || (paramName && !isalnum(*(paramName-1 { /*
+the next word is an
offset to type */
pType = (WORD*)(pFirstItem + *pArg);
SLTG_DoType(pType, pFirstItem,
Re: Better font charset handling
On Fri, Sep 21, 2001 at 03:46:29PM +0200, Nerijus Baliunas wrote: > On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <[EMAIL PROTECTED]> wrote: > > HDMD> Huw D M Davies <[EMAIL PROTECTED]> > HDMD> Use the font charset to obtain a codepage for A->W conversion in the > HDMD> text functions. > > HDMD> Index: objects/text.c > > HDMD> +case VISCII_CHARSET: > HDMD> +case TCVN_CHARSET: > HDMD> +case KOI8_CHARSET: > HDMD> +case ISO3_CHARSET: > HDMD> +case ISO4_CHARSET: > HDMD> +case ISO10_CHARSET: > HDMD> +case CELTIC_CHARSET: > HDMD> + /* FIXME: These have no place here, but becasue x11drv > HDMD> + enumerates fonts with these (made up) charsets some apps > HDMD> + might use them and then the FIXME below would become > HDMD> + annoying. Now we could pick the intended codepage for > HDMD> + each of these, but since it's broken anyway we'll just > HDMD> + use CP_ACP and hope it'll go away... > HDMD> + */ > HDMD> +cp = CP_ACP; > HDMD> +break; > > Why these are here? Because they do not have windows equivalents? > If so, at least KOI8 shouldn't be there (IMHO). AFAIK they're not Windows charsets, somebody has made up some numbers and added them to wingdi.h . The reason they're here at all is because the x11drv enumerates fonts with these charsets and I'm claiming that this is a bug, since no application can be expected to know that these numbers mean. Now there is a RUSSIAN_CHARSET and this gets handled by the TranslateCharsetInfo before the switch. Huw.
Re: GDI_CheckNotLock strikes again
On Fri, Sep 14, 2001 at 09:43:39AM +0900, Dmitry Timoshkov wrote: > "Huw D M Davies" <[EMAIL PROTECTED]> wrote: > > > Does this help? > > Yes, it does. But application (a heavily modified MS glyph sample > from 1993) doesn't show anything. I could send you the source code > if you are interested to fix it. It won't at the moment. Currently no driver in the cvs attempts to use gdi fonts, so the new code is never called. [working on it]. Huw.
Re: GDI_CheckNotLock strikes again
On Thu, Sep 13, 2001 at 05:49:56PM +0900, Dmitry Timoshkov wrote:
> Hello.
>
> Decided to try sample program which uses GetGlyphOutline.
>
> Backtrace:
> =>0 0x400d2ae1 (_CheckNotSysLevel+0x51(lock=0x407bb6a4) [syslevel.c:153] in
>libntdll.so) (ebp=405b6734)
> 1 0x407a2667 (GDI_CheckNotLock+0x1b [gdiobj.c:446] in libgdi32.so) (ebp=405b6744)
> 2 0x40798a1c (DeleteDC+0x48(hdc=0x8bc) [dc.c:784] in libgdi32.so) (ebp=405b6764)
> 3 0x407983b9 (RestoreDC+0x13d(hdc=0x8a0, level=0x1) [dc.c:541] in libgdi32.so)
>(ebp=405b6790)
> 4 0x4078ba4b (PATH_StrokePath+0x28b(dc=0x403a1640, pPath=0x403a16a0) [path.c:1511]
>in libgdi32.so) (ebp=405b67b4)
Does this help?
Huw.
Index: graphics/path.c
===
RCS file: /home/wine/wine/graphics/path.c,v
retrieving revision 1.22
diff -u -r1.22 path.c
--- graphics/path.c 2001/07/02 19:59:48 1.22
+++ graphics/path.c 2001/09/13 14:53:04
@@ -1465,6 +1465,11 @@
{
INT i;
POINT ptLastMove = {0,0};
+POINT ptViewportOrg, ptWindowOrg;
+SIZE szViewportExt, szWindowExt;
+DWORD mapMode, graphicsMode;
+XFORM xform;
+BOOL ret = TRUE;
if(dc->funcs->pStrokePath)
return dc->funcs->pStrokePath(dc);
@@ -1472,10 +1477,20 @@
if(pPath->state != PATH_Closed)
return FALSE;
-SaveDC(dc->hSelf);
+/* Save the mapping mode info */
+mapMode=GetMapMode(dc->hSelf);
+GetViewportExtEx(dc->hSelf, &szViewportExt);
+GetViewportOrgEx(dc->hSelf, &ptViewportOrg);
+GetWindowExtEx(dc->hSelf, &szWindowExt);
+GetWindowOrgEx(dc->hSelf, &ptWindowOrg);
+GetWorldTransform(dc->hSelf, &xform);
+
+/* Set MM_TEXT */
SetMapMode(dc->hSelf, MM_TEXT);
SetViewportOrgEx(dc->hSelf, 0, 0, NULL);
SetWindowOrgEx(dc->hSelf, 0, 0, NULL);
+
+
for(i = 0; i < pPath->numEntriesUsed; i++) {
switch(pPath->pFlags[i]) {
case PT_MOVETO:
@@ -1495,20 +1510,36 @@
if(pPath->pFlags[i+1] != PT_BEZIERTO ||
(pPath->pFlags[i+2] & ~PT_CLOSEFIGURE) != PT_BEZIERTO) {
ERR("Path didn't contain 3 successive PT_BEZIERTOs\n");
- return FALSE;
+ ret = FALSE;
+ goto end;
}
PolyBezierTo(dc->hSelf, &pPath->pPoints[i], 3);
i += 2;
break;
default:
ERR("Got path flag %d\n", (INT)pPath->pFlags[i]);
- return FALSE;
+ ret = FALSE;
+ goto end;
}
if(pPath->pFlags[i] & PT_CLOSEFIGURE)
LineTo(dc->hSelf, ptLastMove.x, ptLastMove.y);
}
-RestoreDC(dc->hSelf , -1);
-return TRUE;
+
+ end:
+
+/* Restore the old mapping mode */
+SetMapMode(dc->hSelf, mapMode);
+SetViewportExtEx(dc->hSelf, szViewportExt.cx, szViewportExt.cy, NULL);
+SetViewportOrgEx(dc->hSelf, ptViewportOrg.x, ptViewportOrg.y, NULL);
+SetWindowExtEx(dc->hSelf, szWindowExt.cx, szWindowExt.cy, NULL);
+SetWindowOrgEx(dc->hSelf, ptWindowOrg.x, ptWindowOrg.y, NULL);
+
+/* Go to GM_ADVANCED temporarily to restore the world transform */
+graphicsMode=GetGraphicsMode(dc->hSelf);
+SetGraphicsMode(dc->hSelf, GM_ADVANCED);
+SetWorldTransform(dc->hSelf, &xform);
+SetGraphicsMode(dc->hSelf, graphicsMode);
+return ret;
}
wcs* functions within Wine
Hi, I want to use wcsrchr and wcstrol in oleaut32.dll . If I just use them then we do indeed call the ntdll versions rather than libc which is all very nice. The question is, what include file am I supposed to use to get their protoypes? Huw.
Re: Is this a bug?
On Tue, Jun 05, 2001 at 06:12:27PM -0500, Ian Pilcher wrote:
> While poking around in gdi.h, I came upon the following:
>
> static inline INT WINE_UNUSED INTERNAL_YWSTODS(DC *dc, INT height)
> {
> FLOAT floatHeight;
>
> /* Perform operation with floating point */
> floatHeight = (FLOAT)height;
> INTERNAL_XWSTODS_FLOAT(dc, &floatHeight);
>
> /* Round to integers */
> return GDI_ROUND(floatHeight);
> }
>
> Shouldn't one of these (probably INTERNAL_YWSTODS) be calling
> INTERNAL_YWSTODS_FLOAT instead of INTERNAL_XWSTODS_FLOAT?
Yes, well spotted. This one should indeed be calling
INTERNAL_YWSTODS_FLOAT [This stuff is a mess anyway, but that's a
different sotry...].
Huw.
Re: FreeType autoconf checks - please test
On Thu, May 31, 2001 at 10:02:55AM -0500, Ian Pilcher wrote: > This works on my system (Red Hat 7.1 with FreeType 2.0.1). Please try > it on other variants and let me know if it works. Ian, Looks good with freetype 2.0.3 (and RH 7.1). It's not an offical rpm though, I just dropped the 2.0.3 tarball into the build directory and tweaked the spec file a little. Huw.
Re: wineps include fix.
Actually aren't you supposed to do this? #include #include FT_FREETYPE_H #include FT__H Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: Make PostScript driver less loquacious
On Wed, Apr 04, 2001 at 02:16:49AM +0600, Ian Pilcher wrote: > Dmitry Timoshkov wrote: > > > > I would agree with you, if you have added all regular possible values listed > > in wine/include/wingdi.h and only then replaced FIXME's by WARN's. > > Well, the only paper size missing is DMPAPER_11X17, presumable because > it isn't mentioned in Adobe's documentation. > > For the bin types, if someone can tell me how to map the following PPD > file bin types, I'll do it: The fallback should be to map unmapped names to DMBIN_USER, DMBIN_USER+1, etc... This is what the FIXME is now telling us to do ;) Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: winspool.drv initialization problem
On Mon, Feb 26, 2001 at 11:07:27PM +0600, Ian Pilcher wrote: > Any idea when Windows loads printer drivers? Usually on CreateDC/IC or OpenPrinter. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: VerQueryValue[A|W]
On Thu, Feb 15, 2001 at 01:03:28AM -0500, James Hatheway wrote: > > I guess logically, it should be converted, but I'm still > > trying to work out which function to use. > > Hi Lawson, > > To convert an ASCII string to Unicode, you can use the > function HEAP_strdupAtoW, as in: > > wide_str = HEAP_strdupAtoW(GetProcessHeap(), 0, AsciiStr); Please don't. Use the win32 api instead, eg: INT len; len = MultiByteToWideChar(CP_ACP, 0, AsciiStr, -1, NULL, 0); wide_str = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); MultiByteToWideChar(CP_ACP, 0, AsciiStr, -1, wide_str, len); HeapFree(GetProcessHeap(), 0, wide_str); Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: AFM-Handling problem
On Mon, Feb 12, 2001 at 01:56:09PM +0100, Joerg Mayer wrote:
> Moin,
>
> Marcus last patch to add default paths for afm files triggered a bug:
> Inside my font dirs, there is a directory that contains gzipped afm
> files. After I unzipped these files, wine started up again. Not nice.
How about something like this?
[We should also make the afm parsing robust against non-afm files].
Huw.
--
Dr. Huw D M Davies | Clarendon Laboratory
[EMAIL PROTECTED] | Parks Road
Tel: +44 1865 272390| Oxford OX1 3PU
Fax: +44 1865 272400| UK
Index: dlls/wineps/afm.c
===
RCS file: /home/wine/wine/dlls/wineps/afm.c,v
retrieving revision 1.5
diff -u -r1.5 afm.c
--- dlls/wineps/afm.c 2001/02/12 01:25:46 1.5
+++ dlls/wineps/afm.c 2001/02/12 13:23:46
@@ -430,7 +430,8 @@
if (dir) {
struct dirent *dent;
while ((dent=readdir(dir))) {
- if (strstr(dent->d_name,".afm")) {
+ int len = strlen(dent->d_name);
+ if (len > 4 && !strcmp(dent->d_name + len - 4 ,".afm")) {
char *afmfn;
afmfn=(char*)HeapAlloc(GetProcessHeap(),0,strlen(afmdir)+strlen(dent->d_name)+1);
Re: Misc / Unicode
On Mon, Feb 05, 2001 at 08:51:45PM -0800, Francois Gouget wrote:
> Index: include/richedit.h
> ===
> RCS file: /home/cvs/wine/wine/include/richedit.h,v
> retrieving revision 1.4
> diff -u -r1.4 richedit.h
> --- include/richedit.h2001/01/22 19:25:27 1.4
> +++ include/richedit.h2001/01/29 11:01:27
> @@ -15,7 +15,7 @@
> #define cchTextLimitDefault 0x7fff
>
> #define RICHEDIT_CLASS20A"RichEdit20A"
> -#define RICHEDIT_CLASS20WL"RichEdit20W"
> +static const WCHAR RICHEDIT_CLASS20W[] = {
>'R','i','c','h','E','d','i','t','2','0','W' };
Doesn't this want a trailing 0 ?
Huw.
--
Dr. Huw D M Davies | Clarendon Laboratory
[EMAIL PROTECTED] | Parks Road
Tel: +44 1865 272390| Oxford OX1 3PU
Fax: +44 1865 272400| UK
Re: psdrv: map Courier New to Courier
On Mon, Feb 05, 2001 at 01:31:08AM +0600, Ian Pilcher wrote: > Huw D M Davies wrote: > > > > We don't need to worry about compatibility with the native drivers to > > this extent (this data is private to the driver), I was just using > > this as an example to how a native driver does save its data. > > I'm glad you feel that way. I've implemented it as: > > [...\Printers\\PrinterDriverData\FontSubTable] > = > = > . > . > . > > > It doesn't matter: TTFontSubTable is what the native M$ driver uses, > > but we can use anything you like. Calling OpenPrinter is fine within > > the driver - it only really retrieves a printer handle. > > Well, I couldn't get GetPrinterData to work. The driver would compile > OK, > but Wine was unable to load the driver, because it couldn't resolve the > 'GetPrinterData' symbol. (Probably something I did wrong.) You'd need to add the line import winspool.drv to wineps.spec Actually since you're storing the data as many values under a separate key would you mind moving the key to [..\Printers\\FontSubTable] (i.e. get rid of the PrinterDriverData elememt), this will mean the GetPrinterDataEx will still be able to access the data (I really think that we should eventually use these APIs as hard coding the ..\Printers\ bit into the driver offends me ;) ). > Is it actually possible to just go in and edit them? I always figured > those numbers at the end of the key names were some sort of checksums > that would get messed up. The numbers are modification times, so it's safe to play with the values. > I was also under the impression that we would actually be reading the > font substitution table from the Windows PostScript driver. Since those > substitutions might not be appropriate for the Wine environment, I felt > it was important to provide the user with a way to override them. As > long as we keep WINEPS's data private, I agree. No (or is that Yes?), this is definitely private to a given instance of wineps.drv. > I absolutely agree. I see the manual mapping of X fonts to Windows > font names as an interim step in that direction. > > While I was playing with the registry, I moved the PPD file > specification > into the PrinterDriverData key, so the driver should support multiple > printers fairly well. Good. Actually it's hacked into the Devmode too, but this is ugly and I'll get rid of it. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: psdrv: map Courier New to Courier
On Sat, Feb 03, 2001 at 04:18:45PM +0600, Ian Pilcher wrote: > I just spent some time poking around in the Registry of my Windows 2000 > system. Neither "TTFontSubTable" or "FontSubTable" appears anywhere. > (I have printers installed that use both the Adobe and Microsoft Post- > Script drivers.) Try changing an entry in the font sub table. The driver doesn't write anything until you move anyway from the default. > Another point of interest -- none of the printer properties dialogs seem > to allow me to configure the font substitution, even though I have > "TrueType Font: Substitute with Device Font" set in the Advanced Options > of the Apple LaserWriter 12/640 PS driver. My LaserJet 4/4M driver allows you to edit the table in the Device Settings tab of the Property dailog got by going to Control Panel -> Printers, selecting the printer and then doing Printer->Properties. We don't need to worry about compatibility with the native drivers to this extent (this data is private to the driver), I was just using this as an example to how a native driver does save its data. > So is "FontSubTable" what we want to use? It should be easy enough for > me to have the driver use GetPrinterData and set up a simple array when > it is initialized. (Although it does seem a little weird to have the > driver calling OpenPrinter; is this OK?) It doesn't matter: TTFontSubTable is what the native M$ driver uses, but we can use anything you like. Calling OpenPrinter is fine within the driver - it only really retrieves a printer handle. > > Not really convinced about this. I'd like to move all of the psdrv > > stuff out of the config file (which afterall is just a bit of the > > registry) into its correct place under > > HKLM\System\CurrentControlSet\Control\Printers\Print > > The configuration should all be done via a GUI control. > > Two points: > > 1) How can a user get this information into the Registry until the GUI > control is written? (I hope you weren't thinking that this is some- > think I'm capable of doing. Me stupid procedural guy; OO GUI stuff > make head feel oogey!) > > 2) Just because people use Wine to run Windows applications, doesn't > mean that they've bought into the "everything should be GUI" > philosophy; some of us actually *like* ASCII configuration files. The Wine registry files are ascii, and adding stuff to the registry can be done via the regapi program anyway. > I actually see a manual font configuration as a *very* small step in > this direction. At least it will let Wine control it's view of what > fonts are available, rather than trying to make intelligent guesses > based on the X font list and the PostScript driver. > > It does assume a certain intelligence on the user's part; mapping the > core Windows fonts to X fonts that aren't installed on the system would > be "bad", but it shouldn't be too hard to supply a reasonable default > configuration. I anticipate that most people will just be happy using TT/Type1/.fon fonts all served by FreeType and will not bother using XLFD fonts at all. This makes font configuration quite easy, we just tell the FreeType font driver which font files we want it to serve and that's it. The psdrv may still want to substitute builtin type1 fonts, but that seems to me to be psdrv's role and thus its configuration is unique to that; this becomes more obvious when you think that the user may install 2 instances of psdrv that print to different printers which may have different fontsets installed, therefore font substitution would be on a printer by printer basis. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: PATCH: "Manual" trays for ppd
On Sat, Feb 03, 2001 at 07:21:54PM +0100, Marcus Meissner wrote: > Hi, > > The ppd also has Tray1,Tray2,Tray3 ... Now where should those map to? I think these should go to DMBIN_USER, DMBIN_USER+1, etc. So if the lookup of the standard names fails, we just start allocating bin numbers from DMBIN_USER. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: psdrv: map Courier New to Courier
On Thu, Feb 01, 2001 at 11:19:31PM +0600, Ian Pilcher wrote:
> I think I can probably handle reading the registry. (Although from
> what little I've seen of the Win32 API, even that could be a night-
> mare.)
OK, I've just submitted G|SetPrinterData implementations to
wine-patches - please use these instead of direct Reg apis. (it should
make life easier anyway.
You basically want
HANDLE hprn;
OpenPrinterA("Wine PostScript Driver", &hprn, NULL);
SetPrinterDataA(hprn, "FontSubTable" /*or whatever*/, REG_MULTI_SZ, pData, size);
ClosePrinter(hprn);
where pData is a list of \0 terminated strings that make up the table,
finally terminated by a double \0.
Reading the data back is almost the same using GetPrinterDataA
> I think we should also allow the Wine config file to override what's
> in the registry.
Not really convinced about this. I'd like to move all of the psdrv
stuff out of the config file (which afterall is just a bit of the
registry) into its correct place under
HKLM\System\CurrentControlSet\Control\Printers\Print
The configuration should all be done via a GUI control.
> Which leads me to another, more dangerous, thought. It seems to me that
> life would be simpler for everyone if we could bring some consistency to
> the way that Wine's display and print subsystems work with fonts. What
> about a section in the configuration file that related Windows, X, and
> PostScript font names?
>
> In the old style, I would have suggested something of the form:
>
> Windows Font = X LFD, PostScript font name
>
> This would seem to be relatively straightforward to implement, and it
> would bring a small measure of sanity to the area. (I currently have
> both 'MS Sans Serif' and 'Ms Sans Serif' fonts, because the X server and
> the PostScript driver don't agree on what the font should be called!)
This should all be a lot easier when I get a FreeType engine bolted on
to gdi. Then psdrv,x11drv,ttydrv(?) will all have access to the same
data and thus consistancy should not be a problem.
Huw.
Re: Add "OnlyOne" paper source, used by the Acrobat Distiller PPD
On Sat, Jan 27, 2001 at 11:43:43PM +0800, Dmitry Timoshkov wrote:
> Hello.
>
> Changelog:
> Dmitry Timoshkov <[EMAIL PROTECTED]>
> Add "OnlyOne" paper source, used by the Acrobat Distiller PPD.
>
> --- cvs/wine/dlls/wineps/ppd.cWed May 31 05:27:25 2000
> +++ wine/dlls/wineps/ppd.cSat Jan 27 23:20:01 2001
> @@ -161,6 +161,7 @@
>char *PSName;
>WORD WinBin;
> } BinTrans[] = {
> + {"OnlyOne", DMBIN_ONLYONE},
>{"Cassette", DMBIN_CASSETTE},
>{"Envelope", DMBIN_ENVELOPE},
>{"LargeCapacity", DMBIN_LARGECAPACITY},
>
Any chance of keeping the array in alphabetical order (by the PSName
member)?
Huw.
Re: Poor Man's GDI Object Refcount
On Sun, Jan 14, 2001 at 02:48:21PM -0600, Andreas Mohr wrote: > On Sun, Jan 14, 2001 at 06:45:55PM +0100, Uwe Bonnes wrote: > > Hallo, > > > > as reported yesterday, some application depended on DeleteObject > > failing as long as the Object is stillselected into some DC. Andi also > > noted the need for such a check some time ago. This patch adds an > > entry "refcount" in GDIOBJHDR and increments/decrements this refcount > > in SelectObject and denies DeleteObjects if the refcount isn't zero. > Sorry, this is not correct, I think. > > First, GDIOBJHDR is a *fixed* structure AFAIK. It should not be changed. The header is the same as 16bit GDI at the momenet, however the storage of some of the actual objects is completely different, so I don't think we lose much by breaking this 'compatibility'. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: World transform support for PostScript driver
On Thu, Jan 11, 2001 at 03:31:31PM +0100, Eric Kohl wrote: > > This patch adds partial world transform support to the PS driver > > ChangeLog: > > Eric Kohl <[EMAIL PROTECTED]> > > * dlls/wineps/font.c, > dlls/wineps/graphics.c, > dlls/wineps/pen.c, > dlls/wineps/text.c > Added partial world tranform support to the PostScript driver. Actually this isn't quite right. The World Transform should be honoured whether or not the graphics mode is GM_ADVANCED. You just need to be in GM_ADVANCED to set up the transform. This means that all the mode == GM_ADVANCED checks are redundant and we should just call LPToDP throughout. This applies to the x11drv too (sorry I didn't spot that in time). Huw.
Re: XFree 4.x Render extension
On Wed, Dec 20, 2000 at 08:10:04PM +0100, Lionel Ulmer wrote: > Hi, > > Now that XFree 4.0.2 is out, the new Render extension (more details here : > http://www.xfree86.org/~keithp/render/) will be available on many (most ?) > Linux desktops. > > What could be interesting for Wine is resumed in the X release note : > > "Unlike the core protocol, Render provides no font support for applications, > rather it allows applications to upload glyphs for display on the screen. > This allows the client greater control over text rendering and complete > access to the available font information while still providing hardware > acceleration." > > This could solve many problems Wine has for font displaying. I know this > argument (ie client-side font rendering) was already discussed at length > (and rejected due to the 'remote displaying' argument). But now that the > possibility of client-side glyphs is in the X protocol itself, we could have > the argu^H^H^H^Hdiscussion again :-) Indeed, I've been looking into this. I don't think we ever rejected client-side rendering, it was just noted that there will be a slight hit for remote displays ['slight' because the server will cache the rendered glyph so it's not that bad]. In fact we were probably going to go down the client-side rendering route anyway, XRender now just makes it rather easier. In the next few weeks I'll try to get a Wine internal font-engine api evolved, once we have that we can get a XRender module into the x11drv. Huw.
Re: Proposed change to PostScript driver
On Mon, Dec 11, 2000 at 04:44:23PM +0600, Ian Pilcher wrote:
> Here is a small patch to the WINEPS driver, which uses a case-
> insensitive string comparison to find an appropriate PostScript font.
>
> --- dlls/wineps/font.c-20001026 Sun Aug 20 03:38:55 2000
> +++ dlls/wineps/font.c Fri Oct 27 15:37:52 2000
> @@ -77,7 +77,7 @@
>
> /* Look for a matching font family */
> for(family = physDev->pi->Fonts; family; family = family->next) {
> -if(!strcmp(FaceName, family->FamilyName))
> +if(!strcasecmp(FaceName, family->FamilyName))
> break;
> }
> if(!family) {
Looks good to me, we certainly shouldn't worry about case when
matching font names.
Huw.
--
Dr. Huw D M Davies | Clarendon Laboratory
[EMAIL PROTECTED] | Parks Road
Tel: +44 1865 272390| Oxford OX1 3PU
Fax: +44 1865 272400| UK
Re: DnD cursors
On Mon, Nov 06, 2000 at 09:42:54AM -0500, Jean-Claude Batista wrote: > Hi, > > I just wanted to let you know I'm presently working on a way to bridge Ole > DnD with Xdnd. Are you working only at the OLE level? Go for it; I have one other small patch to go in at the ole level and that'll probably be it. Huw.
Re: open paths, pies and chords
On Wed, Oct 25, 2000 at 12:49:07AM +0200, mark dufour wrote: > The X11DRV_DrawArc() helper function is used to draw arcs, > pies and chords. Now when there is an open path, the lines and arcs > used in these figures have to be added to this path (NT/2000.) This > has not yet been implemented in wine for pies and chords. In the > helper function the coordinates for the figure parts are > calculated. So, it would be possible to add the required path > entries from there. But I don't think graphics drivers should have > anything to do with paths, just with drawing graphics > primitives. But if the path entries aren't added from here, the > coordinates for the entries have to be calculated somewhere else > also ( or be passed in some way. ) A cleaner approach to this I > think would be to move the calculation of the coordinates out of the > graphics driver and into a helper function for WINAPI Arc(), Pie() > and Chord(). Checking for open paths and taking the appropriate > actions is now easily done at this level. This would also make for a > simpler graphics driver, as the coordinate calculations are now done > elsewhere. Is there a reason why this would not be a good approach ? Umm, I'm not sure what you mean. To add Chord and Pie to the path handling you should add PATH_Chord/Pie to graphics/path.c, which will probably call PATH_Arc or something. Treat the path stuff as if it were another graphics driver (cf enhmetafiledrv) - in fact I almost converted to one, but there are some annoying problems in doing so. I don't understand what you mean about coordinate calculation. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: registry tree deletion
On Mon, Sep 18, 2000 at 06:15:09PM +, Andreas Mohr wrote: > Hi all, > > implemented the possibility to delete whole registry trees. > (which you couldn't do before e.g. in regedit) > > I'm a bit frightened by the small size of patch, however. > > Why wasn't it implemented before if it was that easy ? > > Did I miss something obvious ? (or not so obvious, perhaps) Hi Andi, NT's RegDeleteKey doesn't delete the key if it contains subkeys, while win9x's does. To perform a recursive delete under NT you're supposed to call SHDeleteKey or see knowledge base Q142491. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: (Enhanced) - Metafiles
On Thu, Aug 17, 2000 at 02:33:35PM +0200, Klein Andreas wrote: > Hello, > > i´ve got some problems with the display of Metafiles and Enhanced Metafiles > (*.EMF and *.WMF). Does anyone know whether this should work generally or > not ? > > And here are my major problems: > - the EnhMetaHeader of the Metafile (*.WMF) won´t be read correctly. I got > some values in the type and size-members, but nothing in the dimensions or > the device-Informations. This leads to a crash in the > EnumEnhMetaFile-Function (\object\enhmetafile.c) when the dimensions are > calculated (div by zero). > (i put some Debug-Outputs in the wine-source to display the Header-Infos) > - with an EMF-File everything seems correctly, but nothing is displayed. I > got some FIXMEs: Type xx is not implemented > > Running the test-apps with windows, everything is fine. I'm rather confused. What exactly is the problem? Can you give me an example of what doesn't work; your test app prehaps? Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: Managed window title is screwed up
On Wed, Aug 16, 2000 at 11:00:49AM -0700, Alexandre Julliard wrote: > This was already discussed a few months ago; the right fix is to make > the window rectangle (returned by GetWindowRect) distinct from the X > window rectangle. Then the differences between the two rectangles can > be handled entirely in the x11drv, and all the rest of the code can > work with the window rectangle without worrying whether the window is > managed or not. Ah yes, I remember now... Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: Managed window title is screwed up
On Wed, Aug 16, 2000 at 04:42:04PM +0300, Veksler Michael wrote: > That was the general feeling. In that case there are several questions: > 1. What should be done when a client is writing to a non-client area? >It is wrong to put it in the client area (the way it is done now). >Your suggested hack works when the string is few pixels above the >client area, but is makes no sense when it is below. Well what's happening is that in managed mode GetDCEx( DCX_WINDOW) gets a dc with its top starting at the bottom of the window decoration. The apps assumes that the top is the top of the caption and starts drawing on it, so everything appears a caption height too low. Maybe what we should do is to set dc->OrgY to -(caption height). At least this should hide the draw attempts to the caption. If the app used SetWindowText in the first place we wouldn't have this problem ;) Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: Managed window title is screwed up
On Wed, Aug 16, 2000 at 03:48:35PM +0300, Veksler Michael wrote: > Here is a trace of an attempt to put "Cut to the Clipboard" on the title. > I am not sure if it is from managed or unmanaged (they both seems to have > the same values). > > Trace of user32 relay: > Call user32.171: DrawTextA(0b78,406e5754 "Cut to the >Clipboard",,406e58d8,) ret=00916e3b fs=008f > Ret user32.171: DrawTextA() retval=000e ret=00916e3b fs=008f So it's writing this to the non-client area directly. I can't see how managed mode will ever support this. You'd somehow have to hack GetDCEx to return a special dc if we want a DCX_WINDOW dc. This dc would have to trap attempts to draw stuff to the non-client area and somehow persuade the Window Manager to draw them... Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: relay debugging broken?
On Fri, Aug 11, 2000 at 04:35:50PM +0200, Peter Ganten wrote: > Huw D M Davies writes: > > Oops, thank you. What about this one? Alexandre: Please forget the > previous patch. I still find it easier to understand (! (!strcmp() || !strcmp()) but anyway... Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: relay debugging broken?
On Fri, Aug 11, 2000 at 02:07:00PM +0200, Peter Ganten wrote:
>-SYSLEVEL_CheckNotLevel( 2 );
>+/* the user driver functions may be called with the window lock held */
>+if ( ! ( strcmp ( buffer, "x11drv" ) || strcmp ( buffer, "ttydrv" ) ) )
You'll need a '!' in front of each strcmp.
>+ SYSLEVEL_CheckNotLevel( 2 );
>
> if (relay->ret == 0xc3) /* cdecl */
> {
>@@ -275,7 +277,8 @@
> DPRINTF( "Ret %s() retval=%08x ret=%08x fs=%04x\n",
> buffer, ret, ret_addr, __get_fs() );
>
>-SYSLEVEL_CheckNotLevel( 2 );
>+if ( ! ( strcmp ( buffer, "x11drv" ) || strcmp ( buffer, "ttydrv" ) ) )
ditto
>+ SYSLEVEL_CheckNotLevel( 2 );
>
> return ret;
> }
>
Huw.
--
Dr. Huw D M Davies | Clarendon Laboratory
[EMAIL PROTECTED] | Parks Road
Tel: +44 1865 272390| Oxford OX1 3PU
Fax: +44 1865 272400| UK
Re: Äcorel wine mergeÅ Add support for li baps
On Tue, Aug 08, 2000 at 06:09:42PM -0700, Alexandre Julliard wrote: > Another problem with the patch is that it adds dependencies between > gdi, wineps and winspool, and this is Not Good(tm). Inter-dll calls > are only allowed to call functions exported in the spec file; the APS > functionality should be exposed through the standard Windows APIs. Yes, this is the reason why I haven't merged this code from the Corel tree myself. It's not quite as hard to unravel as the FontTastic stuff though... Huw.
Re: Initialize hrgnWnd
On Mon, Jul 31, 2000 at 10:15:14AM -0400, Francois Jacques wrote:
> huw,
>
> Thanks for this update... After a while, I thought that my WindowRgn
> patch wouldn't make it into the tree. I have an updated version which
> had this fix along with other XShape<-->WindowRgns issues. Look for an
> update later this week...
Hi Francois
Have you got this one too?
Changelog:
WINPOS_WindowFromPoint should care about hrgnWnd.
Huw.
--
Dr. Huw D M Davies | Clarendon Laboratory
[EMAIL PROTECTED] | Parks Road
Tel: +44 1865 272390| Oxford OX1 3PU
Fax: +44 1865 272400| UK
Index: windows/winpos.c
===
RCS file: /home/wine/wine/windows/winpos.c,v
retrieving revision 1.67
diff -u -r1.67 winpos.c
--- windows/winpos.c2000/07/28 23:04:55 1.67
+++ windows/winpos.c2000/08/01 09:23:22
@@ -466,13 +466,16 @@
/* is enabled (or it's a top-level window), then explore */
/* its children. Otherwise, go to the next window. */
-if ((wndPtr->dwStyle & WS_VISIBLE) &&
+if ((wndPtr->dwStyle & WS_VISIBLE) &&
(!(wndPtr->dwStyle & WS_DISABLED) ||
((wndPtr->dwStyle & (WS_POPUP | WS_CHILD)) != WS_CHILD)) &&
-(xy.x >= wndPtr->rectWindow.left) &&
-(xy.x < wndPtr->rectWindow.right) &&
-(xy.y >= wndPtr->rectWindow.top) &&
-(xy.y < wndPtr->rectWindow.bottom))
+ wndPtr->hrgnWnd ?
+ PtInRegion(wndPtr->hrgnWnd, xy.x - wndPtr->rectWindow.left,
+ xy.y - wndPtr->rectWindow.top) :
+((xy.x >= wndPtr->rectWindow.left) &&
+(xy.x < wndPtr->rectWindow.right) &&
+(xy.y >= wndPtr->rectWindow.top) &&
+(xy.y < wndPtr->rectWindow.bottom)))
{
*ppWnd = wndPtr; /* Got a suitable window */
@@ -517,7 +520,7 @@
{
retvalue = hittest; /* Found the window */
goto end;
- }
+ }
}
else
{
Re: strmdll
On Tue, Jul 18, 2000 at 04:58:20PM +0200, Patrik Stridvall wrote: > > Huw D M Davies <[EMAIL PROTECTED]> > > Stubs for strmdll. > > Hmm, STRMDLL.DLL is AFAICS distributed with > Microsoft Media Player which is not really a > proper part of Windows 9x/NT/2000. Yes you're right. Please forget this patch. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: icontitle fix
On Tue, Jul 18, 2000 at 04:08:06AM -0600, gerard patel wrote: > The kind of problem really obvious once you have found it :-/ Tell me about it. I've just spent far too long rediscovering this bug ;-) Huw.
Re: Enhanced Metafiles
On Mon, Jul 10, 2000 at 04:08:37PM +0100, Huw D M Davies wrote: > On Mon, Jul 10, 2000 at 10:42:30AM -0400, Jason Mawdsley wrote: > The recording of enhmetas definitely does this. Insert 'under Windows' somewhere in this sentence ;-) Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
