Apache OpenOffice (AOO) Bugzilla – Issue 54944
Provide way to mark forced font replacement
Last modified: 2010-04-28 11:32:12 UTC
When OO encounters font which lack of some glyphs, it automatically replaces font with default one. Such behavior is much better than MSO, which draws empty rectangles instead of letters. However, user should be aware of such auto-replacement. So, prodive a way to visually mark (something like spellcheck color underlining) text areas where font auto-replacement is applied.
I strongly support this RFE (Request for Enhancement) and would like to use it as parent task for all there is to come (analysis, requirements, concepts, specifications, etc.) @MMP: pls. see my old memos in this matter. BACKGROUND: =========== In general OO.o provides two types of font fallbacks: 1. FontFallback: an application requests a specific font which at the moment of request isn't available to OO.o. Then OO.o performs a context sensitive fallback to a different font. This fallback process continues until a suitable candidate is found in the fallback list (VCL.xcu) which is then passed to the app. 2. GlyphFallback: an application requests a specific glyph which isn't provided by the chosen font. OO.o tries to provide the glyph from a different font which is determined by context sensitive internal fallback lists. Conclusion: =========== From my understanding this RFE and the intended feature should cover both Font- and GlyphFallback as the representation to the user is the same: a font has changed completely transparent to the user with almost no possability to control the behaviour. Wish-list: ========== From my understanding the new feature should provide the following: * emphasize the position (in a document) where a font change took place * provide UI to display what change has been performed * briefly display why the change was necesarry * provide UI to control the behaviour * provide UI to permanently customize Font- and GlyphFallback * offer option to either change font settings only for current document display or to save the information permanently with the document * specify appropriate handling also of print-outs and PDF-exports as they suffer from the same problem of Font- and GlyphFallbacks Any further suggestions?
forwarding important RFE
really depands on 54780? see also issue 45128
issue 54780 is unrelated to this RFE.
I'd just like to add a vote for this enhancement and a request that whatever notification the program gives is immediately apparent when scanning the document. Personally, I'd prefer that glyph fallback never occur--that glyphs unavailable in the specified font appear as big black boxes. This behavior occurs on some platforms in some version of openoffice, but on other platforms, glyphs fallback occurs silently.
The latter (black boxes) would be easy to achieve, however most people want things to work "magically" however unrealistic that wish is. Perhaps we should have an on/off switch for glyph fallback in tools->options->general->view
Retargeting this issue. Adding CC.
Fixed dependency to issue 45128, thanks meywer!
While automatic font replacement is a useful feature, it should be apparent what is going on - I find it confusing that it isn't. Possibly the Tools > Options > OpenOffice.org > Fonts should be enhanced to display this information?
First of all, this is really similar to issue 45128, maybe merge or mark as duplicate? In the long run full control over font / glyph fallback and substitution would be desirable of course but as that's a big (UI) change maybe some of the following could be implemented: - a warning (on opening a document) that substitution is taking place. - an option to turn off all substitution and live with black boxes or boxes with the Unicode codepoint number in them. Make it an environment variable if that's easier - an indication in the font dropdown box that substitution is taking place (at the cursor position / in the selection). A symbol, different color, anything. - a way to search for substituted glyphs / fonts
yes, it's a duplicate, doesn't make sense to have two issues open for the same thing. While not productive to add the comment here, I cannot resist: > - a warning (on opening a document) that substitution is taking place. No, that will not get my support. The user usually doesn't care /that/ much to be annoyed with a dialog she has to click away. > - an option to turn off all substitution and live with black boxes or boxes with the Unicode codepoint number in them. Make it an environment variable if that's easier That again is a very, very unlikely szenario for a user. I doubt anyone would like to have an unreadable document. 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. > - an indication in the font dropdown box that substitution is taking place (at the cursor position / in the selection). A symbol, different color, anything. The dropdown probably is the wrong place, as the user (when creating a document) will not see non-installed fonts there, so cannot chose a non-installed font other than by typing in the fonts name. In that case, the user already knows the font is not available, and is actually explicitly requesting fallback in that case. > - a way to search for substituted glyphs / fonts Yes, that's closed 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. Anyway, flagging as duplicate. *** This issue has been marked as a duplicate of 45128 ***
closing duplicate.