Some research on bugzilla would have save you a lot of typework. You are mixing
a two problems here, in particular bug #112401 and bug #141102. The latter
point, which gets you to the wrong conclusion that GIMP would crash, has been
fixed a good while ago. Why the GIMP for Windows binary intaller still ships
with the old version of GLib that has this problem, is beyond my knowledge.

*** This bug has been marked as a duplicate of 141102 ***

I don't think this is a dupe of bug #141102. It probably *is* a dupe of bug
#112401, though. The "requestors" he mentions aren't console windows, they are
GUI message boxes. The first one is generated by glib for a fatal error, and the
second one then by the C library when glib calls abort().

As to why entering an incorrect extension causes the infamous "MS Sans Serif 8"
problem to occur I can't say. I would have thought it should happen much
earlier? Anyway, I think the GIMP on Windows FAQ has advice on this.

Xanthian, there is no font called "fixed" in Windows... You are confusing with X11.

Why would there be a GUI message box generated by glib for a critical warning?

Actually I never realized that the infamous "MS Sans Serif 8" problem is
actually causing Pango to abort. I thought we would have been past that point a
few years ago already. I've always assumed that it's just a remaining warning
and that the problem is GLib opening a console window for it that the user then
closes, thereby causing GIMP to quit. Oh well, poor Win32 users ...

Reply to comment #1:

Do you find frequent good results in insulting the
intelligence of those who report bugs? I _did_
search for reasonable keywords that would have
matched this situation, if badly designed bugzilla
bothered to search past the titles of other bugs (a
failing strategy), and instead searched the bug
comment bodies,

    "save as" crash "sans serif"

and received the "zarro boogs" response. This bug is
not related to either of the ones you cite, except
that it happens to evoke the same symptom as bug
112401, but from a completely different cause and
failure in the GIMP or GTK+ software. The reasonable
person would conclude that some fragile part of GIMP
frequently crashes into that symptom in response to
multiple separate causes which are themselves
separate bugs, as is the case here.

This bug is not only not a duplicate of 141102, it
bears no relationship at all to that bug. Please
repair your meddling and let someone competent deal
with this bug.

Response to comment #2:

This bug is also not a duplicate of bug 112401. They
happen to share a symptom, but that is all they
share, they don't share a cause, and are surely
independent bugs.

Sorry to have used "requestors"; after writing parts
of three international computer graphics standards,
I have this naive impression that folks doing
computer graphics software will be familiar with the
terms of art in common use in the field. More the
fool me.

Notice that what this bug report has provided is a
repeatable way to invoke one of (probably many)
failures that have as one symptom the "sans serif"
fallback. Rather than ignoring this, or trying to
sweep it under the rug of some unrelated bugs, a
wise software maintainer would sieze on this as a
golden opportunity to single step through the code
to find not just the immediate bug, but also the
reason that this and many other bugs share the "sans
serif fallback" symptom.

There is very likely not a font called "fixed"
anywhere; it is the generic name usable in standard
font nomenclatures on pretty much every OS by now to
evoke _whatever_ default fixed pitch font a system
contains, used specifically so that a choice of say
"Courier New" doesn't fail from some other fixed
pitch font being the default instead. It has roughly
the equivalent role for fixed pitch default fonts
that "sans serif" has in picking out the default
proportional pitch font.

Response to comment #3:

The alternative, to crash without an explanation,
was probably considered an inferior choice.

Response to comment #4:

Win32 users still being roughly 95% of the potential
user base for GIMP, Win32 should probably be the
_first_ focus of GIMP maintenance attention, rather
than being treated as some poor relative to the
Unix-workalikes by bigots who can only deal with
ideal OSen. 

Your comment shows your crippling prejudices, and
not much else.

xanthian, infamous for his inability to deal
gracefully with fools (and a former Unix sysadmin
and Unix internals developer).

xanthian, given that you sometimes seem to get things partly wrong (at least
that's my impression from your posts to gimpwin-users, and your initial comments
here), you should try to be less arrogant. Oh, and before you add me to the
"bigots who can only deal with ideal OSen" (something you should apologize for,
btw) because of this comment, consider having a look at the ChangeLog of GIMP...

