UI Font != LAY Font

[Gurudumps]

MAME version

0.282 (or any or latest)

System information

applies to any PC running MAME

INI configuration details

n/a

Emulated system/software

any emulated machine with a complex keyboard

Incorrect behaviour

The layout font is (incorrectly) hard-coded to the default font.
When the UI font is changed the layout font does not change.

Expected behaviour

Changing the UI font should also change the Layout font or the Layout font needs its own setting.

Steps to reproduce

Run any device using a layout where the device is large. Text generally looks bad, especially at small sizes.
For example sd132 (and many others... cz101, cz1, dx100 etc)

Additional details

Solution:

To at least make the experience the same across all platforms, MAME should use the included Noto Sans font that is hidden in one of the 3rd party dirs. Or choose some other free font with a large selection of glyphs. Noto Sans seems to be a very good choice.
MAME must use this font in the layout where currently it uses some default font regardless of what is
selected for the UI font. Or (probably better), allow for a device-specific .ini where the layout font can be set.

The different-UI-font-across-different-platforms issue has been a problem for many years and makes some layouts look terrible. Yet no one seems to have 5 minutes to solve this issue? There are also some mametesters reports, largely ignored. This issue is well known.

MAME should use the bundled free font as the UI and LAY font, otherwise why bundle something that is completely unused with the MAME distribution and hide it?

On first run MAME should check to see if the font is installed on the system and if not found, either install it or prompt the user to install it. At least do the check for any emulated device that includes a layout when first run to warn the user they are going to have a bad experience without the correct font installed on their system. Adding (checking for and if found, loading) a device-specific ini setting to specify the layout font will solve part of the problem.

Case in point: I'm working on layouts for a couple of special computers with non-standard keyboards. When I put special characters on the keys using the common uifont MAME normally uses (in this case it's Windows / Tahoma), it will not display correctly on other platforms. When I change the UI font to Noto Sans (the one hidden in the 3rd-party dir) it uses that font only for the UI and not for the lays. Noto Sans looks good at smaller sizes since it is bolder but the layout font seems to be hard-coded which is a mistake.

Summary:
Use existing/bundled Noto Sans as the font for the UI and Layouts.
Add setting to mame.ini for layout font and use it in a lay. Default will be whatever is the uifont.
Allow for loading device-specific ini with a layout font setting for device-specific layout font usage.

The use of a 'MAME' font across all platforms for the UI and Layout should be unified and consistent.
Currently it is not.

[ajrhacker]

Unfortunately there is another UI font problem which I've noted in MT 7977: most standard fonts (including the NotoSans-Bold.ttf packaged with MAME) lack glyphs for katakana, which is important for many Japanese computers.

MAME's font handling is very clumsy and outdated but doesn't seem likely to be replaced soon. The rewrite seems to be contingent on a new rendering layer which exists mostly in the minds of one or two MAMEdevs.

[Gurudumps]

A few Japanese computers shouldn't be a barrier to move forward with getting Noto Sans into MAME properly and making lays also use it.
When MAME supports a mame.ini setting for the layout font then those Japanese computers can have their own ini to set their own layout font as per what I said above.

As for the rendering layer, at least for better svg rendering and command support, I noted that there is a very complete open-source svg renderer called ThorVG which should replace the junker nanosvg currently in MAME. With ThorVG and proper support for a layout font that is not the OS default, layouts should actually look really good.

[cbrunschen]

I actually think that the SD-1/32 (sd132) looks pretty good, including text. But there are absolutely aspects of it that I can't 100% accurately represent in the current layout system. And here, being able to choose a single "layout font" isn't really sufficient. The Ensoniq VFX family that includes the SD-1/32 uses (what looks like) Helvetica, both in Regular weight with Italic style, and in Bold weight with Normal style: the labels above buttons are all Italic; the labels underneath the display, and along the coloured decorative lines that indicate different sections of buttons, are all Bold.

Better would be to be able to specify for each <text> element a list of possible fonts in order of preference, much like you can in HTML and CSS, with some suitable set of fallback fonts included with MAME.

For a future or alternative rendering layer, perhaps RmlUi would be worth looking at: it is modelled after HTML and CSS, supports SVG (by way of LunaSVG) and Lua, and integrates well with SDL (2 and 3).

[Gurudumps]

Yes the lay looks good, quite impressive actually. But the full view is unreadable unless viewed on a 100cm 4K tv. A bolder font would help. The fonts would need to be open source alternatives as you can't use trademarked items (including logos) in open-source projects plus MAME would not ship those fonts (or any other fonts) with the distribution anyway.
The layout is not designed as a full replacement for the real thing. It just makes it more usable. To have the full experience use an external png in one of the views that when selected will have a much nicer look identical to the original device. The point is having a better font in the lay that isn't hard-coded means it can be changed. The very poor barebones svg render engine is also part of the problem but in reality, likely none of these issues will ever be fixed. But I'd like to be surprised :-)

