Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

regfont problem with gVim #1

Open
chrisbra opened this issue Jan 4, 2016 · 4 comments
Open

regfont problem with gVim #1

chrisbra opened this issue Jan 4, 2016 · 4 comments

Comments

@chrisbra
Copy link

chrisbra commented Jan 4, 2016

(quoting from an email, I sent last year)

I have been using regfont to install fonts locally, when I am not
allowed to install fonts. Unfortunately, I have run into a problem, that
I hope you can explain to me.

I use vim and since some versions, it allows to use directx rendering
instead of the normal GDI rendering engine. Now all fonts that I have
installed using regfont, won't be rendered at all, if I turn on directx
rendering for Vim. I have used MS Visual Studios debugger, to trace the
problem, but I can only see, that whenever a CreateFontIndirect() call
is made, a handle is returned, that looks like this
0xc011751 {unused=???}

Since CreateFontIndirect() is a Windows function call, I am not sure,
what this means and how I can prevent this. Do you have an idea, what
might be causing this or how this could be fixed?

I hope you can explain the problem or even fix it ;)

Thanks for providing regfont.

@dcpurton
Copy link
Owner

dcpurton commented Jan 5, 2016

Hi Chris,

Glad you found the new GitHub repository.

I don't actually have a windows machine any more so I can't test. I am going to put more verbose debugging output into Regfont, but I don't think this will help. AddFontResource does not return any extended error info even when it does fail.

Does Vim fall back to a different font? Or is nothing rendered at all? Or something else? Can you test it on different versions of Windows or with different versions of DirectX? What version of Windows does it fail on?

CreateFontIndirect is a GDI function, so I don't think this is the problem. DirectX uses another function to create it's fonts (I've never done any DirectX programming).

David

@dcpurton
Copy link
Owner

dcpurton commented Jan 5, 2016

I think the problem is in the way vim creates the DWrite font. It uses CreateFontFromLOGFONT, but this system call does not work with fonts added with AddFontResource. (At least I couldn't make it do so in a test application and I stumbled across a few forum threads outlining similar problems.)

If this is right, then I can't fix it from within regfont. You could ask the vim developers if they have any thoughts, but I suspect it might mean them adding the ability to use non-installed fonts within vim.

@chrisbra
Copy link
Author

chrisbra commented Jan 5, 2016

Am 2016-01-05 15:03, schrieb David Purton:

I think the problem is in the way vim creates the DWrite font. It uses
CreateFontFromLOGFONT, but this system call does not work with fonts
added with AddFontResource. (At least I couldn't make it do so in a
test application and I stumbled across a few forum threads outlining
similar problems.)

If this is right, then I can't fix it from within regfont. You could
ask the vim developers if they have any thoughts, but I suspect it
might mean them adding the ability to use non-installed fonts within
vim.

Oh that is great. I'll update the vim-dev ml list then. Does the
CreateFontFromLOGFONT indicate an error somehow?

@dcpurton
Copy link
Owner

dcpurton commented Jan 5, 2016

Yes. CreateFontFromLOGFONT returns 0x88985002 (DWRITE_E_NOFONT; Indicates the specified font does not exist.)

My test application was taken from a Windows 7 SDK sample (https://github.com/theonlylawislove/WindowsSDK7-Samples/tree/master/multimedia/DirectWrite/GdiInterop)

I modified it just enough to get it to build using w64-mingw32 and ran it under wine. I added a call to AddFontResource at the start of wWinMain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants