Of course; this could be an issue with all rendering of Ariel Narrow - and a more fundamental font problem, but it's interesting; it looks like the width metrics get busted. Selecting and changing font seems to fix that.
Created attachment 82683 [details] font test document.
To make this more surreal; if you re-load the document then everything is fine :-) My suspicion would be that we are doing something too clever: using the metrics from one font with another font (or somesuch?). Either way - it looks beautiful as/when the metrics are right, I'll attach a more comprehensive test.
http://users.freedesktop.org/~michael/fonttest-many.docx has a few more funky fonts in it - ~all of which work perfectly (AFAICS) but only on the 2nd load.
Perhaps this is expected, but saving as DOCX having loaded, then re-loading that yields still broken fonts, the second reload of that though mends them ( at least for me ).
Fridrich reports success on first-load on a minimal Windows VM without the C* / Bauhaus etc. fonts installed: http://people.freedesktop.org/~fridrich/fonts.png I guess that makes it Linux specific ? Norbert reports a crash on load on Mac, but it seems to be an unrelated coretext issue; so lets hope this is a Linux-specific issue.
Created attachment 82691 [details] trace I attach Norbert's trace, possibly some font lifecycle issue ?
Created attachment 82810 [details] valgrind trace of loading the many font sample In case it's a memory issue - I attach a valgrind log which may be helpful. Certainly looks like some font related stuff there.
Help much appreciated with this one; here is what I managed to dig out by using valgrind and SAL_DEBUG in conjunction. It -seems- that the invalid data is a stale PhysicalFontFace pointer - which seem to get inserted into the mpFontList here: @@ -214,10 +221,13 @@ void OutputDevice::ImplUpdateFontData( bool bNewFontLists ) { if( mpOutDevData ) mpOutDevData->maDevFontSubst.Clear(); !! mpGraphics->GetDevFontList( mpFontList ); !! mpGraphics->GetDevFontSubstList( this ); Those entries appear to be valid at insertion time, but then are later freed at the end of ImplUpdateAllFontData :-) Which is somewhat annoying - and causes the underlying problem (AFAICS) - both the Mac crash and the intermittent Linux mis-substitution.
Created attachment 82827 [details] re-order the cache cleanup - prototype patch Suggested patch; not hyper-happy with what's going on here. There seems to be some very significant cost to clearing these caches - why are we doing anything per Window around fonts ? :-) Anyhow - this at looks plausible I hope and only touches the ImplUpdateAllFontData method.
Prototype patch is also valgrind clean (for me) for a load / exit.
with michael patch, mac does not crash anymoreI'm not sure if the displayed output is what was intented. I see a plain document with a 'Embedded fonts test' title then Callibi Baushaus Cambria Ariel Narrow and Brodway in different fonts... I'm not familiar what the font must look like, but broadway at least looks like what I immagine it would (and Callibi is prolly really Callibri :-) )
This is good for me for master, but I'm somewhat uneasy about backporting this so short before release without more testing. I don't think we can do better though.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dda3686acde4911f70f07724247e822f8b3dbd90 fdo#67086 - clear device font list before re-fetching it. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea82c62a3968181507581724000045d33c216e0d&h=libreoffice-4-1 fdo#67086 - clear device font list before re-fetching it. It will be available in LibreOffice 4.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Closing - unhappily :-) more review of this patch much appreciated, and/or a better two-stage cleanup of all those low-level graphics / glyph caches.