My knowledge is that this type of error (the message box) is caused by glib, and
suppressed in current versions. Is this correct, which release was the first to
ship with the fix, and which version does the installer ship with?

Let's all chill a little.  Obviously, nobody is happy that GIMP is crashing, and
we would all like to fix this.  The question is how.  If GIMP were actually
requesting the font "MS Sans Serif 8" by name somewhere, then it would probably
be trivial, but that doesn't happen.  It seems, based on the discussion here,
that the request is occurring somewhere within Pango or Glib, not specifically
within the GIMP code.  It would be nice to avoid triggering that request if
possible, or to tell people which version of Pango or Glib solves the problem,
but I don't think any of us knows the answers yet.  Suggestions that move us
forward would be great.  Since I don't think any of us has an actual *patch* to
offer at this point, we might as well try to avoid criticizing each other.

This bug is mostly a duplicate of bug #112401, as Tor correctly mentioned in
comment #2.  However, there is a difference here: the glib error message is a
fatal one, not a warning as described in bug #112401.  So I think that this bug
report deserves to be re-opened (if only to mark later it as a duplicate of bug
#112401 instead of bug #141102).

Regarding comment #7: the GIMP is not requesting "MS Sans Serif 8" but it
happens to be the default font configured for menus and other stuff on some
systems (notably Windows NT).  When a generic font is requested (through gtk or
gtk-wimp) and Windows returns a bitmap font, Pango for Windows cannot use it
and an error is returned.  The problem could occur with any other font that is
not a TrueType font.  So contrary to what the reporter wrote in comment #5, this
problem occurs _because_ a generic ("fixed") font is requested.  It would be
good to know what part of the code is requesting such a generic font, though.

The FAQ for the Windows port of the GIMP suggests to go to Control Panel->
Display properties->Appearance and ensure that all fonts are TrueType.  If the
problem is indeed caused by that, it would help greatly if the reporter could:
- check what default fonts are used currently on his system
- try to switch all of them to TrueType fonts and see if it solves the problem
- if yes, try to see which one was causing the problem (by switching them one
  by one)
- report his findings here, including the exact version of gtk used

If the gtk-wimp theme engine is installed, it makes GTK+ use the current GUI
settings from MS Windows - colors, fonts, some behaviour etc...

AFAIK the cause for this error - or rather this annoyance, since actuall it
works as designed, the windows opens on purpose - is identified and fixed at
glib level. See my questions at the end of comment #6. I suggest that this gets
reassigned to the Installer component.

Created attachment 35903 [details]
Control Panel=>Display=>Properties=>Appearance

Per request, reporter's "Appearance" properties sheet from the
Control Panel "Display" properties widget.

Created attachment 35908 [details]
list of c:/windows/fonts

Unfortunately, MS-Win98se doesn't allow the user to capture as
text the information it displays in the c:/windows/fonts window,
but I have attached just the file names from a DIRectory listing
of that directory, in case it is of use in determining what fonts
are in use in the reporting system.

The fonts in the fonts folder are all fonts installed on the system. The default
fonts currently used are displayed in the fonts property of the appearance
dialog, if the currently selected item - either by using the dropdown or by
clicking on it in the preview - has font information associated with itself. In
your case, this should be MS Sans Serif.

Common choices for alternative GUI fonts seem to be Tahoma or Verdana. 

About comment #10 and attachment 35903 [details]: unfortunately, this attachment by itself
is not very useful because the image only shows one item (Desktop) and that one
does not use any font.  What you should do is to go through the list of all items
that can be configured (by selecting them in the drop-down list or clicking on the
corresponding element in the preview) and writing down the fonts used.  If you see
a font that is not TrueType, try to change it, select OK to close the dialog, then
check if you can still reproduce the problem.  It would be nice to write down the
list of fonts as they were configured before you changed them (for each item) and
what you had to change in order to make it work.  Please also include the
details about the versions of gtk and gtk-wimp installed on your system, as
requested above.

Re: comment #6: my response to Michael's egregious
insult is sent offline.
The GTK+ version in use is noted below.

Re: comment #7: I agree that criticism of the
various parties is inappropriate; notice though
that it began with Sven, not me.

Re: comment #8: if the problem is that "Pango",
whatever that is, crashes because the user happens
to have some non-Truetype fonts installed, then the
_correct_ developer reponse is either 1) fix Pango,
or 2) don't use Pango.

