On 19.07.2016 14:34, Hugh McMaster wrote:
Signed-off-by: Hugh McMaster hugh.mcmaster@outlook.com
dlls/kernel32/console.c | 27 ++++++++++++++++++++++++--- dlls/kernel32/tests/console.c | 6 +++--- 2 files changed, 27 insertions(+), 6 deletions(-)
It looks like your code requests the font size from the wineserver (GetConsoleFontSize) just to send it back immediately afterwards. Is that intentional? And wouldn't it make more sense to implement support for multiple font sizes first?
Also, please note that the GetNumberOfConsoleFonts() check is unnecessary because GetConsoleFontSize() already takes care of that.
On Tuesday, 19 July 2016 10:52 PM, Sebastian Lackner wrote:
It looks like your code requests the font size from the wineserver (GetConsoleFontSize) just to send it back immediately afterwards. Is that intentional?And wouldn't it make more sense to implement support for multiple font sizes first?
SetConsoleFont uses the index to look up the relevant font size from the system font table, which is undocumented. Calling GetConsoleFontSize is intentional, although we could look up the font table ourselves, I suppose.
We decided a while back to only have one font in our font table. I guess that makes SetConsoleFont redundant for the moment. If we were to implement support for multiple file sizes, I'm not sure where that support would reside. Kernel32 is too low-level, as enumerating fonts uses GDI32. Any ideas?
Also note that the Windows font table includes the console raster font and the fonts listed in LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont.
We list nothing in that registry key, and wineconsole supports all fonts that meet the fixed width criteria, making this a huge task.
Also, please note that the GetNumberOfConsoleFonts() check is unnecessary because GetConsoleFontSize() already takes care of that.
True, good point.
Thanks for the review.
On 19.07.2016 15:50, Hugh McMaster wrote:
On Tuesday, 19 July 2016 10:52 PM, Sebastian Lackner wrote:
It looks like your code requests the font size from the wineserver (GetConsoleFontSize) just to send it back immediately afterwards. Is that intentional?And wouldn't it make more sense to implement support for multiple font sizes first?
SetConsoleFont uses the index to look up the relevant font size from the system font table, which is undocumented. Calling GetConsoleFontSize is intentional, although we could look up the font table ourselves, I suppose.
This method might work in the future (when GetConsoleFontSize is properly implemented), but as long as there is only one entry, its basically just a complicated looking stub. ;) Later, when SetConsoleFont() allows changing the font, it will probably also be necessary to queue a notification event such that wineconsole can update accordingly.
We decided a while back to only have one font in our font table. I guess that makes SetConsoleFont redundant for the moment. If we were to implement support for multiple file sizes, I'm not sure where that support would reside. Kernel32 is too low-level, as enumerating fonts uses GDI32. Any ideas?
Also note that the Windows font table includes the console raster font and the fonts listed in LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont.
We list nothing in that registry key, and wineconsole supports all fonts that meet the fixed width criteria, making this a huge task.
Not sure if its feasible, but you could probably implement the enumeration in wineconsole. The table could then (for example) be stored in a temporary registry key (similar to how font caching in gdi32 works).
Also, please note that the GetNumberOfConsoleFonts() check is unnecessary because GetConsoleFontSize() already takes care of that.
True, good point.
Thanks for the review.
On Wednesday, 20 July 2016 12:04 AM, Sebastian Lackner wrote:
On 19.07.2016 15:50, Hugh McMaster wrote:
We decided a while back to only have one font in our font table. I guess that makes SetConsoleFont redundant for the moment. If we were to implement support for multiple file sizes, I'm not sure where that support would reside. Kernel32 is too low-level, as enumerating fonts uses GDI32. Any ideas?
Also note that the Windows font table includes the console raster font and the fonts listed in LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont.
We list nothing in that registry key, and wineconsole supports all fonts that meet the fixed width criteria, making this a huge task.
Not sure if its feasible, but you could probably implement the enumeration in wineconsole. The table could then (for example) be stored in a temporary registry key (similar to how font caching in gdi32 works).
In general, I think we could just enumerate appropriate font sizes for the active console font. Storing the values (i.e. the font sizes) in a temporary registry key seems to me like a good idea. Those values would be accessible from kernel32 because the registry calls are forwarded to advapi32.
-
Hugh McMaster -
Sebastian Lackner