Debian Bug #340855 inkscape: Font dialog messes font style of FreeSans, FreeSans and FreeMono
Hi alltogether,
I received the following bug report in debian's BTS at http://bugs.debian.org/340855. Althou it refers to 0.43pre2, I can reproduce this bug on my machine with 0.43. I did not submit it to the tracker since I am not sure if it is a problem with inkscape or the debian package, so my question is if someone can reproduce this bug.
Thanks for help,
Wolfi
----- Forwarded message from Kai-Martin <kmk(at)familieknaak(dot)de> -----
Subject: Bug#340855: inkscape: Font dialog messes font style of FreeSans, FreeSans and FreeMono Reply-To: Kai-Martin <kmk(at)familieknaak(dot)de>, 340855@...499... From: Kai-Martin <kmk(at)familieknaak(dot)de> To: Debian Bug Tracking System <submit@...499...> Date: Sat, 26 Nov 2005 13:59:03 +0100 Resent-Sender: Debian BTS <debbugs@...499...>
Package: inkscape Version: 0.42.2+0.43pre2-1 Severity: normal
The font dialog messes the font style for some fonts. This is what happens with the various styles:
"Medium/Regular": The font style jumps to "Bold" when pressing the apply button. Make default sets the default font style to bold. Consequently the font actually used in the drawing is bold.
"Oblique/italics": No problem. "Bold": No problem.
"BoldOblique/BoldItalic": The font preview shows a regular style. The apply button sets the font used in the drawing to "regular".
This behavior is consitent with all three "Free" fonts (Free Mono, FreeSans and FreeSerif). Other fonts that also come in different styles (e.g. Sans or Courier) can be set as expected.
The font chooser of the gnome system (MainMenu/System/Settings/Fonts) seems to use the same font chooser dialog. Yet it does not suffer from the described symptoms.
---<(kaimartin)>---
-- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-1-k7 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Versions of packages inkscape depends on: ii libatk1.0-0 1.10.1-2 The ATK accessibility toolkit ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library ii libc6 2.3.5-3 GNU C Library: Shared libraries an ii libfontconfig1 2.3.1-2 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgc1c2 1:6.5-1 conservative garbage collector for ii libgcc1 1:4.0.2-3 GCC support library ii libgconf2-4 2.10.1-1 GNOME configuration database syste ii libglib2.0-0 2.8.0-1 The GLib library of C routines ii libglibmm-2.4-1c2 2.6.1-1.2 C++ wrapper for the GLib toolkit ( ii libgnomevfs2-0 2.10.1-5 The GNOME virtual file-system libr ii libgtk2.0-0 2.6.9-1 The GTK+ graphical user interface ii libgtkmm-2.4-1c2 1:2.6.2-1.1 C++ wrappers for GTK+ 2.4 (shared ii liborbit2 1:2.12.2-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.8.2-1 Layout and rendering of internatio ii libperl5.8 5.8.7-7 Shared Perl library ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsigc++-2.0-0c2 2.0.10-3 type-safe Signal Framework for C++ ii libstdc++6 4.0.2-3 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxml2 2.6.21-1 GNOME XML library ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxslt1.1 1.1.15-1 XSLT processing library - runtime ii xlibs 6.8.2.dfsg.1-7 X Window System client libraries m ii zlib1g 1:1.2.2-4 compression library - runtime
Versions of packages inkscape recommends: pn dia | dia-gnome <none> (no description available) ii imagemagick 6:6.2.4.5-0.2 Image manipulation programs ii libwmf-bin 0.2.8.3-2 Windows metafile conversion tools pn perlmagick <none> (no description available) ii pstoedit 3.33-15 PostScript and PDF files to editab ii sketch 0.6.15-1 Interactive vector drawing program
-- no debconf information
----- End forwarded message -----
This behavior is consitent with all three "Free" fonts (Free Mono, FreeSans and FreeSerif). Other fonts that also come in different styles (e.g. Sans or Courier) can be set as expected.
This could be construed either as a problem with the TTF files or with Pango.
Line 756 onwards of pango/fonts.c (http://cvs.gnome.org/viewcvs/pango/pango/fonts.c?view=annotate) provides a list of common synonyms for various styles of fonts which are used by pango_font_description_from_string(). Neither "Regular" nor "BoldOblique" are in the list, which is why they can't be set. ("Normal" is down a bit on line 811, in case you're wondering.)
Inkscape makes the problem obvious because when you click Apply it sets the font then immediately re-reads the style it set in order to update the dialog box. I wouldn't be surprised if other applications using Pango exhibited some variation on the same problem on their canvas, even if the standard GTK font chooser didn't update to show the incorrectness.
My favoured solution would be both to fix the TTFs so that they use more standard names and to add the nonstandard names to Pango. Hopefully that way the problem would get fixed as quickly as possible for as many people as possible.
Richard.
On 11/28/05, Richard Hughes <cyreve@...400...> wrote:
My favoured solution would be both to fix the TTFs so that they use more standard names and to add the nonstandard names to Pango. Hopefully that way the problem would get fixed as quickly as possible for as many people as possible.
Both these approaches are good, but they are not the final solution. First, you'll never be able to cover all possible synonyms, especially given that some fonts use non-English names of variants. Second, and more importantly, many professional fonts contain variants which are not expressible with CSS semantics at all - for example Swash, Outline, or Alternate. So if you try to convert that to CSS and then back, you will never get the same font because CSS simply does not have such font attributes. This is the subject of this long-standing bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=904962&grou...
Perhaps the easiest way to fix this is: On font assignment, check if the variant name is "standard" and is going to be translated into CSS without loss. In that case, do nothing as now. Otherwise, store the complete font name (family + variant) in the "font-family:" property, approximating other properties as best we can. Then on reading the SVG, see if the font-family matches any available family. If not, try to interpret it as family + variant. (This is just a rough outline; it's been long since I looked into that code, but I think this should work. Alternatively, we can add a custom CSS property for storing exact family+variant, but this will be much more cumbersome to implement.)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Perhaps the easiest way to fix this is: On font assignment, check if the variant name is "standard" and is going to be translated into CSS without loss. In that case, do nothing as now. Otherwise, store the complete font name (family + variant) in the "font-family:" property, approximating other properties as best we can. Then on reading the SVG, see if the font-family matches any available family. If not, try to interpret it as family + variant. (This is just a rough outline; it's been long since I looked into that code, but I think this should work. Alternatively, we can add a custom CSS property for storing exact family+variant, but this will be much more cumbersome to implement.)
Somehow, Win32 manages to name the variants normally, ie "Normal", "Italic", etc, so I think an even better solution than this must exist. I don't think I've got any fonts with many different styles (eg italic and oblique separately) so I couldn't say what it does with them.
I agree that trying to guess a font's style from its name is a ridiculous thing to do.
Richard.
On 11/28/05, Richard Hughes <cyreve@...400...> wrote:
Somehow, Win32 manages to name the variants normally, ie "Normal", "Italic", etc, so I think an even better solution than this must exist. I don't think I've got any fonts with many different styles (eg italic and oblique separately) so I couldn't say what it does with them.
Perhaps Windows does some pre-translation of several known variant names into "standard". But it's not likely that it will be able to handle Swash or OSF (OldStyleFigures) variants. If you don't have fonts with such variants, I can send some examples to you.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (3)
-
bulia byak -
Richard Hughes -
Wolfram Quester