Ok, one final comment after switching to Arial. We landed on the following:

```

    "privateFonts": [
      {
        "fontFamily": "Arial",
        "path": "ARIAL.TTF"
      },
      {
        "fontFamily": "Arial",
        "path": "ARIALBD.TTF",
        "fontStyle": "Bold"
      }
    ],

```

1. TextBoxes in reports will render "ok" with just the ARIAL.TTF regular font. However, in the HTML5 report viewer, if you have a textbox with a bolded font, the width will be calculated incorrectly and text can be cut-off. By putting the bold font last, it seems to use Bold when calculating widths which makes the bold textboxes work and doesn't seem to negatively impact non-bold textboxes.
2. Whatever font is last is the ONLY font use to render ANY text on charts and graphs. So, even if you have regular or italics on labels or legends or captions, it just uses Arial Bold without any italic on all text. 
3. What feels odd (and why this has been so hard to completely track down) is that bold, italic, and regular Arial text all seem to render fine in textboxes/tables (with the exception of the width calculations in the HTML5 viewer) in the HTML5 viewer and on exported reports.

Hey Dimitar, 

In further testing, what I've found is:

1. You cannot specify multiple styles of a font in your private fonts. It just doesn't seem to work or make any difference. The only one that is ever used is the last one listed that matches the name of the font used on the report.
   1. So, in the case where I specified 4 fonts with specific names (none of which were just "Calibiri"), the tracing indicated that Calibri couldn't be found and reverted to Deju Vu Sans (on Linux) - although in the HTML5 viewer, Calibri was used sporadically throughout the report.
   2. If I give them all a fontFamily of "Calibri" then the HTML5 viewer looks great, but exporting graphs seems to just use the last font in the list (hence in my screenshots, the graphs were using Bold+Italic - the last one in the list). See this duplicate bug report: https://feedback.telerik.com/reporting/1686068-excel-export-with-skia-renders-the-text-in-the-graph-with-bold-font-although-it-is-set-as-regular-in-the-report
2. If I ONLY include a single font, Calibri Regular, and give it a fontFamily of "Calibri", the HTML5 report viewer renders the report fine, but exporting is still broken because apparently Linux and Calibri just don't get along? 🤷
3. Some other fonts seem to work ok, especially fonts that come with only a single font file. Examples include Noto Sans, Arial, Tahoma, and Times New Roman. 

Hey Dimitar,

Ok, I went through this again, and I think I might have crossed some wires in my last response. In that post, the correct screenshot is using Arial as you noted. However, I think the incorrect screenshot is using Calibri (which is the font I've been trying to use for reports). 

So, what I'm finding is that when using a font like Calibri, which has 4 different font files (Regular, Bold, Italic, Bold+Italic), things don't export properly on Linux. And they don't export properly on Windows/Skia unless you list the fonts in a particular order. 

Currently, our privateFonts section looks like this (and this produces the bad results shown in both my original screenshots and the contrived graph-test.trdx example on both platforms):

```

    "privateFonts": [
      {
        "fontFamily": "Calibri",
        "path": "Fonts/CALIBRI.TTF",
        "fontStyle": "Regular"
      },
      {
        "fontFamily": "Calibri",
        "path": "Fonts/CALIBRII.TTF",
        "fontStyle": "Italic"
      },
      {
        "fontFamily": "Calibri",
        "path": "Fonts/CALIBRIB.TTF",
        "fontStyle": "Bold"
      },
      {
        "fontFamily": "Calibri",
        "path": "Fonts/CALIBRIZ.TTF",
        "fontStyle": "Bold, Italic"
      }
    ],

```

If I change it to the following, it actually starts to work properly on Windows/Skia, but it still does NOT work on Linux:

```

    "privateFonts": [
      {
        "fontFamily": "Calibri Bold",
        "path": "Fonts/CALIBRIB.TTF",
        "fontStyle": "Bold"
      },
      {
        "fontFamily": "Calibri Regular",
        "path": "Fonts/CALIBRI.TTF",
        "fontStyle": "Regular"
      },
      {
        "fontFamily": "Calibri Italic",
        "path": "Fonts/CALIBRII.TTF",
        "fontStyle": "Italic"
      },
      {
        "fontFamily": "Calibri Bold Italic",
        "path": "Fonts/CALIBRIZ.TTF",
        "fontStyle": "Bold, Italic"
      }
    ],

```

NOTE, the `Fonts` folder is distributed with our app.

Am I doing something wrong with defining those fonts? Or does this just not work on Linux? Note the order DOES matter for Windows/Skia (I didn't fully vet that out, but when I had the Regular font first, I still got weird results, moving it to the 2nd item in the list allowed me to render all 4 styles of fonts). Again, in Linux, no matter what order I use and no matter what I put in the fontFamily field, I get bad results. 

Hey Dimitar,

So, the problem is that the export from the stand-alone designer does NOT match up to the export from a .NET Core application. And the problem is worse when that .NET Core application is run on Linux. 

So, I took the report you shared and I modified it slightly to more closely match my report:

1. Added "Titles" on the X and Y axis.
2. Modified the data to take in an actual date (rather than a string)
3. Modified the grouping on the X axis to group by Month name (like my report does).

When I export that from the stand-alone designer, it looks like it looks on screen (in either Skia or GDI mode). Like this:



However, when I run it through my app (again, an asp.net core app on my Windows 11 development machine, but running via the Skia engine) and export it (via the HTML5 report viewer), then I get output that looks like this:

In this contrived example, I've highlighted in yellow how the side caption (Title) and the X-axis labels get randomly messed up. Again, this is done via my Window 11 development machine in an asp.net core web app exporting to Excel through the HTML5 report viewer interface. If I could deploy this to my Azure App Host (which runs on Linux), I suspect the output would likely be a bit worse. 

I've attached my modified report and exports from the stand-alone designer and from the asp.net core app.