Created attachment 170810 [details] source ott & two different html files, due to different screen resolution I've a java program that exports a block of the document, delimited by a bookmark. I use XSelection/XTransferable/isDataFlavorSupported() to select the bookmark text and then to export it as HTML. Everything worked. Suddenly I had a problem with a template because the colWidths of a html table had a different size than before. I've investigated the issue and I found that the problem is related to the monitor resolution. If I run the program with a resolution of 1920x1080, the colWidths of the html table are about 20% larger than if run the program with a screen resolution of 1600x900. A) Large colWidths (1920x1080 - font size 125%) <colgroup> <col width="194"> <col width="177"> <col width="189"> <col width="188"> </colgroup> B) Normal colWidths (1600x900, 1920x1080 - font size 100%) <colgroup> <col width="154"> <col width="141"> <col width="151"> <col width="150"> </colgroup> I tried different resolutions and I've got always results of kind A or of kind B. Another clue: the program with the same resolution (1920x1080) but with a different Font Size (100% or 125%, Windows 10 settings) produces different results (respectively A and B) In attach there's a zip file with an OTT that has a Bookmark BK_TESTO_LIBERO that I export. As you can see from the two HTML files, a table has different colWidths. I use this HTML to display some text to the end user with a rich text component and then I take it back. With the large colWidths, the table in the final document goes over the right margin. Is there a way to have the same result independently from the screen resolution? David p.s. If needed, I can try to build a simple java program to test it.
Does it also behave like this with 7.3?
Don't know, it's not the version used by my company.
(In reply to David Obber from comment #2) > Don't know, it's not the version used by my company. Are you saying you are unable to test with version 7.3 even on your home computer?
Correct.
(In reply to David Obber from comment #4) > Correct. And the reason is that you can't take that Java program with you from work to home?
Exactly. It's a legacy ear and it's not easy to isolate the code. I can try to write a simple program at home that does the same, but it will require some time. Maybe next week I'll be able to test it.
Created attachment 179667 [details] git repo of a simple program I've built a simple class where I've successfully tested that changing the font size in windows screen settings (from 100% to 125%) has a relation with the html produced exporting the bookmark BK_TESTO_LIBERO. It still happens even with the version 7.3.2
Created attachment 179675 [details] Git repo of a simple gradle project I've built a simple class where I've successfully tested that changing the font size in windows screen settings (from 100% to 125%) has a relation with the html produced exporting the bookmark BK_TESTO_LIBERO. It still happens even with the version 7.3.2
(In reply to Buovjaga from comment #5) > (In reply to David Obber from comment #4) > > Correct. > > And the reason is that you can't take that Java program with you from work > to home? Did you see my last comments?
(In reply to David Obber from comment #9) > (In reply to Buovjaga from comment #5) > > (In reply to David Obber from comment #4) > > > Correct. > > > > And the reason is that you can't take that Java program with you from work > > to home? > > Did you see my last comments? Yes. Thanks for the resources. Hopefully someone can test them.
(In reply to David Obber from comment #8) > Created attachment 179675 [details] > Git repo of a simple gradle project > > I've built a simple class where I've successfully tested that changing the > font size in windows screen settings (from 100% to 125%) has a relation with > the html produced exporting the bookmark BK_TESTO_LIBERO. It still happens > even with the version 7.3.2 I had to git reset --hard the unzipped git repository in attachment 179675 [details] to see the files. For Windows testers, would be good to explain how to use the script, e.g. that it needs specifying the location of soffice.exe as an argument to gradlew run, etc. In any case, I was able to reproduce on Ubuntu 20.04, using GNOME's "Large Text" accessibility setting: 1. Open attached OTT 2. Save as > HTML (Writer) 3. Close, change DE setting to "Large Text" 4. Repeat steps 1-2 Results: differently sized tables in resulting HTML files, even though the size is the same in-app. Version: 7.3.7.2 / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded As well as a recent master build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e26aeb882dd236adf19679d5df9b7ba5da1ed226 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded ... and at least since 5.4.0.3. A diff of the two resulting files shows that the only dimensions affected are related to tables: table width / cellpadding; col width; td width / height. Not reproducible with Export > XHTML.
Dear David Obber, 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