Apache OpenOffice (AOO) Bugzilla – Issue 54603
using fontconfig for font fallback
Last modified: 2008-09-19 12:09:06 UTC
Attached is a patch to extend the use of fontconfig to determine the fallback font when the desired font is missing or has missing glyphs. Been using a version of this for some time. Hopefully a varient of this will make it's way into a future OOo release.
Created attachment 29557 [details] patch to implement
Created attachment 31710 [details] updated patch for 2.0.1
Thanks for the patch! Am I misunderstanding something or are you slaughtering the "glyph fallback" feature at least on WIN32 and also on platforms without fontconfig? AFAIK all UNX baselines don't require fontconfig yet...
might need a bit of re-work to support fully falling back to existing system for non-fontconfig available case :-)
*** Issue 63272 has been marked as a duplicate of this issue. ***
updat the patch for cjk compatibility 1. check cjk charactor one by one. 2. set the target font name as empty when the font not in the font list. 3. cjk font name convertion localized <-> english font name for 3, it need font name array correct. issue relate with 68839
Created attachment 38684 [details] for CJK improve
- while ( pWin && !pWin->IsSystemWindow() ) + while ( !pWin->IsSystemWindow() ) doesn't look quite right
jianhuajiao->cmc thanks I am a idiot for create a patch.
Created attachment 38690 [details] update for cmc's sugestion
This patch will cause all fonts name are English name, no localized name. I reversed some code to solve this problem. --- psprint/source/fontmanager/fontconfig.cxx 2006-11-03 17:19:11.000000000 +0800 +++ psprint/source/fontmanager/fontconfig.cxx 2006-11-02 18:19:13.000000000 +0800 @@ -417,8 +417,21 @@ bool PrintFontManager::initFontconfig() FontCfgWrapper& rWrapper = FontCfgWrapper::get(); if( ! rWrapper.isValid() ) return false; - - FcFontSet* pFSet = rWrapper.getFontSet(); + FcConfig* pConfig = rWrapper.getDefConfig(); + FcObjectSet* pOSet = rWrapper.FcObjectSetBuild( FC_FAMILY, + FC_STYLE, + FC_SLANT, + FC_WEIGHT, + FC_SPACING, + FC_FILE, + FC_OUTLINE, + FC_INDEX, + FC_EMBEDDED_BITMAP, + FC_ANTIALIAS, + (void *) NULL ); + FcPattern* pPattern = rWrapper.FcPatternCreate(); + FcFontSet* pFSet = rWrapper.FcFontList( pConfig, pPattern, pOSet ); +// FcFontSet* pFSet = rWrapper.getFontSet(); if( pFSet ) { Any suggestion?
well, that patch on it's own leaks some resources, the pFset and so on. FWIW, the reason I create a fontset to make the rest of this work out of, instead of the default fontconfig list is so as to restrict the fonts that fontconfig works with for font and glyph fallback to the set of fonts that are outline fonts, so that we don't consider non-outline fonts for fallback. How about this alternative patch instead to use the localized fonts, does it work for you. It also sketches out the area in which we could in the future pull the fontnames to use for the UI from the UILocale instead of the process locale so that font names follow that setting of OOo
Created attachment 40359 [details] additional patch to show localized font name
I'd apply the patches if only glyph fallback wasn't damaged for the case that fontconfig is not available (e.g. for the few people still running Win32). @PL: please review the psprint part of the patches.
The psprint part so far looks good to me (it's to complex to say definitely ok or not). however i stumbled over this minor part that makes no sense to me. --- psprint/source/fontmanager/fontcache.cxx 2006-08-21 14:19:19.000000000 +0800 +++ psprint/source/fontmanager/fontcache.cxx 2006-08-11 09:42:31.000000000 +0800 @@ -679,9 +679,9 @@ FontDirMap::const_iterator entry = dir->second.m_aEntries.find( rFile ); if( entry != dir->second.m_aEntries.end() ) { - bSuccess = true; for( FontCacheEntry::const_iterator font = entry->second.m_aEntry.begin(); font != entry->second.m_aEntry.end(); ++font ) { + bSuccess = true; PrintFontManager::PrintFont* pFont = clonePrintFont( *font ); rNewFonts.push_back( pFont ); }
*** Issue 46085 has been marked as a duplicate of this issue. ***
for CJK improvement: 1) The font attributes should not be applied to CJK characters when the selected font doesn't support CJK lang. 2) the Asian font listbox in character property dialog only list CJK fonts
Created attachment 41744 [details] for cjk improvement
I'd consider that last attachment a separate issue to the main task of using fontconfig for font and glyph replacement, So I suggest it would perhaps be best to split it off as a separate issue which depends on this one. Though personally I'd be a little dubious of a "special-handling for CJK" patch, listing just CJK fonts in the cjk drop down font lists seems fairly reasonable, but it does lead to the obvious question if the same sort of thing should then be done for CTL fonts and western to avoid listing fonts in e.g. the "western" dropdown if it don't support characters in an equivalent "western" range And not applying CJK attributes to CJK text because there isn't a proper CJK font in use for them seems dangerous (and again inconsistent as there isn't similar CTL/western changes), i.e. Assuming I'm not missing something, which is quite possible :-), but if I load a doc which has bold CJK text and the user has for some crazy reason already selected e.g. a non CJK font Timmons for that text then the text won't be bold due to the 2nd part of the patch ?
-->cmc, Thanks for your comments. create a new issue for this. #73003 1) I am not familiar with CTL langs. and I think almost CJK fonts support western langs, at least english. 2) The patch doesn't has the problem you mentioned. The patch just checks font name, not check other font attributes.
I hope to get it all into OOo3.
pflin --> cmc. I'd apply the patch. But I stumbled over this following minor part that may cause the font replacement table (tools --> options --> fonts) doesn't work if the replaced font is missing. ImplFontEntry* ImplFontCache::Get( ImplDevFontList* pFontList, @@ -2693,8 +2814,12 @@ ImplFontEntry* ImplFontCache::Get( ImplD if( !pEntry ) // no direct cache hit { - // find the best matching logical font family and update font selector accordingly - pFontFamily = pFontList->ImplFindByFont( aFontSelData, mbPrinter, pDevSpecific ); + pFontFamily = pFontList->ImplGetFontconfigSubstitute( aFontSelData, pDevSpecific ); + if (!pFontFamily) + { + // find the best matching logical font family and update font selector accordingly + pFontFamily = pFontList->ImplFindByFont( aFontSelData, mbPrinter, pDevSpecific ); + }
Created attachment 47680 [details] resynced current patch to OOG680
Since the patch was so invasive that it - removed code in the independent layer for generic font follback and glyph fallback => removed this functionality for all other platforms - introduced very platform specific code into the independent layer => broke the compile on all platforms except the ones with fontconfig >2.2.x - causes massive regressions for non-baseplane unicodes and EUDC users - introduced new behaviour that causes regressions for monospaced fonts (if their notdef glyph is ok) it had to be reworked. The result got into CWS gfbfcfg.
Testing hints for CWS gfbfcfg (fontconfig based font- and glyphfallback): - watch out for font- and glyph-fallback regressions on - platforms that should not be affected by the changes: Windows, Solaris8 - platforms that now behave according to FC's font- and glyph-fallback: Solaris10, Linux (if not too old) - check that application specific fonts which are not installed system-wide are still used properly - watch out for unicode surrogate regressions (see issue 40391 or issue 45983 for background info) Since the changes introduced by the changes are often very subtle I suggest to emphasize the differences by modifying FC's configuration to show more effect, e.g. by aliasing a font "XXXTest" to "NSimSun". See the extensive documentation for users at http://www.fontconfig.org/fontconfig- user.html Especially the "<alias>" element is important for testing this CWS. The regression for the layout of strings in monospaced fonts which fall back to the NotDef glyphs is expected and desired by the patch, so it should be considered a feature. The regression for the EUDC font (issue 33947) in case fontconfig is active is expected too, since normally FC is not configured to prefer EUDC fonts for glyph fallback. Respecting the results of the FC query should be considered a feature.
Adjusting target
what the status of verfication right now ?
In progress...
Adjusting target milestone to CWS milestone.
Verified in CWS gfbfcfg
Adjusting target to CWS.
*** Issue 66321 has been marked as a duplicate of this issue. ***
Was in the MWS for a while, closing the resolved and verified issue.