Comment 9 for bug 179589

Whenever the pdf specifies a font-family it is used to set the svg font-family. The pdf you attached (as well as the pdf I created with AI) seem to specify the family name correct (with spaces) and as such just copying the name into the svg, as the current code does, is ok.

Whenever the pdf does not specify the font-family (which was the case with most pdf's I tested) the svg font-family is based on the fonts stripped down (Orig)Name (without spaces).

The patch did the font name matching in both these cases, but since it seems that the pdf font family is a way to specify the correct name, including spaces, I removed the matching in this case in the attached patch again. This speeds up things as matching is skipped when font-family is specified (*).

Concerning -inskscape-font-specification I was (and am still) not sure about what value it should get and if the current code is correct. The patch does not change anything here. Is the current behaviour correct (without spaces, ...)?

(*) I'm aware that the matching as in the patch is slow since every time all availble font names are fetched for comparison (code from Text and Font dialiog). Especially when text is split in small portions as in some pdfs this causes much overhead. I don't think it's worth to try to optimize much until the font substitution is handled in a general way.