MS Sans Serif 8 is indeed on my (MS-Win98SE) system,
and is marked as an "Adobe" font, not a "TrueType"
font. Obviously, if a library is being used (Pango)
that crashes on the default font setting for an
MS-Windows error requestor widget, selection of that
library for use in a product whose majority user
community is probably the MS-Windows one (by a
simple count of installed base) is a developer
blunder of the highest order.

    [Please notice in this that I am not an MS
    apologist; my hatred of that misbegotten OS is
    well documented online for over 20 years. The
    reality of its > 93% desktop system market share
    remains despite my attitude toward it, however,
    and needs to be a foreground concern in the
    minds of GIMP developers (or any other open
    source software developers) whose main market it
    is (and will remain for years if not decades to
    come, sadly).]

There is no way that any one application should have
the arrogance-by-design to think that it is the sole
arbiter of which fonts the user happens to have
selected for decorating standard requestor widgets,
much less which one the OS vendor has selected in
ways the user may not have the knowledge to modify
or permissions to modify.

Truetype is a _commercial_ font with lots of
competitors; neither GIMP nor GTK+ get to determine
the winner in that marketplace by fiat.

Also, some of us have vision problems whose needs
far override software developer's needs to use a
canned-but-broken library, and Pango, by attempting
to limit user choice to _its_ needs, is simply a
conflict-in-waiting for other software that might
equally well need some simple raster font instead.

"Truetype" is not a requirement for running
MS-Windows

    [though it seems to be the OS vendor's majority
    delivered font, if what I see on this box came
    installed with it; more likely it is a third
    party add-on (unknown to me, since I don't own
    this computer, I just use it],

nor should developers, therefore, assume it is
present or selected.

I've attached a screen snapshot of the "Appearance"
panel from the Control Panel Display Properties
widget of MS-Win98SE, but I cannot comply with the
other information requests of comment #7, and I
doubt what I've attached will help much, but I
included it in case it tells more to others than it
does to me. The "Font" text entry widget is hazed
out and empty, thus the "font" setting is the one
with which MS-Win98SE is delivered and has not been
modified (and is thus something with which GIMP on
MS-Windows should cope without crashing, as a first
order of business), nor do I know how to determine
from what I see in the attached image what fonts are
those default fonts or whether they are Truetype
fonts.

However, I've attached a directory listing (just the
file names) of the files in c:/windows/fonts, in
case that helps some more knowledgable person
determine what fonts are in use.  Based on the icons
I see, all but a handful of the 450 fonts installed
on this system are Truetype fonts, for what it's
worth.

The GIMP/GTK+ I have installed is the standardly
distributed one up on SourceForge for GIMP 2.2.1 for
MS-Windows, I know nothing of its bona fides past
that.  The installer for GTK+ is named
GTK+-2.4.14-setup.zip, if that helps.

There is still some confusion apparent in comment #8
about "fixed". If MS Sans Serif 8 is being invoked,
it is _not_ being invoked by use of "fixed" as the
generic name, but by use of "sans serif" (or perhaps
"proportional") as the generic name. Generic name
"fixed" is not the name of any proportionally spaced
font (such as MS Sans Serif 8), but of some fixed
pitch font, typically set to some specific font name
such as "System", "Terminal", "Courier" or "Courier
New", but I've seen others; I think the Lucida
family includes a popular fixed pitch (==
monospaced) font, for example.

Probably, to help get matters pointed in the correct
direction, rather than marking this bug a duplicate
of bug 112401, a new bug should be filed by a
developer, one which correctly identifies the
problem: any GTK+/GIMP problem that evokes a
standard error requestor widget on a system where
the default font for that widget turns out not to be
a TrueType font, will crash due to problems in
Pango. That, not the many ways to evoke a standard
error requestor widget, is the actual bug, and
having the bug description be as it currently is in
bug 112401 is merely grossly confusing both to
developers and to users trying to report bugs.

