Sans font not available in .91 from .48

I have done some additional testing and attached an example file prepared with ver.48. This example has 3 lines of text in varying size i.e. 40, 64, 72. At the bottom of the page is an image of the text.

When opened in ver.91 the sans text is shown as unavailable, but also the size of the text is changed from the sizes created in ver.48.

I am just guess from my testing that Sans font from previous vers i.e. .48 is the same as arial font. In ver.91 This requires the extension replace_font under texts in extensions to be used to convert the now unavailable Sans font to Arial. The texts converted to Arial appear to be identical to the image of the Sans font text as it appeared in ver.48.

Reproduced on Windows XP, Inkscape trunk rev. 13979.

Sans was a generic font name used in 0.48, but changed in 0.91 to sans-serif in order to be consistent with CSS generic font names (see http://www.w3.org/TR/CSS21/fonts.html#generic-font-families). Replacing Sans with sans-serif in all affected text should fix the "Font not found on system: Sans" warning.

Note that generic fonts are a fallback mechanism, and that Inkscape maps the font to a real font. The size issue is due to the fact that the generic sans-serif font was mapped to Arial (used in the bitmap copy at the bottom of your file) in 0.48, and is now mapped to DejaVu Sans in 0.91, hence the size difference.
Weirdly, the font preview (in the Text and font dialog) shows an Arial font when the invalid Sans font is selected...

Thus if you need your file to look exactly as it looked in 0.48, you can replace your Sans fonts with Arial as a workaround.

On 2015-03-09 11:25 (+0100), jazzynico wrote:
> Note that generic fonts are a fallback mechanism, and that Inkscape
> maps the font to a real font.

AFAIU that mapping is actually done by fontconfig (0.91 uses that
instead of the win32 backend for pango on Windows).

> Weirdly, the font preview (in the Text and font dialog) shows an
> Arial font when the invalid Sans font is selected...

Similar mismatches are also observed on OS X (if using GTK+/Quartz and
pango's coretext backend) - the font preview in the 'Text and Font'
dialog in 0.91 seems to no longer use the same internal rendering as
on-canvas as before the merge of the cairo-rendering branch, and
apparently is not based on the same init or configration information as
the fontconfig-based pango backend (used on-canvas).

Default/preferred fallbacks for generic fonts in fontconfig:
win32:
http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs/trunk/view/head:/etc/fonts/conf.d/60-latin.conf#L16
win64:
http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs64/trunk/view/head:/etc/fonts/conf.d/60-latin.conf#L17

For osxmenu packages, I currently use a custom font config to "force" a similar order of preference as seen in native web browsers:
http://bazaar.launchpad.net/~suv-lp/inkscape/osxmenu/view/head:/packaging/osx/Resources/etc/fonts/local.conf#L35

(this though will result in different appearance depending on whether the official package or an osxmenu build is used to render text in SVG files with 'sans-serif' as specified font.

Related: Bug #1445981 "Font not found on system: Sans"
https://bugs.launchpad.net/inkscape/+bug/1445981

Maybe we could implement a startup test and semi-automatically (after asking the user) convert sans to sans-serif in the texts when the old default name is used in an old document (inkscape:version <0.91).