Created attachment 187933 [details] bug docx text missing first coloumn lo viewer android * open bugdoc16062023.docx * ms word & lo writer has text in first three cells of first coloumn * libreoffice viewer [ android ] text is missing * repro libreoffice: f-droid: Version: 7.6.0.0.alpha1+, Build ID: 5c1c768e128d OS: Android * no repro libreoffice: Version: 7.5.4.2 (ARM_EABI) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: x11 Locale: en-US (C); UI: en-US Calc: threaded OS: NAME="openSUSE Tumbleweed", VERSION_ID="20230604" Word: Version: 1.0.1 (16.0.1.16501.20160) OS: Android
Created attachment 187934 [details] screenshot of docx text missing first coloumn libreoffice viewer android
Created attachment 187935 [details] screenshot of docx text visible first coloumn word android
Created attachment 187936 [details] screenshot of docx text visible first coloumn libreoffice writer linux
I can reproduce with the same version from F-Droid. This is already fixed in the current development version and the table is displayed fine there. Version: 24.2.0.0.alpha0+ Build ID: ba38ef8f7733 Bibisecting with lloconv (which also uses tiled rendering) points to this commit in the linux-64-7.6 repo, so one of the mentioned commits is the fix: commit 4f7a5ad3b108a9e95347968eb0922a4561cf61f5 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Jun 1 12:56:18 2023 +0200 source 5e68d6cfade45f40b1ad46025a81afe4cb8dd337 source 5e68d6cfade45f40b1ad46025a81afe4cb8dd337 source f15a6e1b1b186bf42e1ade05630d17841add2c46 source c1893df42567c260ca5fb069038d1a55616e7b7f source 36ec021c6eafe80caefbedbbe674bd1ee0a9429a source a5c1b749a89b662f9a136d774b3dfd5fbd639c50 source 811e67eb45b1fc97d8c8cc9509acb33267a51aa4 source e2f90d1d0e51c68dd01c9968cdb7a3bbb5658613 source 4ee0aa2ebda0ccd61ea4e0da3caa07d5f9a72eb9 source 99d22fd79c5532fd6c1b167996e1c27216b92469 source 70fd835b4cf75e386ee115c705241a4059fb68a8 source a05dc1591ca9122056e95cb2801e7f924bb7ecdb source 74a306ef4aa425a5637c7c4766600de6c4bc504c source c58ff5befa4c9704ab54f365811af4beeea384a8 source aad2ca8bd3986510b2331752d92958c96ec93f9f source a2bb3dc8696e52b1bf4b0057e2a3fb349c6ca509 source 55b9419e541990fe4f96dd59a42359f86901ab3a source 006990b8d6337c232f0fe06fc284d83c44e6dc80 source 66eabacb7c3618d2724470203d7e95c256334520 source 192167f635e87e1acee9c31d1153285479dc04ab source 6a059f8d1b0a7a5b64bd272e1e7b8291979bcd56 source 6aec73de12a56a56b3ffd9bb86b559bf0609bf58 source 58ab2f002fd27974b474151b01287dac221dc102 source 009b889616561176a230bc041699271697f95bf6 source 046e37faa295889157f0313f2300d93cb0f83b9e source 4f98574b78ed1b06bac1d440d75d8ce1ddea8309 source 5194bb56b6db3b67389cad977c27a7b34f51044b source dcc54c4c4bd3c938ba4b06e89f5688ae262b8507 source 8811bf5aa94df5beff2249e1f51d383b3df6409c source 8ac06469dc0338ed57af76cba9d96117d753422c source 847f899cb3f9607b55fd5989b2043a0b513dec22 source 1bc6d8f811e0941d1a8046c9ba725d0f38223143 source f1ec565d4843284e43614d208b006420732b98e8 source 2cda7933d1ed9e28153f6083e353df352851e235 source a0ee0fe0d5340ba67e849068af9a50108cd27e5f source 7be7e1ff95af485a9cb00748800d3d084f96387c source 8259a99f41367a1d8326c9157fe1902915715879 source c6fcc69ec3a4b36526fbf8ca959371d1ee8e0fb3 source e851d081c614107c450f8ac87e415b49a58bb5bf source f6c753cc0f42e94f89361b7d1c41dae069ed73aa source 2a380dba73d57f825128fbada91c7a9fe79e8a06 source b960668bbde1c77c5eadf0a1ad8abde08114810f source 60e499147963e42ce783dffcf9c8d4aba8b5d475 source b2da36a0837c3d2614917f2382c19c070c5750ed source e0d2996d05be4eb0a3fdc6d1a5155e55294cbb11 source ecd270bc44d094cc01e9978af60715c0d3940416 source 0ceb131e964206efbb1c76a03f19d1992e2f89c7 source 60e32969a98cad348cf8e55e8f93abc3d6e9c70c source 8b5f9debcdb861589c6c9b01858388603dec0d24 source 35a79eac56f8b93b62de555ea92c28304f2333d9 source 05bc773b0e88b408a997ffa5851cc9207d3303e5 source 4c29c7107ed45b777a63c4060340e03f54375391 source d2c02a9aba3c05e4b3072596d2b3871b7fe67864 source d669df25d2ac950da85e9d60074d059f9ef1459a source 4998370216bbea3bcaff7fac2d62cbb4ac978c5d source 8c1892cd80a5095b38e88d558f653b27d93b074c source 20db76c08f870f1f1b4f890d93c0597e2bd36a0a source c9d3abf80e6d8617b7447d2f291cefe16c133514 source 57d5c01ac1bcce56591b4eae96d1e679ef7197d4 source d785d26a5599d3d546b96958b0f1c6d5ed777a0d source 5655cc201e5a80997fe21bc2a0c7abcbe4fb488f source 8716f10f8a3b59ceb8b7673d6c5948b882830167 source bf8d1290a4de26f06d429148a92cbdb7a63eecf5 source 385d3323ce23833e8706b0d21f6df07e1927b8e0 source cf4a1c42d6a90ec73ab1504d4bfaf3004bad33da This one sounds like it: commit e2f90d1d0e51c68dd01c9968cdb7a3bbb5658613 Author: Miklos Vajna Date: Thu Jun 1 08:31:34 2023 +0200 tdf#103869 sw floattable: fix lost table right before a section break from DOCX The bugdoc has 2 pages and 2 tables, one table on each page. The table on the first page was missing in Writer. What happened is that the floating table is anchored in the next paragraph, but that is removed (since it's the last one in the section, so no need for a "next" paragraph), which shifted the table to the next section, which was already a wrong anchor point. Then that next section (next page) started with a (floating) table, so a dummy text node was inserted at the start, which means once it's disposed at the end of the 2nd section, we lost the first floating table with its bad anchor. Fixing the problem was a bit tricky, because DomainMapper_Impl::RemoveLastParagraph() is called before the text frame conversion would be invoked in DomainMapperTableHandler::endTable(), so we can't check if this last paragraph has something anchored in it, as it's too early. Instead, detect that a floating table will be created, and don't remove the last paragraph in this case, since we know that we're at the end of the section (that's why we remove the last paragraph). The export result looks OK, we keep the paragraph-table-paragraph-table-paragraph model correctly. Change-Id: I4612a15d0d1ad3fe527593a21a4120096790a33f (cherry picked from commit ba2f4ebc5343f3eca27baaaf27906be2e6486fcd) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152472 Reviewed-by: Miklos Vajna Tested-by: Jenkins -> Closing as FIXED
@Michael Weghorn Just for the record & clarification. tdf #103869 was reported in november 2016 & fixed in june 2023. Patches are backported? first in still or fresh versions. Or is it arbitary?
(In reply to jindam, vani from comment #5) > tdf #103869 was reported in november 2016 > & fixed in june 2023. Patches are > backported? first in still or fresh > versions. Or is it arbitary? Whether backports are done is generally a case-by-case decision (and backporting to fresh happens more often than to still). For tdf #103869, there are no backports to release branches, so it will be fixed in 7.6.0.
(In reply to Michael Weghorn from comment #6) > (In reply to jindam, vani from comment #5) > Whether backports are done is generally a case-by-case decision Thanks for clarification > (and > backporting to fresh happens more often than to still). Good..... ;)