Runtime: System.Drawing.FontConverter string parsing problem

[walterpg]

Hi all,

ConvertFrom returns a Font instance when the "size" component of the string is missing the "unit" specifier. For example,

myFont = converter.ConvertFromString("Courier New, 11.5, type=Regular") as Font;
myFontString = converter.ConvertToString(myFont);

In corefx, myFontString is "Courier New, 8px", whereas in desktop the value is "Courier New, 11.5pt". ConvertTo appears to be reflecting the myFont instance correctly in each case.

There appears to be at least these two differences with FontConverter in corefx.

• The default value for units is "px" in corefx, and "pt" in desktop.
• In corefx, if units is omitted, default size (8) is used instead of specified value.

Impact
Rightly or wrongly, databases in the wild contain serialized Font instances such as shown above.

Repro
Project targeting net48 & netcoreapp3.0 attached.

FontConverterProblem.zip

[Anipik]

@safern @ericstj what will be the correct behavior here ? if we are allowing for the user to pass the font size without units (not throwing exception), we should return the actual value passed with the default unit ?

[ericstj]

Desktop behavior has precedent, unless there was a good reason for diverging we should try to be consistent with the desktop behavior. I'm not sure if there was a good reason: did you look into that?

[Anipik]

I'm not sure if there was a good reason: did you look into that?

it seems like this just happened during refactoring. we need separate checks for unit and value https://source.dot.net/#System.Windows.Extensions/System/Drawing/FontConverter.cs,145

something silimar to like we have in .Net Framework https://referencesource.microsoft.com/#System.Drawing/commonui/System/Drawing/FontConverter.cs,135

[Anipik]

I am not able to find a reason behind changing the default unit from pt in desktop to pixel in core

[ericstj]

If I look at https://github.com/dotnet/corefx/pull/28426 which was the first iteration of adding this code back, it was done from the mono codebase rather than desktop, which explains the difference. We should fix this difference. It may be worth doing a review of the diff between mono and desktop to see where we might have other breaking changes.