Bugs such as this one whose resolution at run time
are interrupted by the Pango failure should then be
marked not as duplicates to that newly filed bug,
but merely as "depend upon" situations that evoke
that bug. Until that bug is fixed, there is no way
to know whether GIMP or GTK+ or whatever sinner is
involved is correctly handling, for example,
misspelled image file name tags, like my ".pqt" for
".pat", so there is no way to know whether this bug
will need additional work beyond the repairs to or
replacement of "Pango".

Re: comments #8 & #9:

I'm not sure what the "gtk-wimp theme" is, but it
isn't something I've knowingly installed. If it
comes with the standard SourceForge GIMP2 installer
set for GTK+, GIMP, and GIMP help, it is installed
(since I took all the installer defaults), otherwise
not.

HTH

xanthian.

Re: comments #12 and #13:

I have no idea what either of you is asking me to
do; what I attached is as far as I know how to use
that Appearances widget.

I'm not only not an MS-Windows "power user", I use
this system only under protest and due to being
shackled to it for the last 17 months by a
convicted, incarcerated felon (both figuratively and
literally).

Modifying the setup is therefore going to take step
by step instructions at the "click here, then type
this" level, not "handwaving as if the user were a
mind reader".

xanthian.

By the way, bugzilla's inability to fold my comment
#14 in after yours when I started typing mine before
yours arrived and ended typing it after yours
arrived is a _hideous_ flaw.

Except that I happen to do almost all my lengthy
typing into vim() [for the superior formatting
capabilities] rather than HTML text imput forms
windows, and thus by the good fortune of not yet
having closed my vim() session had a backup copy to
reuse, the choices bugzilla offered me were either
to lose that entire typed input, and start over, or
to erase all your "subsequent to the start of my
composition" entries so that mine could be seen.

Please contact the bugzilla maintainers and have
them fix this.

There is nothing the least bit "challenging" about
appending additional comments in "arrival order"
however their open, logged-in Additional Comment
text entry form windows overlap among commenters on
the same bug in "composition order".

Bugzilla reporting windows shouldn't be "stateful"
to the extent that typing among users can't overlap.

Re: original report:

Oh, by the way, the "recursed" in that error
requestor widget isn't something casual, it is a
huge CLUE. The precise failure is that
GIMP/GTK+/some-subordinate-library asked for an
error requestor, evoking use of a font for that
requestor by generic name "Sans Serif", which
evoked the default sans serif font as set at the
software factory, MS Sans Serif 8, which Pango
failed to handle well. Pango (apparently) then
requesting, since the "requested" font failed to
"arrive", that the font system take its fallback,
[never noticing that it was _already_ taking its
fallback] which it did, to "Sans Serif", which
evoked the pre-set default Sans Serif font, "MS Sans
Serif 8" ... you see where this is going, right?

The fault is entirely Pango's. If the font-fetch
recursed, Pango should catch that, and use a font,
if necessary one font _built into_ Pango, that it
could guarantee would be accessible, since error
reporting in any competently designed software
package must be _guaranteed_ to work, always, even,
as they used to say of DEC's VMS OS, "if the disk
drives are on fire".

This is no different in concept from the standard
practice in large software systems of always
pre-reserving some memory for use in reporting an
"out of memory" error, so that such an error doesn't
"recurse".

FYI

xanthian.

Reply to comment #15:

Okay, I finally figured out that the "dropdown list"
of comment #13 is those images in the "Appearances"
window (which give no clue to the naive user that
they are active entities).

Now I can change to a different font, (probably
Lucida Sans Typewriter, almost certainly the "fixed"
font of the Lucida family to which I previously
referred), but only by having opened simultaneously
the c:/windows/fonts window would I be made aware
that the font I'm about to select is a "Truetype"
font, that information doesn't occur in the
"Appearances" widget that I can see.

That will fix the problem _for me_, but will not fix
the bug that GIMP/GTK+ used Pango, which makes
itself _incompatible_ with the manufacturer's
default font choice setup for error reporting of >
93% of the installed base of "customers" for GIMP.
That problem still needs addressing, as _every_
WinGIMP user will otherwise eventually encounter
this failure, to the annoyance of users and
developers alike.

