ThePhysicist wrote:
Ok, let's see what I can do about that.
I begin with the stuff I did recently.
Some time ago, when I browsed through bugzilla, I came across a bug, stating that nothing happens, when you doubleclick a font file. Well no surprise, as we didn't have any fontview application. I used google to find out if I could find an open source fontview, maybe from wine, and I found a mailing list entry where a wine dev said that he was going to write such app. That was in 2003, iirc and still no fontview in wine.
So I decided to write a fontview app (can now be found in modules/rosapps).
Most of the stuff was pretty easy, but how to get the face name? You supply fontview.exe with the name of a fontfile on the command line and it needs to figure aout the face name. There's the undocumented gdi32 function GetFontResourceInfoW() and I found enough info on the web to use it for this purpose. But this function was completely unimplemented in ReactOS. So to get the app working on ROS I had to implement this function, both in gdi32 and win32k (NtGdiGetFontResourceInfoInternalW())
So I did some testing, first calling the gdi function, later also calling win32k's NtGdiGetFontResourceInfoInternalW directly using an int 0x2e.
After some problems in the beginning - I was always getting FALSE returned from win32k (wich means error) because I forgot to translate the filename into Nt format ("??\c:\...") - I was able to gather some additional details about how it works in win32k.
So this is how it basicly works:
- pwszFiles: String containing the filename(s) of the files to get Info from
- pdwBytes: Pointer to a DWORD, IN: Size of the buffer, OUT: Bytes copied
- pvBuf: Pointer to the buffer to recieve the data
- dwType: specifies the Type of info, you want to get
dwType
0 a DWORD, that can be 1 or 2, depending on the font file, don't know excatly
1 long fontname, not suitable for loading the font in some cases
2 a LOGFONTW structure, use lfFaceName member from this one for further use
3 a DWORD, always one if the function succeds(?)
4 returns the full path name, handled by gdi32 only
5 Seems to be a BOOL, wich is TRUE, when the font is not found in the global font table.
return value will be TRUE in this case, even if the font was not found.
returns: TRUE if success, FALSE if no success.
With this info I wrote a basic implementation that allowed to run fontview.exe on ReactOS. It also allows to run ms fontview.exe, but that looks a little ugly. (see pictures at the bottom)
Currently it is only supporting one filename. If someone knows how multiple filenames are handled by the funtion, let me know.
While working on the function in win32k, I came across some issues with our current text rendering code. So I decided to continue the work I had begun some time ago, but quickly abandoned again: Try to get our TextOut and related stuff more compatible with windows.
Hopefully more on that later, so stay tuned...
"And it would be nice to have more dev blogs. Just a few sentences from
time to time apart from the svn commits to see what's going on."
Ok, let's see what I can do about that.
I begin with the stuff I did recently.
Some time ago, when I browsed through bugzilla, I came across a bug, stating that nothing happens, when you doubleclick a font file. Well no surprise, as we didn't have any fontview application. I used google to find out if I could find an open source fontview, maybe from wine, and I found a mailing list entry where a wine dev said that he was going to write such app. That was in 2003, iirc and still no fontview in wine.
So I decided to write a fontview app (can now be found in modules/rosapps).
Most of the stuff was pretty easy, but how to get the face name? You supply fontview.exe with the name of a fontfile on the command line and it needs to figure aout the face name. There's the undocumented gdi32 function GetFontResourceInfoW() and I found enough info on the web to use it for this purpose. But this function was completely unimplemented in ReactOS. So to get the app working on ROS I had to implement this function, both in gdi32 and win32k (NtGdiGetFontResourceInfoInternalW())
So I did some testing, first calling the gdi function, later also calling win32k's NtGdiGetFontResourceInfoInternalW directly using an int 0x2e.
typedef BOOL (WINAPI *PGFRI)(LPCWSTR pwszFiles, DWORD pdwBytes, LPVOID pvBuf,DWORD dwType);
PGFRI GetFontResourceInfoW;
/ Load the GetFontResourceInfo function from gdi32.dll */
HINSTANCE hDLL = LoadLibrary("GDI32.DLL");
GetFontResourceInfoW = (PGFRI)GetProcAddress(hDLL, "GetFontResourceInfoW");
W32KAPI BOOL APIENTRY NtGdiGetFontResourceInfoInternalW(
IN LPWSTR pwszFiles,
IN ULONG cwc,
IN ULONG cFiles,
IN UINT cjIn,
OUT LPDWORD pdwBytes,
OUT LPVOID pvBuf,
IN DWORD dwType
)
{
BOOL ret;
asm volatile ("int $0x2e\n" : "=a"(ret): "a" (0x10b2), "d" (&pwszFiles));
return ret;
}
After some problems in the beginning - I was always getting FALSE returned from win32k (wich means error) because I forgot to translate the filename into Nt format ("??\c:\...") - I was able to gather some additional details about how it works in win32k.
So this is how it basicly works:
- pwszFiles: String containing the filename(s) of the files to get Info from
- pdwBytes: Pointer to a DWORD, IN: Size of the buffer, OUT: Bytes copied
- pvBuf: Pointer to the buffer to recieve the data
- dwType: specifies the Type of info, you want to get
dwType
0 a DWORD, that can be 1 or 2, depending on the font file, don't know excatly
1 long fontname, not suitable for loading the font in some cases
2 a LOGFONTW structure, use lfFaceName member from this one for further use
3 a DWORD, always one if the function succeds(?)
4 returns the full path name, handled by gdi32 only
5 Seems to be a BOOL, wich is TRUE, when the font is not found in the global font table.
return value will be TRUE in this case, even if the font was not found.
returns: TRUE if success, FALSE if no success.
With this info I wrote a basic implementation that allowed to run fontview.exe on ReactOS. It also allows to run ms fontview.exe, but that looks a little ugly. (see pictures at the bottom)
Currently it is only supporting one filename. If someone knows how multiple filenames are handled by the funtion, let me know.
While working on the function in win32k, I came across some issues with our current text rendering code. So I decided to continue the work I had begun some time ago, but quickly abandoned again: Try to get our TextOut and related stuff more compatible with windows.
Hopefully more on that later, so stay tuned...
fontview on ReactOS
MS fontview on ReactOS
