Apache OpenOffice (AOO) Bugzilla – Issue 45128
Silent Failing is Bad Practice (Font fallback and Glyph Fallback)
Last modified: 2013-02-07 22:39:25 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 http://www.evancarroll.com
Reassigned to US.
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.
Adjusting Component to 'gsl'. Unfortunately target milestone '3.0' isn't yet available in this tool - leaving unchanged.
set target to OOo Later
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 font-replacing-feature)
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.
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.
reset target to OOo later
*** Issue 82097 has been marked as a duplicate of this issue. ***
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.
reassigned to HDU
@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
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.)
This could be implemented in an OOo extension if issue 74754 would have been solved as I suggested then.
Just have seen, that issue 74754 is fixed (even I don't know which way). So couldn't be solved this problem too? btw. 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 M$-fonts.
*** Issue 23402 has been marked as a duplicate of this issue. ***
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!!!
*** Issue 102449 has been marked as a duplicate of this issue. ***
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.
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?)
*** Issue 107396 has been marked as a duplicate of this issue. ***
*** Issue 104608 has been marked as a duplicate of this issue. ***
*** Issue 93553 has been marked as a duplicate of this issue. ***
*** Issue 54944 has been marked as a duplicate of this issue. ***
> 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 <installedfont>". > 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.
To be able to vote on this issue, you can vote on issue 111228.
As suggested the issue will be moved to the component framework. This allows voting and seems more appropriate.