I suspect that a stupid and ineffective fix is
nothing more complicated than that GIMP/GTK+/Pango
select some Truetype font at execution startup and
assign it as the one for error widgets early in the
invocation process so that errors later during
invocation don't experience this recursed error.

The fix is "stupid and ineffective" because there
isn't any useful way to guarantee in advance that
any particular Truetype font is installed on the
user's system, except to make it part of the GIMP
installation.

A "better" fix would be to embed some
cheesy-but-small-footprint raster
font-of-last-resort directly into Pango, as
mentioned earlier, because that fix is guaranteed to
be effective.

I'll switch these fonts over and see if I can
re-evoke the misspelled image file name tag problem
and report back whether GIMP now handles that well.

FYI

xanthian.

Re: comment #17:

I changed the following font selection items of
Control Panel=>Display=>Properties=>Appearance
from Microsoft Sans Serif to Lucida Sans
Typewriter:

"Inactive Window Title Bar"
"Active WIndow Title Bar"
"Menu"
"Message Box"

Visually, at 8 points type size, it is hard to
notice the difference in the Appearances
widget, easier in general use within GIMP.

Now, when I try to save a file with tagname ".pqt",
by fat-fingering, I get an error requestor widget
that is titled "GIMP Message" and contains:

  GIMP Message

  Saving
  'C:\Downloads\xanthian\GIMP2\AdditionalToolsDataSets
  \patterns\mattoni101.pqt' failed:

  Unknown file type

a much nicer result.

So, when a bug is written to replace bug #112401
that correctly describes the problem, this bug
can be safely marked as a duplicate of such a bug,
it has no obvious other failures involved.

This, of course, has now solved a problem for _one_
user that needs instead to be resolved at the code
level for _all_ users. Again, GIMP shouldn't be
driving my choice of fonts for MS-Windows default
font settings, and Pango shouldn't be crashing GIMP
because Pango can't cope with Adobe fonts. 

    [It's worth noticing in closing that selection
    of Lucida San Typewriter, a fixed pitch font
    that results in text strings occupying more
    horizontal space, had the amusing consequence
    that the width of the GIMP startup window on
    opening was no longer sufficient. The docked
    "tool options" sub-window widget (which happened
    to be the one for the Paintbrush at startup) was
    only about 75% of the needed width to display it
    all and so had a horizontal slider bar on
    opening, not a bug, just an infelicity that GIMP
    doesn't check the space needed for the currently
    docked widgets before selecting its opening
    window dimensions, but then, perhaps in general
    that wouldn't work anyway; the patterns and
    brushes widgets can get huge, and mine are.]

HTH

xanthian.

Guys, this isn't a GIMP problem at all. It is a well-known and well-documented
fact that Pango relies on fonts being available for the Sans, Serif and
Monospace aliases. Available means available for all font sizes. The Pango/GTK+
installation needs to make sure that these aliases can be resolved and if that's
not the case, well, then things will blow up. It is up to the people who want to
use GTK+ on the Win32 platform to figure out how to fulfill this prerequisite.
If it means fixing bug #112401, then this bug report should be declared a
duplicate of that bug. If it means tweaking the installer, then it should be
reassigned to the Installer component. It is however certainly not anything the
GIMP developers should have to worry about.

Re: comment #19:

Where _do_ you people come up with this bizarre
world view?

Are you kept in a barrel labeled "Linux propoganda
only" and fed on scraps of overly terse and obscure
command names?

My system _has_ a Sans font, size 8, precisely as
requested, already installed and perfectly usable,
since until I reset it, it was the titlebar, menu,
and message requester widget body text font in use,
in particular, Microsoft Sans Serif 8, functioning
perfectly adequately for other applications than
GIMP, and Pango _still_ failed.

The problem is not that "win32 users are all fools
and have to mangle their system default setups to
conform to Pango".

The problem is that Pango is an inappropriate choice
for a tool, GIMP, which must support systems using a
mix of font technologies, because Pango apparently
chokes and dies if what it is fed isn't a Truetype
font.

Since the font technology marketplace is highly
competitive, no tool that depends on which
_particular_ font technology is in place is an
appropriate choice for a product which must run on a
wide variety of platforms, certainly the case for
GIMP.

