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: 22.214.171.124.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 126.96.36.199.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
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default;
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Version 188.8.131.52.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
but not in
(In reply to Xisco Faulí from comment #5)
> Also reproduced in
> Version: 184.108.40.206.alpha0+
> Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
> Threads 4; Ver: 4.10; Render: default;
> Version: 220.127.116.11.alpha1+
> Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
> Version 18.104.22.168.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
> but not in
> LibreOffice 3.3.0
> OOO330m19 (Build:6)
> tag libreoffice-22.214.171.124
Given your investigation, I believe the most logical introduction of the bug was in the switch mentioned in the RTF metabug post 25:
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.
"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.
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...
Some of the svgtools files mention it.
Interestingly there's also this file:
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!
\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
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.