Font path seems to have been hardcoded for Mac?

[farzadmf]

The code seems to do os.Open("/Library/Fonts/Arial Unicode.ttf"), which I think is only valid for a Mac

[ljacobsson]

+1 here on Ubuntu

Really eager to build support for this in cfn-diagram

[ugwis]

Thank you for reporting issue!

Yes. It was hardcoded.
I've confirmed that AWS architecture guidelines recommend Arial for as a universal font that everyone can use. Although the redistribution of Arial font is prohibited, it is pre-installed on major operating systems such as Windows and macOS (and in the case of Ubuntu, it is distributed as a package). Although it is possible to embed redistributable fonts into executable binaries, there are many considerations, including compatibility with Unicode, so we do not currently plan to embed them into binaries.
However, we will add attributes to the definition file to allow users to specify custom fonts.

Work procedure:

• 1. Hardcode the path to the pre-installed Arial font for each operating system.
• 2. Make it possible to specify the font path (and font name, font URL) in the definition file and template.

[farzadmf]

Thank you for the update @ugwis ; hopefully those things will be implemented soon. And I'm not sure if "non-gui" Linux distributions will somehow include fonts (probably they do?!)

---

And also the resources seem to be limited? For example, I tried to add AWS::StepFunctions::StateMachine (from here), but that didn't work

[ugwis]

In #19 I specified the path to the font on Linux and Windows. Font paths should not be hard-coded, but will be removed if we add an implementation that searches for font files by font name.

I have confirmed that the Arial font is included in ttf-mscorefonts-installer, and it's possible to generate it even in a non-GUI environment with the latest commit.

$ sudo apt install ttf-mscorefonts-installer
$ fc-list | grep Arial
...
/usr/share/fonts/truetype/msttcorefonts/Arial.ttf: Arial:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,thường,Arrunta
$ awsdac vpc-natgw.yaml

I tried to add AWS::StepFunctions::StateMachine (from here), but that didn't work

Available resource types are still limited. we need to create a list of resource types. I added a workaround using presets for undefined resource types to #20.

[ojacques]

For distributions - such as Ubuntu - one can use the Liberation Fonts, as an alternative to Arial.ttf with this workaround :

sudo ln -s /usr/share/fonts/truetype/liberation2/LiberationSans-Regular.ttf /usr/share/fonts/truetype/msttcorefonts/Arial.ttf

@ugwis - if Arial.ttf is not found, could the code fall back to LiberationSans-Regular.ttf automatically?

[ugwis]

Thanks for your suggestion! @ojacques

I'm not familiar with alternative fonts for Arial, but LiberationSans seems to be intended as an alternative to Arial and provided by many distributions (I Confirmed repositories provided by rpm, apt, alpine).
Since MS Core fonts repository is not provided by many Linux distributions, I thought it would be a good idea to use it, so made some changes to be able to fall back to LiberationSans. (Currently, font paths must be specified as absolute paths.)

https://github.com/awslabs/diagram-as-code/pull/93/files#diff-87fdc040d7845c23f8fa118c5ef3874db366ad1d9d43883f4cec2048fb4e3d39R9-R15

var Paths = []string{
	"/usr/share/fonts/truetype/msttcorefonts/Arial.ttf",                // For Ubuntu linux ttf-mscorefonts-installer package.
	"/usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf",  // For Ubuntu/Debian Linux fonts-liberation package.
	"/usr/share/fonts/truetype/liberation2/LiberationSans-Regular.ttf", // For Ubuntu/Debian Linux fonts-liberation2 package.
	"/usr/share/fonts/liberation-sans/LiberationSans-Regular.ttf",      // For Fedora/AL2023 Linux liberation-sans-fonts package.
	"/usr/share/fonts/liberation/LiberationSans-Regular.ttf",           // For Alpine/Arch Linux ttf-liberation package.
}

[chenrui333]

any updates on this thread, seeing the similar issue in Homebrew/homebrew-core#175896

[ugwis]

@chenrui333
I'm sorry for my late reply. Yes, test failure is the font issue in Linux.
We are currently considering a solution, so no action is required on brew-core side.