If Pango cannot be fixed, Pango should be replaced.
GIMP developers cannot dodge the reponsibility for
the failure by whining "but its in this low level
library over whose source code we have no control",
because GIMP developers have _absolute_ control over
the decision to use or not use that low level
library. When it breaks GIMP on the dominent desktop
platform in the marketplace, and the dominent
platform used by GIMP's potential customer base,
that decision ought to be a pretty straightforward
one. Try to make it so.

Now, could we _possibly_ have a little less
MS-hater zealot's propaganda out of you, and a lot
more software fixes instead? The problem is fixed
_only_ when Pango is no longer attempting to drive
the user choice of default font technology for the
entire operating system's GUI to cater to a single
application, a pretty incredibly arrogant thing for
any single application to consider doing, when you
think about it. If one application is allowed to do
that, so can others, and nothing whatsoever forces
them to agree. Therefore, none of them can be given
that option, and in particular GIMP/Pango cannot.

HTH

xanthian.

Just shut up. You've abused this bug tracker far enough.

You have no right to make demands of FREE software, made on VOLUNTEER time.
We're not going to waste anymore time reading your ill researched comments and
ignorant conjectures.

I'm closing this bug as INVALID. If you feel this issue is SO important, you'll
address it on your own, or you'll pony up for a, say, $2000/yr support contract.

Kent, we never said that it can't be fixed nor that we wouldn't be interested in
seeing it fixed. But since this is only reproducable on Win32, it's up to the
users and developers on Win32 to isolate the problem and to fix it. All we can
say is that the problem is not in GIMP. It's probably a bug in the Win32 backend
of the Pango library and then it needs to be fixed there. Perhaps it could also
be worked around on a different level. The fact that the problem does not show
up on every Win32 installation seems to indicate that it somehow depends on the
local setup.

Insulting volunteers or telling them how to set their priorities is however not
how things work here. If you can't contribute any useful information that would
help to get this problem fixed, then you should just shut up.

> Why would there be a GUI message box generated by glib for a critical warning?

Maybe that is silly, but GLib has been doing this for ages. g_logv(), when
noticing that the message level is G_LOG_FATAL, put up a MessageBox() with the
message, and only after that aborts (like on Unix).

The rationale is that fatal messages should be seen by the user. If GLib didn't
do this, G_LOG_FATAL errors would go completely unnoticed, the application would
just vanish. (Or the abort() would cause some generic messsage box with an
"abnormal program termination" or somesuch less useful message.) Surely that is
not good either?

Note that this is independent of the console windows that it used to open when
needed, for *any* output through g_print() or friends to stdout or stderr. That
doesn't happen any longer.

> Pango relies on fonts being available for the Sans, [...] aliases.

Yes, and those are  appropriately aliased also on Winows in pango.aliases.

Don't confure "MS Sans Serif" with the Pango alias "Sans". pango.aliases doesn't
even list "MS Sans Serif" in its list of fonts for "Sans". 

Tor, it is up to the application to care about presenting message boxes to the
user. It's not any different on a typical UNIX system. People start GIMP (and
other apps) from the menus or a panel and messages just go nowhere (well, they
go to ~/.xsession-errors or similar).

Adding a GLog handler to GIMP is something that we should consider for GIMP 2.4.
It is definitely not something that GLib or GTK+ should worry about.

For a proper diagnosis of this bug (aborting with a "recursed" error messages
stating that a font couldn't be loaded), se bug #112401

Re: comment #24, hmm. If the MessageBox() call in g_logv() is removed, then this
problem here would have been even harder to diagnose, as the recursive call to
g_logv() means the logging is handled by _g_log_fallback_handler(), which writes
to stderr which doesn't go anywhere in GIMP on Windows. So then GIMP would just
abort() without no indication what the real problem is. On Windows, abort()
causes  a dialog box with the title "Microsoft Visual C++ Runtime Library", and
a generic "Runtime error, Program: <path>, abnormal program termination" text.

This should be closed as duplicate of bug #112401.

*** Bug 167527 has been marked as a duplicate of this bug. ***