I first noticed this on master with a test failure of: /discs/fast/core/test/source/xmltesttools.cxx:95:testTdf97542_2::TestBody equality assertion failed - Expected: 1 - Actual : 0 - In <>, XPath '/primitive2D/transform/objectinfo/svgradialgradient' number of nodes is incorrect so I tried loading the test file and it's misrendering it. That is; a) Start LO b) Create a writer doc c) Insert image from file d) Insert the ./svgio/qa/cppunit/data/tdf97542_1.svg or ./svgio/qa/cppunit/data/tdf97542_2.svg file e) Expected: word 'Text' on shaded background Actual: 4 boxes in the correct foreground colour instead of the 'text' Currently bisecting: 359190cb6ae2c76356de7f9368abc849c7696415 good e64d85c9eb18642ed3a0526f3dd8db9a4b88e629 bad Fedora 39 x86-64 host.
Created attachment 190444 [details] Screen crop of bad import
trying 359190cb6ae2c76356de7f9368abc849c7696415 - good 5127b1961b762643d47a26704556fd9b8664c6fc - bad b9ffee3074d8eb0e95b3d8f78cb7aac10b41c279 - bad af83536685cf50a564d9c8290bf6ea5982de73b7 - bad 211c4df7656bc81617e98ec89466c12f998a6130 bad dc748d7dbd114fbf663752258dbaf003af2926c3 - bad e64d85c9eb18642ed3a0526f3dd8db9a4b88e629 - bad Got further to go; but I'm suspicious I've only had that one good version; so I'm a bit worried where the bisect will lead.
I can't reproduce it in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 809409ca845ff1269d3d8f516678048404d8fea8 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
Created attachment 190447 [details] sample file
it looks like https://lists.freedesktop.org/archives/libreoffice/2023-September/091027.html
Ignore my previous bisect. I'm needing to add a 'make clean' to get a real answer. So, 359190cb6ae2c76356de7f9368abc849c7696415 - clean - good! aa396ee162ee0eb223c90ab4f9bd55014cf94775 - bad; retry clean - good! e64d85c9eb18642ed3a0526f3dd8db9a4b88e629 - bad; retry clean..still bad! Now, that aa396 is 5th Sep, where as the e64 is 8th Oct; and Stephan's report Xisco just linked to is 29th Sep - so right ballpark.
This looks like some form of font search screwup; My bisect comes down to (with a make clean): 19e9fe7c8c89399753ac1730e1c76378b18418bc - clean; good! 9b7c732215f2dc34d1f0cfc08ea912a3925b13b0 - clean; good! 9998c242c6c2ece5f240db2f6ffdf04e7ca7cbb4 - clean; good! 00db8423d18d75f982b337744ec39c4b7269a433 - clean; good! 4d6533a5babd23262f27eb65fd4b5b12a5d889c0 - clean; bad! 739ee655294be56021dc6244dde3faa75e288bd5 - clean; bad! c76678bbe9c3f835e0fd3dc2ec2381ec821dd548 - clean; bad! [dg@dalek core]$ git log --pretty=oneline 9b7c7322^..c76678bbe9c3f835e0fd3dc2ec2381ec821dd548 c76678bbe9c3f835e0fd3dc2ec2381ec821dd548 tdf#155390 Impress template Growing Liberty update 3f20d1dad1b84367f8ec322690dae20b0defbb08 tdf#146609 Renamed line width to thickness. 2902ab24ecc5ffbf4907ea83b2028508b9de6364 tdf#124591: Rename *noto.mk to *noto_kufi_arabic.mk 739ee655294be56021dc6244dde3faa75e288bd5 tdf#124591: Remove Noto Mono ****4d6533a5babd23262f27eb65fd4b5b12a5d889c0 tdf#124591: Update Noto Naskh Arabic to v2.016 ****00db8423d18d75f982b337744ec39c4b7269a433 (HEAD) tdf#124591: Update Noto Sans Lisu to v2.102 114b94f7e04daf699dad44857c1a86932f466c46 tdf#124591: Update Noto Serif Lao to v2.003 c4609a0721b466a805514197cd6872e0dfb07aa6 tdf#124591: Update Noto Sans Lao to v2.003 0d49ac1ba30e2cb6247a77e75383176a4624adfd tdf#124591: Update Noto Serif Georgian to v2.003 529ddd57c673f49a334b0813f979e7c88db2f46b tdf#124591: Update Noto Sans Georgian to v2.003 15f234bab54c990f3d5362b89afc097f82718e9b tdf#124591: Update Noto Serif Armenian to v2.008 d69317ca8f4b39c7fe62e9404f93d5d43e5495d6 tdf#124591: Update Noto Sans Armenian to v2.008 7376eed0f00ab7d3217f484a707aaf5ef4bc801e tdf#124591: Update Noto Serif Hebrew to v2.003 448d5d7fbfc3d545cb9f8e5e89514784b03e4cd1 tdf#124591: Update Noto Sans Hebrew to v2.003 9998c242c6c2ece5f240db2f6ffdf04e7ca7cbb4 tdf#124591: Update Noto Sans Arabic to v2.010 ee9b13668cf955d2f3ad927f26bf3e1910779047 tdf#97710: do not create nonzero conform for polyline 96aba2de78ffa641f6c0c898b99158715b2f2703 tdf#124591: Update Noto Serif to v2.012 69943f33bf219558d6b219f0eaeda1e25e487b05 tdf#124591: Update Noto Sans to v2.012 defc3dd75ff8ff937d2161237b281284240b86f0 Update git submodules 2b153ad42904e433d41b630fc80daf4a57112681 tdf#146619 Recheck include/o3tl with IWYU e0021031f6cb0c52892142d5753b222d571acf49 tdf#85263 Resolve accelerator collision in Options - User Data page 8d7a27a3e4b71e6be44e7fc07f370e18bf475b4c Resave in newer Glade version e53a99c4bbf09763ecfb05a0926e7957b31c1fff tdf#105303 (related) Drop unused translation strings 9b7c732215f2dc34d1f0cfc08ea912a3925b13b0 Resolves: tdf#151919 mark blanked fields as requiring a reformat So we have a lot of font updates around the failure, the one just *before* the last good one is 'Remove Noto Mono' which you can imagine might surprise something; but it's not actually the transition for me - still, I bet it's something to do with the svg importer choosing the font it uses.
Adding in Khaled since they did the font wrangling.
I don’t know why updating a bunch of font families would affect something like this, but the SVG files uses a generic font family name ("serif") so some form of font fallback would be happening, and this may be fragile for some reason or another.
OK, I think the problem is that LO is using it's fonts to decide which font to use but then mmap'ing the system fonts that aren't consistent with them; Turning on some debug, in the working one I see: info:vcl.fonts:PIDb:PIDb:vcl/unx/generic/fontmanager/fontconfig.cxx:1123: PrintFontManager::Substitute: replacing missing font: 'serif' with 'Noto Serif' info:vcl.unx.freetype:PIDb:PIDb:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSerif-Regular.ttf' successfully so that's found my system NotoSerif-Regular I guess. On the broken one we have: warn:vcl.fonts:2547652:2547652:vcl/unx/generic/fontmanager/fontconfig.cxx:1029: no FC_FILE found, falling back to name search info:vcl.fonts:2547652:2547652:vcl/unx/generic/fontmanager/fontconfig.cxx:1123: PrintFontManager::Substitute: replacing missing font: 'serif' with 'Noto Naskh Arabic' Lots of: info:vcl.gdi:2547652:2547652:vcl/source/outdev/font.cxx:1083: Font fallback to the same font, but has missing codes but if I look at the LO provided Naskh Arabic font in FontForge the font has the standard latin A-Z/a-z - so it should be fine. But... grep'ing for noto and mmap, in the working one: [dg@dalek core]$ grep -i noto log.00db8423d18d |grep -i mmap info:vcl.unx.freetype:PIDb:PIDb:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Regular.ttf' successfully info:vcl.unx.freetype:PIDb:PIDb:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Thin.ttf' successfully info:vcl.unx.freetype:PIDb:PIDb:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto-vf/NotoSansArabic[wght].ttf' successfully info:vcl.unx.freetype:PIDb:PIDb:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Medium.ttf' successfully info:vcl.unx.freetype:PIDb:PIDb:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSerif-Regular.ttf' successfully and in the broken one: info:vcl.unx.freetype:PIDb:PIDb:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Regular.ttf' successfully info:vcl.unx.freetype:2547652:2547652:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Regular.ttf' successfully info:vcl.unx.freetype:2547652:2547652:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Thin.ttf' successfully info:vcl.unx.freetype:2547652:2547652:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto-vf/NotoSansArabic[wght].ttf' successfully info:vcl.unx.freetype:2547652:2547652:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Bold.ttf' successfully info:vcl.unx.freetype:2547652:2547652:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Thin.ttf' successfully info:vcl.unx.freetype:2547652:2547652:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto-vf/NotoSansArabic[wght].ttf' successfully info:vcl.unx.freetype:2547652:2547652:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto/NotoSans-Medium.ttf' successfully info:vcl.unx.freetype:2547652:2547652:vcl/unx/generic/glyphs/freetype_glyphcache.cxx:139: mmap'ed '/usr/share/fonts/google-noto-vf/NotoNaskhArabic[wght].ttf' successfully now if look at /usr/share/fonts/google-noto-vf/NotoNaskhArabic[wght].ttf it is missing the standard ASCII letters. (That's from Fedora's google-noto-naskh-arabic-vf-fonts-20230801-3.fc39.noarch package) So, it looks like LO is making decisions on the font to use based on it's installed set, but then using the system fonts that are inconsistent with that decision.
That would explain why the font updates trigger this, since the previous Noto Naskh Arabic version we were bundling didn’t have any Latin glyphs, like the system version on the broken systems.
(In reply to خالد حسني from comment #11) > That would explain why the font updates trigger this, since the previous > Noto Naskh Arabic version we were bundling didn’t have any Latin glyphs, > like the system version on the broken systems. I bet this bug rehappens every few years as fonts change. Who is the person who knows about the font paths and caching stuff?
This is happening on Linux, so it is probably either a FontConfig issue or an issue on how we use FontConfig, so Caolán McNamara is probably the one most familure with this code.
OK, so since it's FontConfig stuff, it's not related to the actual import filter I'd originally filed it against, so lets swing this to 'graphics stack' (is that right for fonts?) and cc Caolán
I think we can confirm this anyway seeing as I can get it to happen too
It doesn't help a lot that both LibreOffice's bundled: instdir/share/fonts/truetype/NotoNaskhArabic-Regular.ttf and fedora system /usr/share/fonts/google-noto-vf/NotoNaskhArabic[wght].ttf have the same version, but the fedora one has less glyphs
(In reply to Caolán McNamara from comment #16) > It doesn't help a lot that both LibreOffice's bundled: > instdir/share/fonts/truetype/NotoNaskhArabic-Regular.ttf > and fedora system > /usr/share/fonts/google-noto-vf/NotoNaskhArabic[wght].ttf > have the same version, but the fedora one has less glyphs Noto fonts come in several builds, one of them is called “full” which includes Latin (and other common) glyphs and tat what we are now bundling (because it causes less problems to have Latin in the fonts), but Fedora might be packaging the build that has Arabic only.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6fbd5a72c83a6d50a650fe9ae5f5ed0e54dbdd59 tdf#157939 drop duplicates from the FontConfig Set It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to خالد حسني from comment #17) > Noto fonts come in several builds, one of them is called “full” which > includes Latin (and other common) glyphs ... but Fedora > might be packaging the build that has Arabic only. That might explain it. I do also see "Bad device table" warnings on opening: /usr/share/fonts/google-noto-vf/NotoNaskhArabic[wght].ttf with fontforge, something I don't see with: instdir/share/fonts/truetype/NotoNaskhArabic-Regular.ttf Either way, I think it makes sense to use a FcFontSet for the font/glyph fallback with just the fonts in it that we haven't ignored. Things seem to work now.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2f2803a77af3bfdab979bd44ce61866e6985d172 Related: tdf#157939 put CppunitTest_svgio under non_application_font_use:abort It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks! (I can't verify it myself at the moment due to a different failure)
(In reply to Caolán McNamara from comment #19) > (In reply to خالد حسني from comment #17) > > Noto fonts come in several builds, one of them is called “full” which > > includes Latin (and other common) glyphs ... but Fedora > > might be packaging the build that has Arabic only. > > That might explain it. I do also see "Bad device table" warnings on opening: > /usr/share/fonts/google-noto-vf/NotoNaskhArabic[wght].ttf > with fontforge, That is because it is a variable font which is too new for FontForge (FontForge is not seeing much of development these days).