Various fonts refuse to render properly

[The-n0id]

On my system some fonts refuse to render properly in
Inkscape. This however only seems to effect some of my
fonts and in other applications (like Gimp) even those
fonts work fine.

I have no idea as to how/why this happened and I used
to be able to use all my installed fonts in Inkscape,
but something seems broken or badly configured
somewhere on my system.

I'm currently using the 0.42.2 version of Inkscape on
an AMD64 Gentoo system with a 2.6.11 Linux kernel. And
as said before, everything else concerning my fonts
seem to work without any problems what so ever.

To provide you all with some more in depth information
please check out the following examples:

Screenshots of fonts in Inkscape/Gimp on my system:
http://paran0id.mine.nu/inkscape/Arial_Black_TTF.png
http://paran0id.mine.nu/inkscape/Chicago_TTF.png
http://paran0id.mine.nu/inkscape/LucidiaBright_PCF.png

...as you may see from the shots, "Arial Black" works
both in Inkscape and Gimp, while both "Chicago" and
"Lucidia Bright" only look as they should in Gimp. Also
please note that "Lucidia Bright" is a PCF font, while
the others are TTF.

The Module and Files sections of my xorg.conf file:
http://paran0id.mine.nu/inkscape/xorg_conf.txt

Installed packages on my system needed by Inkscape:
http://paran0id.mine.nu/inkscape/installed_pkgs.txt

Some parts of /usr/share/fonts/ on my system:
http://paran0id.mine.nu/inkscape/fonts_fs.txt

If more information would be required to resolve this
issue I'll of course provide such on request.

...and last but not least, any help or tips would be
really appreciated!

Thanks in advance

Mr. n0id

[The-n0id (the-n0id)]

Ok, here's my latest take on this issue. It seems the
problem has to do with the mapping of the fonts. After
editing the Chicago TTF with a font editor and adding
"Microsoft Unicode BMP only" mapping to the font (used to
only have Apple mapping) it now works as it should in Inkscape.

Maybe this info could shed some light on where the problem
is located and how to resolve it. To be frank I'm not that
familiar with various fonts and their makeup, but maybe
someone with such knowledge could sort this out!?

// n0id

[Bug Importer (bug-importer)]

i've had exactly the same problem with 0.42 qith a number of
coreldraw supplied .ttf fonts. i've had to stay on a
previous version, 0.41 i think. i've tried using 0.42 on
mandrake 9.2, mandriva 2005 and 2006, all with the same
effect. i'd agree, the fonts look fine on every other app
i've tried. and some fonts are always fine in inkscape, and
some are never ok in 0.42. it doesn't seem to vary by the
version of mandrake i'm on.

**

could you let me know what editor you used to mark the font
as microsoft unicode bmp?

**

<email address hidden>

[The-n0id (the-n0id)]

First of all "nobody", please excuse my late reply but I've
been having my hands full lately.

Anyway, when it comes to the application I used to edit my
fonts it was a shareware application for Windows called
"Font Creator". Sort of a messy way of doing things but I
ran it through Wine and fixed my fonts from there. This of
course doesn't solve the Inkscape issue itself but at least
it's a temporary solution.

The Font Creator application can be found at:
http://www.high-logic.com/fcp.html

...and Wine is available at:
http://www.winehq.org/

Hope this helps until there's a more permanent solution for
the problem.

// n0id

[Richard Hughes (cyreve)]

I've been looking at this bug for the past few days without
doing anything about it, but now Bulia's assigned it to me I
suppose I've got to admit that I haven't got a clue what the
problem might be. The following text, therefore, is composed
of 50% random guesswork and 50% grasping at straws.

- Try wiping your font caches and starting again:
  cd /usr/share/fonts
  find . -name fonts.cache-1|xargs rm -f
  fc-cache .

- I have a font called "Lucida Bright" which works for me on
0.42.2 (Win32), however I think it looks slightly different
to yours. lbrite.ttf 70,748 bytes, md5
825a2395154f2a944b653bcb7839dd27

