Created attachment 120369 [details] Odt-document for testing the export - look at the width between text and bullet. Open the attached *.odt-file. Shows a little bit text and the start of a list with a bullet. Export this with File → Export ... to a xhtml-file. Open this file with your browser. The bullet is on the left, directly followed by the text. Open the *.html-file for editing. Inside this file is shown "min-width:0,635cm;" This is a wrong decimal-separator and couldn't work. Change this to "min-width:0.635cm;" and the list would be shown in a better way. Seems this bug appears mostly together with bullets. Have tried to change the GUI from German to English - no effect. Have tried to change the local schema to English - no effect.
Created attachment 120370 [details] XHTML-file produced by LO while exporting - wrong decimal-separator for min-width
For me not reproducible with LO 5.0.3.2, Win 8.1
(In reply to A (Andy) from comment #2) > For me not reproducible with LO 5.0.3.2, Win 8.1 Could be I have to describe a little bit better: 1) Open the attached *.odt-file 2) Go to File → Export (not: File → Save As) 3) Select format XHTML 4) Save the file There will appear a file with *.html (better should have *.xhtml). Code is something like this: ... <span style="display:block;float:left;min-width:0,635cm;">•</span>One bullet. Decimalseparator for margin on left ... The min-width is set wrong here. If doing File → Save As the code is totally different. It produces ... <li/> <p style="margin-bottom: 0cm; line-height: 100%">One bullet. Decimalseparator for margin on left ... No min-width is set here. The format isn't the same. For exporting a book (like Base-Handbook) it is unusable.
Thanks for your reply. But unfortunately not reproducible for me. I get: "<span style="display:block;float:left;min-width:0.635cm;">•</span>One bullet. Decimalseparator for margin on left side should be 0.6<span class="T1">" Maybe a Linux only issue?
I have set back the user-profile here. Same behavior. I changed to the LO-Version of OpenSUSE - same behaviour. Changed to LO 4.1.6 (have installed many LO-versions parallel) - same behavior. My System: OpenSUSE 13.2 64bit rpm Linux. Seems we have to look for another person with Linux.
I get min-width:NaNcm; Setting to NEW. Ubuntu 15.10 64-bit Version: 5.0.2.2 Build ID: 00m0(Build:2) Locale: en-US (en_US.UTF-8)
Have tested a little bit more. The bug first appears with LO 4.0.0.3. Up to LO 3.6.7.2 the created code shows only '0' for min-with. So no min-with is defined at all. Seem this feature has been added with LO 4.0. I will set this one as "regression". Could be it is wrong to set this as "regression", because the feature doesn't exist before.
(In reply to robert from comment #7) > Seem this feature has been added with LO 4.0. I will set this one as > "regression". Could be it is wrong to set this as "regression", because the > feature doesn't exist before. Let's change to implementationError
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Bug still exists with LO 5.3.1.1, OpenSUSE 42.1 Leap, 64bit rpm Linux.
** Please read this message in its entirety before responding ** 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
Bug still exists with LO 6.0.5.2, OpenSUSE 42.3 Leap, 64bit rpm Linux.
Dear robert, 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
Bug still exists in LO 6.2.5.2 on OpenSUSE 15 64bit rpm Linux
adjusting "$listLabelWidth" to "translate($listLabelWidth,',','.')" in the File filter/source/xslt/odf2xhtml/export/xhtml/body.xsl in Lines 2045 and 2107 fixes this for me, preparing a pull request at the moment...
I made a commit at https://gerrit.libreoffice.org/c/core/+/104544, this gerrit configuration is new to me, i usually only use git, but I over all like the Interface, good thing i don't have to install gerrit, last time i tried that it deleted my username on deinstaling it again xD
gerrit committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9804cb2f195451811eff8924d7997a3cbd6d679d tdf#95662 Convert , to . for the min-width in the Lists only It will be available in 7.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.
Hi Robert, Before and after your commit I get 'min-width:NaNcm', do you know why ?
(In reply to Xisco Faulí from comment #18) > Hi Robert, > Before and after your commit I get 'min-width:NaNcm', do you know why ? Hi Xisco, First of all, I am not my dad, I am Roberts son, Gerrit. Secondly, the NaN (not a number) is propably a bug coming from deeper in the code, this fix just scratched the surface, I have not looked so deeply into where the numbers come from. I think it would be best to put that in a new Bugreport and provide a minimal example file to better understand where the faulty numbe could be coming from. Greetings, Gerrit
(In reply to Gerrit Großkopf from comment #19) > (In reply to Xisco Faulí from comment #18) > > Hi Robert, > > Before and after your commit I get 'min-width:NaNcm', do you know why ? > > Hi Xisco, > First of all, I am not my dad, I am Roberts son, Gerrit. Secondly, the NaN > (not a number) is propably a bug coming from deeper in the code, this fix > just scratched the surface, I have not looked so deeply into where the > numbers come from. I think it would be best to put that in a new Bugreport > and provide a minimal example file to better understand where the faulty > numbe could be coming from. > Greetings, > Gerrit Hi Gerrit, sorry for the confusion, won't happen again. Could you please share the info from About LibreOffice dialog? Version: 7.2.0.0.alpha0+ Build ID: 8b3982681e98818388c09233960ad6eaacee205a CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded it's weird that I and buovjaga ( comment 6 ) get min-width:NaNcm and you get min-width:0,635cm
(In reply to Buovjaga from comment #6) > I get > min-width:NaNcm; > > Setting to NEW. > > Ubuntu 15.10 64-bit > Version: 5.0.2.2 > Build ID: 00m0(Build:2) > Locale: en-US (en_US.UTF-8) If that helps, I get NaNcm on every mention of the word "border-?-width", e. g. border-bottom-width:NaNcm; border-left-width:NaNcm; border-top-width:NaNcm; Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5 Locale: pt-BR (pt_BR.UTF-8); Interface: pt-BR Calc: threaded (This may explain why I don't get a bottom border in some paragraphs)
For the record, here without the patch/commit, I do *not* get NaN (Not a Number) with Locale: en-US (en_US.UTF-8). I get min-width:0.635cm; as expected. Xisco: as you are able to repro the NaN thing, you could debug the XSL values a bit. I will explain what I did. In the file filter/source/xslt/odf2xhtml/export/xhtml/body.xsl find the variable block <xsl:variable name="listLevelTextIndent"> After the closing tag of the variable, insert <xsl:message> listLevelTextIndent <xsl:copy-of select="-$listLevelTextIndent"/> </xsl:message> Then run make filter Now, when you export the ODT bug document to XHTML, it will print your debug message to your console!! Further, you can experiment and use your imagination variously with the debug elements to try to find the root cause :)
Dear Gerrit Großkopf, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
There is only fixed a part of this report. There also appear "margin-left:1,27cm;". There must be something going wrong deeper in the code which sometimes sets the German decimal separator. Looks as if its not recognized as a number …
I now get "min-width:0cm" when exporting with LO 7.2 alpha1: <span style="display:block;float:left;min-width:0cm;">•</span> Version info: Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 4a9eef7849a75ba91806886ea9c96d114c8d56f9 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-05-22_06:45:25 Calc: threaded
Seems this is getting worse. At this moment I could only export with LO 7.1.5.2, open a text editor and remove :0, with :0. :1, with :1. With LO 7.2.5.2 and newer versions I can't get a tab between bullet and following text. Bullet will disappear inside the text. Seems we have to revert to the old behavior… Have had this trouble every time I have updated the German Base Handbuch, so I didn't test it before.
(In reply to Robert Großkopf from comment #26) > Seems this is getting worse. > > At this moment I could only export with LO 7.1.5.2, open a text editor and > remove > :0, with :0. > :1, with :1. > > With LO 7.2.5.2 and newer versions I can't get a tab between bullet and > following text. Bullet will disappear inside the text. Seems we have to > revert to the old behavior… > > Have had this trouble every time I have updated the German Base Handbuch, so > I didn't test it before. I am not seeing any visual difference with the bullet. The change is seen in the style, where the min-width for the bullet span used to be 0.635cm and is now 0cm. I bisected the change with the help of the command line conversion: instdir/program/soffice --convert-to "html:XHTML Writer File:UTF8" --outdir ~/libobugs ~/libobugs/decimalseparator_xhtml.odt The changing commit is https://git.libreoffice.org/core/commit/9d3b39cf9fed9a305ac23d1ecaaafc8f7caaeeb0 HTML XSLT: Missing paragraph BORDER of stand-alone border paragraph (@style:join-border problem) However, I don't understand why the XHTML filter exports the bullet in such a silly way: <span style="display:block;float:left;min-width:0cm;">•</span> It manually inserts a bullet character! The HTML filter does not do this silliness.
(In reply to Buovjaga from comment #27) > > > > At this moment I could only export with LO 7.1.5.2, open a text editor and > > remove > > :0, with :0. > > :1, with :1. > > > > With LO 7.2.5.2 and newer versions I can't get a tab between bullet and > > following text. Bullet will disappear inside the text. Seems we have to > > revert to the old behavior… > > > > Have had this trouble every time I have updated the German Base Handbuch, so > > I didn't test it before. > > I am not seeing any visual difference with the bullet. Try the new attached documents. Original *.odt and export with LO 7.1.5.2 and also LO 7.4.0.2. Both exports will look the same. Now remove :0, with :0. :1, with :1. There won't be found :0, in the document exported with LO 7.4.0.2. The export doesn't change but the export with LO 7.1.5.2 will look right.
Created attachment 181858 [details] Original for export to xhtml
Created attachment 181860 [details] Result export with LO 7.1.5.2
Created attachment 181861 [details] Result export with LO 7.4.0.2
Created attachment 181862 [details] After replacing :0, with :0. and :1, with :1. it looks well in LO 7.1.5.2 - but not in LO 7.4.0.2