Issue 45128 - Silent Failing is Bad Practice (Font fallback and Glyph Fallback)
Summary: Silent Failing is Bad Practice (Font fallback and Glyph Fallback)
Alias: None
Product: General
Classification: Code
Component: www (show other issues)
Version: OOo 2.4.0
Hardware: All All
: P3 Trivial with 6 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 23402 54944 82097 93553 102449 104608 (view as issue list)
Depends on: 74754
Blocks: 72910
  Show dependency tree
Reported: 2005-03-15 23:40 UTC by evancarroll
Modified: 2013-02-07 22:39 UTC (History)
11 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description evancarroll 2005-03-15 23:40:14 UTC
Silently Failing is Bad Practice

Items should not silently fail. Fonts should not silently fall back. In a recent
example my ‘Bitstream Charter’ 10cpi fell back to something that looked like
Comic Sans, if the default action is to fall back on error, then it should be
obvious to the user, that the action is a default, and not deceptive to the user
as misnaming the font truly used.

I have two ideas on how to fix this problem:
a)	Simply make the font name, truly represent the font used. If font ‘foo’,
isn’t on the system and it falls back to font ‘bar’ then it should label the
font in the interface ‘bar’, and *not* ‘foo’.

b)	Or continue to mislabel the font ‘foo’ but make it evident to the user that
this is an automated best ditch effort to deliver what the user wants. This
could be easily accomplished by coloring the background of the Font Name, on the
Formatting Toolbar a light shade of red, and applying a simple bubble notice
when the user drags the cursor over the name. The logic behind this more
incognito notification is when the user realizes what is wrong the first places
he will look is the font bar and notice its red background. A scheme as such
could be used on all parts of the ‘Formatting’ bar.

-Evan Carroll
Comment 1 michael.ruess 2005-03-16 07:01:00 UTC
Reassigned to US.
Comment 2 ulf.stroehler 2005-03-16 10:54:23 UTC
Evan, thanks for the RFE.
Completely agreed. Intransparent font or glyph changes without any feedback to
the (advanced) user isn't a very smart behaviour of the app. 

Has been on our 'list of wishes' since some time. But probably not feasible for 2.0.

@mmp/ka: something we really should address for 3.0. I remember  an old memo
(approx 3years old) on this topic which I conducted together with MMP and refer
to from time to time.

Such a feature would help to solve a lot of confusion on the user side, help QA
and thus improves quality. Complete control on user set document fonts is a
requirement in certain business areas.

