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.