#170 Font Panel/Text Draw Mode crashes 0.33 in Linux

[Marc J. Driftmeyer]

Great app by the way:

Known:

SodiPodi 0.33
Debian Linux 2.6 kernel running Sid distribution
Xfree86 4.3 pre1v4 debs via KDE 3.2 Beta.

Issue: Upon attempting to insert text or launch the
Font Panel the first instance of a ttf without an
accompanying .afm file crashes the application.

Workaround:

sudo and do the following:

Leverage ttf2afm to generate .afm file for every ttf file
Create by hand a font.map that lists the accompanying
FontName/afm name key/value pairs, within every
directory that has Type 1 fonts.

example:

AharoniBold aharonbd
Andalus andlso
AngsanaNew angsa
AngsanaNew-Bold angsab
AngsanaNew-BoldItalic angsaz
AngsanaNew-Italic angsai
AngsanaUPC angsau
AngsanaUPC-Bold angsaub
AngsanaUPC-BoldItalic angsauz
AngsanaUPC-Italic angsaui
AnimeAce animeace
AnimeAceBold animeace_b
AnimeAceItalic animeace_i

Run within every font directory: mkfontscale and
mkfontdir commands to update the directory status.

restart xfs via host>/etc/init.d/xfs restart within
user account.

Relaunch SodiPodi and then attempt to insert a Text
Object or load the Font Panel and all is well.

This is a workaround but definitely not a solution.

The application is looking better and better. It took
a bit to get around the handle on the drawing paradigm
but that is all part of the learning process, eh?

[Lauris Kaplinski]

Logged In: YES
user_id=19294

Is this really about ttf, not pfa files?
Is it possible to produce backtrace? It is weird, because
sodipodi shouldn't use neither afm file nor xft loader,
but load file directly, using freetype2. So xft map is
only needed, to find font filename.

[Marc J. Driftmeyer]

Logged In: YES
user_id=938549

So since sodipodi utilizes freetype2 you're then surmising
that it freetype2 dynamically generates font.map for all of
the directories installed, or upon reloading xft it
reindexes and auto-updates font.map within each specific
font directory?

It appears not to do so and from my research font.map is
manually created.

Once I converted all ttf files to have corresponding afm
files and then manually created the font.map within the font
directory which in this case was
/usr/share/fonts/truetype/Truetype Sodi's Font Panel
launched without bringing down the application.

Would it not be a much better approach to have Sodi fail
gracefully so that if it comes upon an exception like
missing font.map file that it invokes an alert panel giving
the exception listed with then the user being left to click
OK and fix the issue?

Also, how much work would it be for sodi if it detects a
lack of a font.map file to build one to use and thus
reference that map file and not be dependent upon xft to
have done so?

[Marc J. Driftmeyer]

Logged In: YES
user_id=938549

Lauris,

Freetype is the culprit and not Sodipodi.

Inside /etc/fonts/font.conf I had a path reference to
/usr/share/fonts which includes extra fonts.

From my determination the duplicate references to arial.ttf
is what causes Sodi to crash as freetype2 has already
registered a copy of arial.ttf via xfs.

removing the following pathway:

<!-- <dir>/usr/share/fonts/</dir> -->
<dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
<dir>/usr/X11R6/lib/X11/fonts/TrueType</dir>
<dir>/usr/X11R6/lib/X11/fonts/misc</dir>
<dir>/usr/X11R6/lib/X11/fonts/100dpi</dir>
<dir>/usr/X11R6/lib/X11/fonts/100dpi</dir>
<dir>/usr/X11R6/lib/X11/fonts/75dpi</dir>
<dir>/usr/X11R6/lib/X11/fonts/cyrillic</dir>
<dir>/usr/X11R6/lib/X11/fonts/Speedo</dir>

<dir>/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType</dir>
<dir>/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID</dir>
<dir>~/.fonts</dir>

restarting xfs fixed the issues.

This is definitely not a bug related to Sodi and if anything
duplicate font names should be ignored by freetype2 or at
the least inform via a log file that such is occuring and
applications will be affected.

Thanks for your patience.