@ka: pls. integrate in OO.o 3.0 planning. Thx.
Comment 3 ulf.stroehler 2005-03-16 10:56:27 UTC
Adjusting Component to 'gsl'. Unfortunately target milestone '3.0' isn't yet
available in this tool - leaving unchanged.
Comment 4 ooo 2005-03-21 15:51:58 UTC
set target to OOo Later
Comment 5 meywer 2005-11-03 09:10:58 UTC
I like very much the second idea how to fix this (really strong) problem.
While moving the mouse-cursor over the (original, but at the moment not used) 
font-name, there should appear a little notice, which tells the user, which 
font is used instead of the missing original one (and maybe a tip about the 
Comment 6 ulf.stroehler 2005-11-03 10:34:07 UTC
We should really try to address this for 3.0. Adjusting target appropriately. 
@meywer: really nice idea. Although I think there should be 'real' UI to display
fallbacks and to manually adjust settings. But as an additional feature I like
the idea.
Comment 7 meywer 2006-05-22 14:31:56 UTC
see also issue 54944

For a document written with openoffice 2.0.2 on M$windoofXP using the font
"comic sans ms" openoffice 2.0.2 on my linux-pc used another font to display
(because comic sans ms isn's installed on the system).
But for bold characters there was choosen yet another font.

I really would like to know, which font OO (or X or what/who) choose to display
instead of "comic sans ms", but I suppose, nobody will be able to tell me?

In both cases - the automatically and the customised font replacement - it
should be clear for the user, which font is connected to the text/characters in
the document and which font is used to display at the moment.

I think, every replacement should be announced AND it should be asked for
customisation that behaviour.
Comment 8 ooo 2006-06-20 14:44:24 UTC
reset target to OOo later
Comment 9 lohmaier 2008-01-09 12:49:59 UTC
*** Issue 82097 has been marked as a duplicate of this issue. ***
Comment 10 nmailhot 2008-04-02 17:22:17 UTC
The issue is more complex than that:
1. it's not a Font A or Font B. It can be Font A with bits from font B is Font A
has not a particular glyph or set of glyphs.
2. The replacements bits can be taken from a set of fonts, not just one other font
3. You don't want OO.o to automagically change the font from A to B in a
document when it's modified on a system without font A. That would pose problems
when the document is moved back to a system with font A (and if font A and the
replacement font are present on this system you want to use the original font A
choice everywhere).
4. Asking the user each time a substitution occurs is going to get old fast for
many users (and is UI-intensive)
5. It's not silent failure. Failure would be not to display a document content
when the original font is not present, or is not complete enough to display all
the text entered by the user.

So :
1. A visual indication next to a Font Name that it's partially or totally
replaced on system would work.
2. Since the substitution can be partial, any correct user feedback requires   
A.either dumping the user to a charmap where you can find out what font is used
for each glyph when font A is replaced (à la gucharmap; gucharmap integration on
*nix systems would solve many user problems)
B. Or a special display mode where the parts of the document where substitution
occurs are highlighted and a mouseover each highlighted character shows the font
actually used in a tooltip.
Comment 11 ooo 2008-04-03 03:12:42 UTC
reassigned to HDU
Comment 12 2008-04-03 09:42:45 UTC
@requirements: please define a nice UI for this and then reassign it to the framework(?) team

In the GSL layers the functionality is already there:
- to find out which font substitution is applied for which font on a specific output device do
   - call OutputDevice::SetFont(requested_font)
   - call OutputDevice::GetFontMetric()
   => the font that is actually used is right there in the result, including its font properties
- to find out where glyph fallback is applied on a specific output device for a particular string do
   - call OutputDevice::HasGlyphs() to find out the parts of the string that the current font don't support
Comment 13 meywer 2008-09-02 18:19:38 UTC
I've got a problem connected to this now:
written an odt, printed, I got instead of some glyphs just empty "boxes".
Exported a pdf - shows all characters as desired (and as OO shows). 
Printed to a file - in the ps there are the boxes.

So it really should be *indicated* in OO, if there are missing glyphs on a system!!!

(And it should be *comprehensible*, which font is used instead of which one at
every place and for every single character.)

(And it should be *configurable*, how OO behaves.)
Comment 14 2008-09-03 07:44:34 UTC
This could be implemented in an OOo extension if issue 74754 would have been solved as I suggested 
Comment 15 meywer 2008-11-26 09:48:49 UTC
Just have seen, that issue 74754 is fixed (even I don't know which way).
So couldn't be solved this problem too?

I really don't understand, how it can happen, that in OO AND pdf there are shown
characters, which in ps and print are replaced by a little empty box.
E.g. character unicode hex2012 in font Arial on a linux-system with installed
Comment 16 Joost Andrae 2009-04-24 09:41:33 UTC
*** Issue 23402 has been marked as a duplicate of this issue. ***
Comment 17 meywer 2009-05-15 21:38:20 UTC
Once more I want to say, that its really not nice, to get awful nasty boxes
instead of letters printing a document, which is shown nice at the screen
without any warning!!!
Comment 18 2009-06-15 14:53:26 UTC
*** Issue 102449 has been marked as a duplicate of this issue. ***
Comment 19 jeremygharrison 2009-07-11 19:58:23 UTC
I would like to have voted for this issue. 

I find it most confusing (and would say wrong) that the font actually being used
is not that stated. 
Comment 20 meywer 2009-09-03 16:32:07 UTC
Have a look at the votes for 23402 (closed as a duplicate of this issue). (Why
on this issue there is no „vote for this issue“ link?)
Comment 21 dtardon 2009-12-03 08:18:58 UTC
*** Issue 107396 has been marked as a duplicate of this issue. ***
Comment 22 lohmaier 2010-03-25 22:44:40 UTC
*** Issue 104608 has been marked as a duplicate of this issue. ***
Comment 23 lohmaier 2010-04-01 18:29:28 UTC
*** Issue 93553 has been marked as a duplicate of this issue. ***
Comment 24 lohmaier 2010-04-28 11:30:48 UTC
*** Issue 54944 has been marked as a duplicate of this issue. ***
Comment 25 fallenguru 2010-04-28 13:40:13 UTC
> While not productive to add the comment here, I cannot resist:

We can just continue the discussion here, then. :-)

> No, [a warning (on opening a document)] will not get my support. The user
usually doesn't care /that/ much to be annoyed with a dialog she has to click away.

How about making it non-modal then? Something like the yellow bar that pops up
at the top of Firefox windows?

The reason I'd like this feature is simple: easier support.
a) I send someone a document. The recipient doesn't have all required fonts and
thinks that the document is ugly / broken and, what's worse, that it's my fault.
If there were a warning I could point to that and say "look, you're missing some
fonts, let me help you find and install them".
b) Two third parties, at least one of which I have to support, have problems
exchanging documents. They "don't look right". See above.  

Most of the time one can just export as PDF but some people would like something
they can easily edit.

> [an option to turn off all substitution and live with black boxes or boxes 
with the Unicode codepoint number in them] is a very, very unlikely szenario for
a user. I doubt anyone would like to have an unreadable document.

I'd prefer an unreadable document to one that looks entirely different depending
on the platform / installed fonts. Yes, I'm a control freak. 

> This is the wrong cure to the real problem. You probably think of this as a
way to spot the places where fallback did occur, but IMHO this is a very bad way
to deal with it.

Naturally, but it would be very quick to implement, wouldn't it, and thus could
serve as a stop gap measure.

> [a way to search for substituted glyphs / fonts is closer] to a workable solution.

> I'd think of a notification in the statusbar. "green" no substitution in
place, "orange" glyph fallback, "red" font-fallback (just states, not real
design proposal :-))
> click on it and get a list similar to "Font <notavailable> is replaced by font
> For the glyph fallback this is harder, as you cannot simply put the character
in the UI, since very likely the ui font will not contain that symbol either, so
either use unicode codepoints or a "highlight all font replacements" and 
"highlight all glyph fallbacks" function. IMHO the glyph fallback one is more 
important, as single alien characters within text stand out more, than whole 
paragraphs/document in the same (replacement) font.

Sounds good to me.
Comment 26 vinc17 2010-04-28 15:08:24 UTC
To be able to vote on this issue, you can vote on issue 111228.
Comment 27 stx123 2010-04-30 13:49:52 UTC
As suggested the issue will be moved to the component framework. This allows
voting and seems more appropriate.