[cbrunschen]

The 'Full' view of the VFX family is just big - because it's representing the actual size of the synthesizer. Of course any text on it will be small unless you show it on a large display; but that's not a fault with MAME layout's text rendering. Plus, there are the 'Compact, 'Panel' and 'Tablet' views, that give different zoomed-in versions that should allow any user to find a version that is more legible.

My point was more that your proposal of specifying a single "layout font" would be insufficient for these panels, because there is more the one font in use on these keyboards (both Regular and Bold weights, both Normal and Italic styles, in this instance).

Using an external PNG file would limit the maximum resolution at which the layout can be displayed without showing upscaling artefacts; vector graphics including vector fonts can be scaled to any size.

[Gurudumps]

I'm fully aware of the additional views. They are fine and useful, especially the compact view. There is nothing wrong with your lays, relax. It was only an example because it is probably the largest device with a lay and more clearly shows the problem.
You have missed the point completely. We could argue about what needs to be done to fix everything for years and likely all of it will be ignored.
This is about being able to change the layout font to anything other than the default hard-coded font. It is also about using a free an open-source font as the default instead of what the various different OS's provide.
Uniformity and consistency.
Unless the original professional software engineer dev who really knows what they are doing comes back onto the team and modernised the lay system (which I doubt will ever happen thanks to another dev disagreeing with something and telling him to go read a C++ book causing him to quit the skene) the only way is to make it slightly better in small increments.
Being able to change the layout font is step #1.
Having the emulated device be able to read a device-specific ini for the layout font is step #2.
Hooking up ThorVG svg render engine (or any svg renderer that supports all the svg commands not just a subset of them) is step #3.
Doing #3 solves your problem... multiple fonts can be listed in the xml/svg and selected for drawing text. Currently the svg text command is not supported at all, which seems bizarre given a layout is essentially lines and text. The current nanosvg is really just garbage and should never have been used, but perhaps it was the only one available back then and the dev didn't want to write one from scratch. We know better now.
With the text command supported these below are possible.

3 Examples:

<-- Text with different fonts -->
<svg width="500" height="150">
  <text x="20" y="40" font-family="Arial, sans-serif" font-size="24">This uses Arial</text>
  <text x="20" y="80" font-family="Times New Roman, serif" font-size="24">This uses Times New Roman</text>
  <text x="20" y="120" font-family="Courier New, monospace" font-size="24">This uses Courier New</text>
</svg>

<!-- Text with fall-back fonts -->
<svg width="400" height="100">
  <text x="10" y="50" font-family="Arial, Helvetica, sans-serif" font-size="32" fill="black">
    HELLO WORLD
  </text>
</svg>

<!-- Text with bold / italic -->
<svg width="400" height="100">
  <text x="10" y="30" font-weight="bold">This is bold text</text>
  <text x="10" y="60" font-style="italic">This is italic text</text>
  <text x="10" y="90" style="font-weight:bold; font-style:italic">Bold and italic</text>
</svg>

[cbrunschen]

I'm not missing your point, I'm disagreeing with it.

You picked the specific example of the sd132 layout, so I'm looking at your suggestion in that context.

To make the sd132 layout look its best, being able to specify a single "layout font" is not a sufficient solution: it needs two different fonts, from the same family, but differing in style and weight.

Further, it needs those fonts to be metric compatible with Helvetica / Arial - so perhaps the Liberation Sans fonts, or URW Nimbus Sans - but Noto Sans would not be the correct choice, because its metrics differ. So including specifically Noto Sans and using that by default doesn't help the sd132 layouts.

So even as a step 1, a better solution even for the specific layout you picked as an example would be to allow each text element to specify its own font - because it needs more than one.

Yes, going full SVG (or something like RmlUI) would allow text in arbitrary fonts, but then that would rather significantly bloat the layout: every single <text> element would have to be replaced by

  <data>
    <![CDATA[
      <svg>
        <text font-family="Helvetica,Arial,sans-serif" find-style="italic" font-weight="bold">Hello</text>
      </svg>
    ]]>
  </data>
</image>

It seems to me that extending the existing layout <text> element to also accept an attribute to specify the font to use gives a lot more flexibility at a lot lower cost, implementation-wise.

Something like #14533 might be a starting point.

[Gurudumps]

My later examples address all of that. With small steps it might be done. With one giant step it will not be done.
You are forgetting ONE very important thing. You are not fixing the issue(s).
If you can fix it then just do it. If you can't then you are at the mercy of someone coming along who is capable of fixing the problems AND also gives half a f*#k about fixing this issue. Being capable and doing it are not the same.

