Is Helvetica available on every MATLAB platform?

I am programmatically building graphical interfaces and was wondering how universal Helvetica is on various platforms. A quick test:

 Q=listfonts();k=contains(Q,'Helvetica');Q{k}

ans = 'Helvetica'

verifies if one or more Helvetica font are available. I can confirm than this font is available in R2025a (presumably previous releases as well) on the Mac and Windows. It also appears to be present on MATLAB Online. What I am less clear about is the many different flavors of Linux.

The underlying problem is that horizontal space requirements vary wildly between different font types. I have enabled a system where interfaces can be tailored around the end user's font size preference, but allowing the font itself to change is much tricker. For example, suppose you want to have an edit box wide enough to fit 20 characters. This is straightforward for a fixed with font, such as Monaco or Consolas. The default choice seems to be Helvetica, where the "W" and "i" characters are vastly different. A graphic sized for one font can appear much wider than necessary in some cases or not wide enough in others. If one were certain that Helvetica is always availble, it would make sense to base the design around that font. If not, one could rely on a fixed with font, although not everyone appreciates their appearance.

[Rik]

Fonts are a pain. In my GUIs I generally allow for very large margins (i.e. 2x-3x of what I think will be needed) or I hardcode a font I pixelized myself (see text2im). It is a bit of a cludge, but I often see huge companies with entire departments focused on UI design mess up, so I don't fret too much.

Also, you should be careful assuming any defaults, since people can change them, which would break your carefully calibrated solution.

[Dan Dolan]

You are spot on about fonts being a pain. Sometimes I go to great lengths to avoid putting uicontrols or components (uilabel, etc.) on a graphical interface to avoid dealing with variations across different systems. The problem is that uimenus, context menus, and various action callbacks only get one so far. When I have no choice but to use controls, they are usually based on the requirements of repeated "W" characters. Oversizing is less bad than undersizing--at least you can always read the text--but sometimes the result is garish.

Although I don't use the App Designer, presumably its existence suggests some degree of font portability. One of my gripes with this approach is that the interface is explicitly tied to a specific font name and size, but in order for that to work, presumably the default (Helvetica 12 point) has to be available on all platforms? Then again, the font might be embedded somewhere in the *.mlapp file.

Answer 1

[Star Strider]

On my Ubuntu 24.04 installation (latest updates), using yur example code, 'Helvetica' is the 12th entry in 'k'.

Proportional fonts are exactly that -- proportional. There are probably ways of calculating the pixel width of each letter in a specific font size, or the pixel width of a character array in a specific proportional font. Searching the File Exchange on 'font width' brings up three contributions, however none of them appear to calculate the pixel widths of either individual letters or a character array. You might consider doing a wider interweb search for that.

[Dan Dolan]

That's a useful data point. Would you be willing to try another set of commands?

temp=extractBetween(evalc('type listfonts'),'if useLocal','end');
disp(temp{1})

On my Mac and MATLAB Online, I see seven postcript fonts: Courier, Helvetica, Monospaced, SansSerif, Serif, Symbol, and Times. Windows returns a list of eleven fonts with some overlap. Notable commonalities include Courier, Helvetica, and Times. It would be interesting to see if Linux includes those three particular fonts.

I've written some code that determines relative characer widths (with respect to "W") for a given font based on the printable ASCII characters. This is interesting it's own right, but it is only a partial step along the path. The challenging part is deciding what kind of characters will be going into component. For example, the text in a label or button is generally static, so it makes sense to set the size slightly larger than the effective character width. That width equals the number of characters for a fixed width font and something smaller for proportional font. My code can handle arbitrary strings, and typical scaling is 50-60% (not accounting for character frequency).

What about user-editable componets, like edits and tables? Well if that field only needs to support numeric input, you might base widths around the digits (which appear to have consistent widths) plus maybe a decimal point, some signs, and maybe an e/E for scientific notation. However, those fields might need to manage a vareity of user inputs, which kicks you back to using the widest character to ensure that content is always visible. Now we return to potentially oversized controls, which is better than undersizing but does not look very nice.

[Star Strider]

My pleasure!

Your code:

temp=extractBetween(evalc('type listfonts'),'if useLocal','end');

disp(temp{1})

returns:

% always add postscipt fonts to the system fonts list.

systemfonts = [fonts;

{

'Courier';

'Helvetica';

'Monospaced';

'SansSerif';

'Serif';

'Symbol';

'Times';

}];

else

systemfonts = getCommonFonts();

for me.

.

[Dan Dolan]

This core set of fonts appears on MATAB Moble as well.

[Star Strider]

Noted! Thank you!

I believe everything in MathWorks uses Ubuntu, however I know of no further details. The ver command will list some of those details in its OS section.

Answer 2

[Walter Roberson]

The traditional way of handling this was to create a uicontrol and set the text string and font properties of the uicontrol, and then query the Extent property of the uicontrol, which would return the width and height actually needed to represent the text string with those properties. And then to use that information to set the size of the target control.

The main alternative to this is to get the Extent property of a text() object.

There is a File Exchange contribution that automates getting the extent from a text object; see https://www.mathworks.com/matlabcentral/fileexchange/168156-gettextextent

[Dan Dolan]

I to feel the pain at the loss of Extent properties--that's what I have traditionally done. I had considered the approach you suggest, relying on a hidden figure with a legacy text field for Extent calculations, but there's a problem. Axes text and uicontrols fonts are scaled by 1.33x (starting in 2025a), but new components (uilabels, uibutton, etc.) are not. That means the extent values calculated this way are systematically too large. I conceed that oversizing is less dangerous than undersizing a component, at least in terms of readability, but now the question is whether this arrangment changes in a future release. Objects where Units/FontUnits can be something other than pixel are scaled, and for now the newer components do not qualify.