I have some trouble to implement a text input field on Windows correctly.
I call GetUI()->CreateTextEntry(…). There are two possibilities in this method:
(1) We use CreatePlatformTextEntry(). This uses the Win API and creates a font this way:
lFont.lfHeight = text.mSize * scale;
mEditFont = CreateFontIndirect(&lFont);
Unfortunately Windows and Skia have different ideas of the size of the font. If we use e.g. “Roboto”, we get the same font size as in the other parts of the UI (where we use Skia to render the fonts). But for many fonts this is no true, e.g. for “Arial”, “Trebuchet MS”, “Ubuntu”, “Recursive”, … Here an example for “Trebuchet MS”:
This is ugly…
[Using lFont.lfHeight = -text.mSize * scale; to use the character height instead of the cell height make the font too big…]
(2) We use ITextEntryControl: Here all is fine, all fonts are rendered using the same engine. But ITextEntryControl has problems with German keyboards (and may be other non English keyboards): AltGr is not processed correctly, i.e. every character I try to type where I need AltGr are ignored. These characters are: |~}][{@€²³
This means: pretty but useless!
Any idea what to do? I think we don’t have a chance to convince Win API to do always the same as Skia. So, we should enabled AltGr in ITextEntryControl, but debugging through this I got lost 
Anyone who has an idea where to look?
[I could stay with Roboto, but I like Recursive much more… 
]
I have conditional code in my plugins that changes the text size depending on font and also Windows vs Mac. I found out right away that there are size variations from Mac to Windows. I’m using NanoVG but this probably also occurs with SKIA, IDK.
Testing, testing, testing…
There is an iplug issue around text sizes to resolve. I did a lot of work on this about 2.5 years ago when there were still 4-5 graphics backends (+ 3 platforms), and because of that it was quite time consuming.
At the moment I thought things were relatively consistent between platform and non-platform displays, although the biggest issue is that font sizes do not relate to those in graphics packages. This was based on a NanoVG design decision that we followed at the time that has now been changed.
It’s on my list of things to look at but I can’t say when yet. The difference between platform and native text is also really frustrating. It is impossible to get them to match exactly. I have been thinking about the idea of a hybrid approach, where the platform provides the editing capabilities but draws transparently and we render the text natively. It’s not a particularly nice solution from an engineering point of view, but it might be the best way to get the right graphical display at the same time as getting proper text entry etc.
For now unfortunately for issues like this workarounds are the only option.
@AlexHarker: Thank you for this lot of information!
Just merged your text-size branch in my work branch. Much better, great work! Now my layout is completly destroyed , but text input is much better. Only the positioning of the text input is now wrong, but there is an issue of YouLean, which may help.
I would like to encourage you to finish this great work. This will break all plugins build with iPlug2 and therefore: the sooner, the better!
In theory only the text sizing should have changed, but I can’t remember exactly where I got to. In time I should be able to supply conversion helpers that allow you simply wrap any text sizes with a convertor to maintain your layout.
Do you get the same size of text in entries as on the display on windows?
Were there any merge conflicts?
Sorry, I exaggerated 
. Yes, only the text sizes changed and text placements based on text sizes are wrong. No Problem, I will adjust that.
I had only time to test one font and this looked good. I will test other fonts later!
Only one small real merge conflict and some whitespace conflicts.
I forgot to write: I had to change the font size in the platform dialog to lFont.lfHeight = -text.mSize * scale to get the right results.
Some more test with different fonts showed: Much better, but for most fonts the Windows rendered version is a little bigger. Not quite as bad as before, but a few pixel width in a 30 character sentence.
I will look a little more in detail next week. I will write my findings in the issue
Thanks - to clarify I checked the text-size branch and I never did any work on Windows to do with platform entries - it was only done on Mac (and the native drawing). So there’s still more to look at here and this fix is definitely going to look different on windows.
I’ll try to find time to look more soon. I wanted to rebuild the history of changes on a more up to date branch, so I’ve started that work locally.