[Gurudumps]

That PR looks interesting but I doubt it'll be accepted because it's a bandaid solution. But as far am I'm concerned it looks good :-)
When doing a PR be positive... here is the solution, tested working.
Not.. here is something that might work sometimes maybe if the wind blows in the right direction (using the word strawman in the description was a mistake ;-)
If the entire nanosvg is replaced with a proper svg renderer then the regular text could use your changed version and more advanced text like rotated text needed for the Virus A layout could be done using the svg text command with rotation applied (which currently does not work because the svg text command is unsupported).
I wonder if the svg text command could be added to the existing out-dated/obsolete dead nanosvg project?
But maybe your PR is a good first step.
Also remember if your fonts are not installed on the target system then it will revert to the default so will look exactly the same as before, or more likely worse since the positions may have been changed to make it work with the correct fonts (start position and height/width). MAME won't distribute extrra fonts even free ones. Ideally if a layout script can check for installed fonts and if not found show a message to the user that would be the solution. If the user continues as-is they were warned so the bad looks are their problem ;-)
To get a font into the MAME distribution someone would need to create one giant truetype font file (perhaps a merge of some noto fonts) with a finite selection that will be useful for almost everything including italic, bold, wide, narrow and a Japanese character set. Wide and narrow fonts could be omitted if stretching fonts is fixed.
Currently text can't be stretched. Can you fix that?
The only way to make fonts longer is by increasing the height. However I would think that limitation would not apply to svg text. If kerning can be added (adjusting the spacing between characters) then it would be possible to make text fit into any position to match the original.
I suspect it'll just be ignored or rejected because "it's a hack" or some other fictional excuse.
But good luck with it! ;-)

[felipesanches]

"stretching fonts"...
Sounds like variable font support would help in that case.

[felipesanches]

One of the most annoying aspects of the current poor quality text support in MAME layouts is that the actual bounds of the rendered text do not match the values passed on the bounds tag. I think the reason for that is probably because there's some blank space above and below the text in the rendered buffer.

Also, the align attribute being a numerical value (0, 1 or 2) is not very intuitive. And "align left" is pretty much useless if the rendered text has some left padding, because it ends up not visually aligning to anything.

I think that a revamp of the text support needs to take these things in consideration. It must be possible to say (via code): "This computer panel has a text label that fills the exact area of this rectangle and it uses a Bold Italic typeface. Use this familyname if available, otherwise, 'stretch' any other font to fill this area.".

Then, the 'stretching' can be done the dirty way, which completely distorts the text, or the nice way which is by using a variable font with a width axis and computing which axis coordinate to use that would result in that exact bounding box width, at that selected fontsize.

[Gurudumps]

It just needs to properly support truetype fonts. Any ttf can already be sized / rotated / squashed /stretched / warped or whatever way you want using software like Photoshop, Illustrator, Corel Draw etc. The limitation is MAME lacking certain layout functionalities that are required for good looking and accurate layouts. It was more designed to provide simple and basic text, boxes, lines, circles and background png support. No one could have ever imagined we would now be seeing working emulation of so many advanced devices that require artwork to be usable.

[Gurudumps]

Another problem with bounds is there are sometimes multiples which can accumulate errors. I'm sure you've seen it before. You declare the text or rect (or whatever), then use it in a group with other elements to make a module, again with a bounds, start position and width/height. Then you put that module into the view area and again have another bounds with the start position and also a width/height.... but if the width/height doesn't add up to the same as the defined group there will be shifting left/right/up/down by some amount which can be tricky to figure out where the mistake is because the bounds area is invisible. The solution would be to define the size ONCE and then just put it somewhere after with only the start position. In the bounds command the width/height could be optional if the element has already been defined with a bounds once (like element ref="itemname" bounds = x y width height etc. within a group) Also, having the bounds of all objects visible by turning on some kind of layout dev mode will help to see out-of-position errors which I had mentioned previously in the Virus commit.

[Gurudumps]

Unfortunately there is another UI font problem which I've noted in MT 7977: most standard fonts (including the NotoSans-Bold.ttf packaged with MAME) lack glyphs for katakana, which is important for many Japanese computers.

MAME's font handling is very clumsy and outdated but doesn't seem likely to be replaced soon. The rewrite seems to be contingent on a new rendering layer which exists mostly in the minds of one or two MAMEdevs.

ajrhacker: Just a FYI, I was looking today at the Noto full archive. There are tools there to merge any fonts together into one file. So just find the font you need for katakana (or whatever) and merge it with Noto Sans Bold into one font file and then hide that in the same dir with the other bundled fonts ;-)
At least then it will be possible to use it if/when the layout truetype font PR gets added.

[galibert]

455M noto
299M noto-cjk