- The only part of the code which I think is unusual is that
we force all fonts to be 'outline' (whatever that means: I
don't know much about the internal structure of ttf either).
If a font is not outline then we'll sometimes fail to load
it and sometimes coerce the outline property on, possibly
causing a different font to be selected.

- Your Chicago screenshot looks particularly interesting
because of the massive amount of kerning on the T's. Since
the real Chicago has quite narrow T's, this could mean that
the correct metrics are being used but the wrong glyphs. Can
you try some other characters to see if you can figure out
if that is the case, or if it's just normal kerning?

- I might think of something else to add later. We'll see.

[Buliabyak-users (buliabyak-users)]

Originator: NO

cyreve, any news/progress/insights on this one? may it have fixed itself
during the past year? may font quoting i just committed help?

[agb (agb-ukr)]

Look, please here:

http://lecom-ltd.com/dwl/ooo.gif - OpenOffice: Tahoma, 12pt, Scale 100%, Screenshot
http://lecom-ltd.com/dwl/ink.gif - Inkscape 45.1: Tahoma, 10pt, Export to PNG on 90dpi, Screenshot

Why pictures are different? How can I get picture like from OOo?

[agb (agb-ukr)]

WinXP pro sp2 rus
if this info helps to identify problem

[Buliabyak-users (buliabyak-users)]

latest comment is on a different problem, see bug 170392

can anyone reproduce the original problem? this report is very old.

[bbyak (buliabyak)]

since it's so old and not confirmed recently, setting to incomplete - unless someone comes up with more data it will expire in 60 days

[Bruce Alderson (mx-warpedvisions)]

I'm pretty sure that I'm seeing the same bug, which looks like a rounding error in the font rendering (and/or anti-aliasing) code. Example:

http://robotpony.ca/images/2008/programmers-consistency.png

The text along the bottom is properly rendered in the center ("EVENTUAL"), but is fuzzy on both the left and the right portions. I find this is the case with most fonts, but it's most clearly visible in this example (combination of font + size + color make it obvious).

The font is Kottke's Silkscreen TTF font, available from:

http://www.kottke.org/plus/type/silkscreen/

[Richard Hughes (cyreve)]

Bruce: The behaviour demonstrated in your image is expected. Unlike the normal 'for screen' renderer used for displaying GUIs and stuff, Inkscape always attempts to display things as they are described. This means that for your font, where the width of each character is very slightly less than an integer number of pixels, you'll get a slight drift which causes the antialiasing to become pronounced. Zooming in/out or changing the font size will alter the numbers involved so that it doesn't look quite so odd any more.

[Bruce Alderson (mx-warpedvisions)]

My apologies, I thought the issue was related. What I found confusing is that the effect was not consistent over the path of the text (in this case it's clearer in the center, and fuzzier at the edges).

[Troy James Sobotka (troy-sobotka)]

I've noticed some extremely strange rendering on my end. There is most certainly something broken under the hood here - either in the fonts themselves or in Inkscape. Somehow GIMP and OpenOffice deal with the following font entirely correctly.

The following should help illustrate this and hopefully shed some light on the issue.

First, a rendering of the font as it appears in GIMP and OpenOffice. This is direct output from GIMP:
http://img168.imageshack.us/img168/5627/gimpoutput.png

Now a rendering out of Inkscape (SVN R20551 2009-01-21 06:53:10 -0800 (Wed, 21 Jan 2009):
http://img258.imageshack.us/img258/8859/inkscapeout.png

At first glance, one should be able to quickly and immediately note the missing components.

The paths are there however, as we can see with a render that involves only the stroke:
http://img21.imageshack.us/img21/5584/inkscapeoutstrokeonly.png

The face can be downloaded from http://dafont.com for further testing:
http://www.dafont.com/capture-it.font

[prkos (prkos)]

I can't load the example images from the first report, but I haven't noticed anything weird with the way Arial Black is displayed in Inkscape.

The last reported font - Capture it seems to not apply color to some parts of some characters, so far I only saw it in E, I and 1. Converting it to path makes the color appear in those segments as expected.

This font is very heavy, lots of "nodes", it ate my memory quickly, don't test with too many letters if you're low on memory ;)

[Troy James Sobotka (troy-sobotka)]

Good old Imageshack was down. They should work now - or at least intermittently. ;)

I have attached them here for good measure.

[Troy James Sobotka (troy-sobotka)]

I'll add that when the face is converted to nodes, it renders correctly.

Looks like an Inkscape bug.

@prkos: Inkscape's performance is simply unfortunate. Try applying a stroke to a standard face - it too will grind to a slugging chug for some reason. It seems that if you have a stroke set and try to do typeface work, it grinds. If we can replicate it, I suspect there is another bug in there.

Needless to say, there is no reason that a typeface should slow a system down, so it is yet another knock on Inkscape's performance issues.

[ScislaC (scislac)]

Troy: Can you whip up a very quick example file or tell me what fonts have issues or steps to reproduce?

[su_v (suv-lp)]

Example from comment #16:
Not reproduced with Inkscape 0.48+devel r10325 (old renderer),
not reproduced with Inkscape 0.48+devel r10331 (new renderer)

[su_v (suv-lp)]

Still need to find the site where I downloaded v1.6 of the font 'Capture it' from …

Other sites have v1.4, e.g.
<http://www.dafont.com/capture-it.font>
<http://www.fontsquirrel.com/fonts/Capture-it>

[su_v (suv-lp)]

Seem to be identical font files

[su_v (suv-lp)]

Example from comment #14:
Not reproduced with Inkscape 0.48+devel r10325 (old renderer),
not reproduced with Inkscape 0.48+devel r10331 (new renderer)

[su_v (suv-lp)]

> Try applying a stroke to a standard face - it too will
> grind to a slugging chug for some reason.

Not reproduced with a standard font, but the font 'Capture it' with a stroke color applied is very sluggish when e.g. scaling with the select tool in Inkscape 0.48.1 and trunk with old renderer (< r10326).

Performance issue with stroked 'Capture it' font no longer reproduced with the latest builds from trunk (r10331) using the new renderer.

Proposing to close this report as 'Fix Committed' - based on comment #9 and the tests done with latest builds from trunk for the issues reported in comment #13 and #14.