Re: gdi32: return the correct font type, ntmFlags and PitchAndFamily for Type1 fonts (fixes bug #5877)
"Mikolaj Zalewski" <[EMAIL PROTECTED]> wrote:
As I wrote in Bugzilla for Photoshop to work with Type1 fonts after
applying this patch one needs to reinstall Photoshop in a clean
wineprefix - it seems that Photoshop caches some font data.
+/* check for the presence of the 'CFF ' table to check if the font
is Type1 */
+tmp_size = 0;
+if (pFT_Load_Sfnt_Table && !pFT_Load_Sfnt_Table(ft_face, 0x43464620,
0, NULL, &tmp_size))
+{
+TRACE("Font %s/%p is OTF Type1\n", wine_dbgstr_a(file),
font_data_ptr);
+face->ntmFlags = NTM_PS_OPENTYPE;
+}
Please use a symbolic name instead of 0x43464620. FreeType provides TTAG_CFF,
or you can define it on your own using FT_MAKE_TAG.
--
Dmitry.
Re: Kudos - Fireworks 8 working better...
I told that for weeks - I really believe that speed on Fireworks are better under Linux using wine than XP. I suspect Dreamweaver to use ~ 90% from it's original speed. Also XnView works as in Windows (except I can not open files by dragging them to Xnview Icon) - last XnView work without any ..any problem I can do ALL operations like before. Dan Kegel wrote: http://www.5thpercentile.com/devBlog/archives/2007/09/wine_just_got_t.html and http://appdb.winehq.org/appview.php?iVersionId=4149&iTestingId=15163 both say that wine-0.9.44 really improves Adobe Fireworks. Yay! - Dan
Re: wined3d: add WINED3DPRESENT_INTERVAL_ONE flag (fix bug 9584)
Am Freitag, 7. September 2007 18:29:02 schrieb Louis. Lenders: > I added this initially as a hack to get mame running, but what i understood > from discussion on IRC, there's no way we can check the graphics card's for > this capability now, and adding it as default (so without checking) would > be rather harmless. Short answer: Patch is ok with me Long answer: We can check if opengl supports vsync(which is what this flag does). WineD3D implements vsync using GLX_SGI_video_sync. So if this extension is supported, we should set the flag. If it is not supported, do not set it. Our WGL implementation does not forward the GLX extension yet, so we do not support vsync at the moment, so setting this flag means essentially lying to the app. However, I think it is safe to pretend vsync support. The worst that may happen is that the game renders with a higher framerate, and the hardware consumes more power instead of beeing idle. I think both cases are better then not running the game at all. There's one game which runs into internal race conditions if vsync does not work(need for speed 3), but that game doesn't even care to check that flag.
Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite
"Vincent Povirk" <[EMAIL PROTECTED]> wrote: Again StrCpyNW is a shlwapi export, and since you just allocated the buffer of correct length memcpy + adding an explicit '\0' terminator look more naturally here (if not kernel32.lstrcpynW). I'm allowed to use memcpy? Isn't that a native Linux function? If Wine wouldn't be able to call native Linux APIs how it would work at all? You are still not checking SHCreateDirectoryExW return value. Nope. If SHCreateDirectoryExW returns ERROR_ALREADY_EXISTS, I need to return HRESULT_FROM_WIN32(ERROR_DIRECTORY) or S_OK, depending on whether it is a file or a directory. I already pointed out that there is no such a test to show correct behaviour of SHCreateDirectoryExW in that case. If you claim that there is inconsistency you need to add a test case for it. And since I'd need to free temppath if and only if I'm returning early, I think that any way I could do that would make the code awkward/confusing. I don't think that handling errors makes the code confusing. If SHCreateDirectoryExW fails you can skip a fairly slow GetFileAttributesW call, and that's another advantage. There is no need to check temppath for NULL before HeapFree call. Oh. MSDN says there is. Not that I trust MSDN.. Even there is a janitorial task in Wine to remove NULL checks before HeapFree calls. -- Dmitry.
Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite
> > Again StrCpyNW is a shlwapi export, and since you just allocated the > > buffer of correct length memcpy + adding an explicit '\0' terminator look > > more naturally here (if not kernel32.lstrcpynW). > > I'm allowed to use memcpy? Isn't that a native Linux function? It's a C library function. Got nothing to do with Linux. Cheers, Kuba
Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite
> You are still using a buffer of a fixed size. Whoops, didn't think about that one. > StrRChrW is a shlwapi export. Since shlwapi.dll is just mostly a > wrapper/helper, > and it imports shell32, that would create a circular dependency. I already > suggested to use strrchrW here. Um, ok. I didn't realize there were two different functions. I only was able to find documentation on StrRChrW. There is indeed a circular dependency (which I wouldn't have noticed), apparently because shell32 needs to export StrRChrW. > Again StrCpyNW is a shlwapi export, and since you just allocated the buffer > of correct length memcpy + adding an explicit '\0' terminator look more > naturally here (if not kernel32.lstrcpynW). I'm allowed to use memcpy? Isn't that a native Linux function? > You are still not checking SHCreateDirectoryExW return value. Nope. If SHCreateDirectoryExW returns ERROR_ALREADY_EXISTS, I need to return HRESULT_FROM_WIN32(ERROR_DIRECTORY) or S_OK, depending on whether it is a file or a directory. And since I'd need to free temppath if and only if I'm returning early, I think that any way I could do that would make the code awkward/confusing. > There is no need to check temppath for NULL before HeapFree call. Oh. MSDN says there is. Not that I trust MSDN.. -- Vincent Povirk
Re: nhelp, Vector NTI, molecular biologists
Uwe Bonnes wrote: [...] Missing MFC42 and other redistributable DLLs is a showstopper for winelib and running windows code on non i386 archtecture... Well, not quite. If you're going to use Winelib it means that you have the source of the application. And if it is using the MFC it should mean that you have a Visual Studio license, and thus the MFC sources (though maybe that's only in the 'Pro' edition or some such). So then you should be able to recompile the MFC using Winelib. That's exactly what I did five years or so ago. I had to trim quite a few things but got something that was somewhat usable. I did not pursue it further though. Modern day MFC probably changed a bit (did it really change much?), but then Winelib should be much better too. The real issue is the license. In the Visual Studio 6 era, it seemed like it was legal to redistribute the MFC dll with your non-trivial application, with no mention of the platform. This might have changed since, and in any case that's something you'd want to check with a lawyer. -- Francois Gouget [EMAIL PROTECTED]
Re: ddraw/tests: Check deviceGUID of enumerated devices.
Am Freitag, 7. September 2007 02:44:32 schrieb David Hedberg: > Ah, I thought this was going a bit too well ;) I'll fix the issues and > send it in again. Regarding a fix, would something as simple as the > following be acceptable? > > (in dlls/ddraw/direct3d.c) > > @@ -263,6 +263,12 @@ IDirect3DImpl_7_EnumDevices(IDirect3D7 *iface, > return hr; > } > Callback(interface_name, device_name, &ddesc, Context); > + > + ddesc.deviceGUID = IID_IDirect3DHALDevice; > + Callback(interface_name, device_name, &ddesc, Context); > + > + ddesc.deviceGUID = IID_IDirect3DRGBDevice; > + Callback(interface_name, device_name, &ddesc, Context); You should set the right interface and device name string too.
Re: nhelp, Vector NTI, molecular biologists
Am Freitag, 7. September 2007 10:05:25 schrieb Uwe Bonnes: > Missing MFC42 and other redistributable DLLs is a showstopper for winelib > and running windows code on non i386 archtecture... I think you can compile MFC42 for winelib and other architectures, the source code is publically accessible(shipped with visual studio). It is a bit tricky, and you have to get the license right, but there is a HOWTO somewhere on the wine website and it should work.
Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped as PE resources
"Mikolaj Zalewski" <[EMAIL PROTECTED]> wrote: Then there is no point in using FreeType for loading font files at all, (or adding support for new font file formats to FreeType) since FreeType can load fonts from memory. Do you mean that in AddFontResource I shouldn't try to call WineEngAddFontResourceEx but do only a LoadLibraryEx (that won't work as at least according to MSDN the parameter to AddFontResource can be a FNT file or a Win16 NE executable) or that in AddFileToList I should not make a distinction between memory and file fonts but always load the font from memory, mmaping it before if necessary? I mean that we should choose from either leaving the task to FreeType, or doing the whole job of loading the font files internally in Wine. I admit I don't understand - what would we gain from doing all the loading internally in Wine? Wouldn't that be simply rewriting a big part of freetype? That's exactly my point. We shouldn't add workarounds for deficiencies in FreeType, especially since FreeType now handles fonts in PE format. You wrote that loading fonts from memory will help but isn't FT_New_Memory_Face using the same parsing code as FT_New_Face and only the source differs? Anyhow it looks to me as something rather orthogonal to this patch as I don't try to parse the content of the font but only remove the PE "wrapping". We don't we do that for other font formats, what's so special about PE, that Wine can handle it? But Wine can handle NE format as well, and there are older FreeType versions that can't handle NE fonts either. If that's just a worlaround for Photoshop's (because "many programs" that you mention your patch helps is so much vague, and while searching for fonts in PE fomat to test my FreeType patch I haven't found anything except Photoshop, so I had to create a sample font set in PE format on my own) Z-order problem during startup then your fix is in wrong area, you need to fix Z-order bug instead. -- Dmitry.
re: nhelp, Vector NTI, molecular biologists
> "Dan" == Dan Kegel <[EMAIL PROTECTED]> writes: Dan> Misha wrote: >> and even my version of Windows 98 is bundled with mfc42.dll, so wine >> really should provide it too... [our own version, not Microsoft's.] Dan> Well, sure. Same goes for a lot of things. But since mfc42.dll is Dan> a Visual C++ runtime file that has very liberal redistribution Dan> terms and is in fact bundled with many apps, we can get away Dan> without it for a long time. And it's not currently a showstopper Dan> as far as I can tell; I'm more interested in the bugs that keep Dan> e.g. Photoshop from running flawlessly. Dan> So one of these days it might become a priority. Until then, it's Dan> merely important but not urgent. - Dan Missing MFC42 and other redistributable DLLs is a showstopper for winelib and running windows code on non i386 archtecture... -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
