I am not sure if this is a bug or some of my setting is not right.
I am using a special font for headers and I have online both the regular and the italics uploaded.
When I see the page online, it works fine, when I make the pdf it is rendered italicised (italics applied to the italics!)
My CSS is

@font-face {
  font-family: 'Museo 500';
  src: url("http://www.engramma.it/eOS/core/fonts/Museo500-Regular.eot");
  src: 
  url("http://www.engramma.it/eOS/core/fonts/Museo500-Regular.otf") 
  format('opentype');
}
@font-face {
  font-family: 'Museo 500';
  src: url("http://www.engramma.it/eOS/core/fonts/museo-500-italic.eot");
  src: 
  url("http://www.engramma.it/eOS/core/fonts/Museo-500Italic.otf") 
  format('opentype');
  font-style: italic;
}
h2 {
          font: normal 36pt/43pt "Museo 500";
                }
em, i {font-style: italic;}

Without the "em, i {font-style: italic;}" no italic was rendered in the PDF pages (browsers would do that).

I'm guessing this is an issue with the font incorrectly declaring itself to be not italic and thus Prince is slanting it unnecessarily, can you try applying the --no-artificial-fonts option to Prince?

Thank you for the suggestion. If running "C:\Program Files (x86)\Prince\prince-gui.exe --no-artificial-fonts" is what you are talking about, unfortunately I got no difference. I try if I can change the font declarations.

EDIT:
I used the options on the command line and they worked. But still I don't think it is my fault...

Edited 26 May 2019 by liladude

Right, the option only applies to the command-line engine, not the GUI.

thank you, mikeday! I figured this! Now it works, but even if I declared the italics in the font, it did not worked whitout it!

We may try to address this in future by allowing the @font-face declaration to overrule the data in the font itself, this just requires some care to get right. Another alternative would be to expose the artificial slanting via a custom CSS property so it is easier to adjust.

Thank you! do you happens to know if I can have the -no-artificial-fonts option in DocRaptor too?

Good question, it doesn't look like it's supported, but I would think it would be easy for them to add as it is so similar to the switches for font embedding and font subsetting, which are supported.

We have now fixed this issue in latest builds, so future versions of DocRaptor based on Prince 13 will not have this problem.