Created attachment 143215 [details] Example RTF file, as created by MS Word 2010 I'm currently trying to use libreoffice to batch convert some documents (RTF in this case) to PDFs, however after investigating it became clear that the table header row repeat isn't being correctly handled. I am attaching an example .rtf file which was created by MS Word 2010, as well as the PDF renderings made by that same version of MS Word and LibreOffice 6.
Created attachment 143216 [details] MS Word 2010 PDF export of the example
Created attachment 143217 [details] LibreOffice6 PDF export of the example (INCORRECT RENDERING)
confirmed with RTF from attach for Version: 6.1.0.0.beta2+ (x64) Build ID: fe1a23b5c49c94410a604c8d4a6f50f43d575403 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-06-17_06:31:41 Locale: ru-RU (ru_RU); Calc: CL
Hi Michael, kompilainenn, I confirm too with 6.2.0.0.alpha0+ Build ID: 4a82543b3419339ae554485c582a80c41a57c417 CPU threads: 2; OS: Windows 6.1. Once opened this file in Word, selected the whole table, looking at the table propreties, Line Tab, Line Options: Repeat at top of each page as header line is ticked. Opening this file in Writer, after Table properties selecting, Text Flow Tab, Repeat heading is not ticked. When done, Table reprove the same aspect as in Word.
Also reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.10; Render: default; Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) but not in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
(In reply to Xisco Faulí from comment #5) > Also reproduced in > > Version: 5.2.0.0.alpha0+ > Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 > Threads 4; Ver: 4.10; Render: default; > > Version: 4.3.0.0.alpha1+ > Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e > > Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) > > but not in > > LibreOffice 3.3.0 > OOO330m19 (Build:6) > tag libreoffice-3.3.0.4 Given your investigation, I believe the most logical introduction of the bug was in the switch mentioned in the RTF metabug post 25: https://bugs.documentfoundation.org/show_bug.cgi?id=81234#c25 It seems like a bunch of /other/ bugs were all quashed with that switch, so it's no surprise that a smaller corner case like this was missed.
After giving up on creating my /own/ example file by hand (MS Word wound up in an infinite loop generating the table over and over again), I have identified a more likely cause of the issue. http://www.biblioscape.com/rtf15_spec.htm \trhdr "Table row header. This row should appear at the top of every page the current table appears on." These look like the parts of the RTF filter that are broken. https://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/rtftok/rtfcontrolwords.hxx https://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/rtftok/rtfcontrolwords.cxx The control word is identified, but no actions are taken based on it's existence. A unit test might also be failing based on \trhdr existing in... https://cgit.freedesktop.org/libreoffice/core/tree/sw/qa/extras/rtfimport/data/tdf99498.rtf Some of the svgtools files mention it. Interestingly there's also this file: https://cgit.freedesktop.org/libreoffice/core/tree/compilerplugins/clang/unusedenumconstants.writeonly.results RTF_TRHDR is among the many RTF_ enums that are defined but "never actually used". Currently LibreOffice also cannot /export/ an RTF document with a repeating header row (however adding the missing keyword manually does allow MS Word to read it with that property).
Problem is seen in the oldest commit in 43all bibisect repo.
Dear Michael J. Evans, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
\trhdr tag is ignored in the latest version of LibreOffice writer. Please let me know if you need more detail. Could this fix be prioritized in the next release?
(In reply to LibreUser from comment #10) > \trhdr tag is ignored in the latest version of LibreOffice writer. Please > let me know if you need more detail. Could this fix be prioritized in the > next release? Sure, if you pay for it.
First of all, I would like to say big Thank You to all developers who contributed to such amazing software. I would more than happy to contribute. Please advise on the process
(In reply to LibreUser from comment #12) > First of all, I would like to say big Thank You to all developers who > contributed to such amazing software. > > I would more than happy to contribute. Please advise on the process Contact a certified company or individual: https://www.documentfoundation.org/gethelp/developers/
Thanks, just one question. Once fix has been developed than could it be added into the regular release. I would not prefer to keep fix as a separate fork.
(In reply to LibreUser from comment #14) > Thanks, just one question. Once fix has been developed than could it be > added into the regular release. I would not prefer to keep fix as a separate > fork. It will not be in any separate fork.
The recently reported bug 134002 is really similar, I was tempted to close as duplicate, but that one is already buggy in 3.3.0, so there must be some kind of difference compared to this file.
Repro 7.1+. For testers, same file resaved in MSO as DOC or DOCX opens OK in LO.
*** Bug 134002 has been marked as a duplicate of this bug. ***
Dear Michael J. Evans, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
While I am not the original author, I confirm that this bug still exists in the current version of LO: Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 8; OS: Mac OS X 12.6.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded This bug also exists in v7.4.0.3 (on Mac OS X 12.6.1) and v7.0.4.2 (on Ubuntu 20.04). LO 3.3 will not run (an update to it is required for this OS), so I cannot confirm the earlier assertion (in #6) that this bug is a regression -- however, FWIW, a similar bug existed in Open Office (https://bz.apache.org/ooo/show_bug.cgi?id=55088); the description of that Open Office bug report is: "The tag for table row header (\trhdr) is being ignored. The row which is marked with the \trhdr tag should appear at the top of every page on which the table containing the row appears. It works in oo 1.1.5 and 1.1.4, but not in 2.0." This is the exact behavior I'm seeing in LO, which occurs both in the GUI, and when called with --headless to convert RTF to PDF. Additional observations (using 7.4.3.2/Mac): When opening an RTF document with a multi-page table that contains the \trhdr tag, that tag is indeed ignored; Table Properties... shows the Repeat Heading checkbox is unchecked. Checking that box does prefix the specified header row to each page of the table. Saving that file in ODT format does preserve that setting, but saving in RTF does not (no \trhdr tag is present), and emits the warning that the document may not save correctly. Exporting as PDF with that box checked likewise results in the prefixed header on every page.
*** Bug 153450 has been marked as a duplicate of this bug. ***