Bug 69017 - FILEOPEN: text rendering (font replacement for UniversR 45 Light) in some cells too wide (new lines, changing row height, an extra page)
Summary: FILEOPEN: text rendering (font replacement for UniversR 45 Light) in some cel...
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: filter:doc, notBibisectable, regression
Depends on:
Blocks: DOC-Tables
  Show dependency treegraph
 
Reported: 2013-09-06 08:40 UTC by bugzilla
Modified: 2021-03-26 14:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
MS Office doc with columns, rows and fields (916.50 KB, application/msword)
2013-09-06 08:40 UTC, bugzilla
Details
offset in LibreOffice (92.30 KB, image/jpeg)
2014-01-31 09:01 UTC, bugzilla
Details
original (93.92 KB, image/jpeg)
2014-01-31 09:03 UTC, bugzilla
Details
comparison LO 4.1.3 - MS Word, font Arial (226.39 KB, image/jpeg)
2014-03-20 09:28 UTC, bugzilla
Details
PDF version of the DOC as viewed in DocsPal.com (50.39 KB, application/pdf)
2015-07-27 10:38 UTC, tommy27
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bugzilla 2013-09-06 08:40:24 UTC
Created attachment 85310 [details]
MS Office doc with columns, rows and fields

Problem description: Row heights changed, 2 pages instead of 1 page

Steps to reproduce:
1. open attached doc in LibreOffice 4.1
2. print document
3. check row heights in the printout

Current behavior: 2 pages are printed instead of 2, and 2 lines of the document appear on the second page. In the printout, some rows in the central part of the document are visibly higher than they are in the original document, hence 2 lines do not fit on the page. 

Expected behavior: All lines should be printed on he same page. Row heights should not change.

              
Operating System: Windows 7
Version: 4.1.0.4 release
Comment 1 bugzilla 2013-09-06 09:04:45 UTC
Printer / Printer Driver: Samsung CLP-320 Series
Comment 2 Jean-Baptiste Faure 2013-12-21 14:56:29 UTC
Opened with LibreOffice 4.2.0.1+, your test file takes 2 pages...
It uses the "UniversR 45 Light" font which is not installed on my computer.

Does this font is installed on your computer?

Please, could you try again but with a more ordinary font like Arial?

Best regards. JBF
Comment 3 bugzilla 2014-01-31 08:58:33 UTC
Wa re-tested the issue with Arial. Rows are still moved but less than in the first test. But still a new page can be created by moved rows.
Please see attachments - the lines indicate the offset.
Comment 4 bugzilla 2014-01-31 09:01:05 UTC
Created attachment 93104 [details]
offset in LibreOffice
Comment 5 bugzilla 2014-01-31 09:03:32 UTC
Created attachment 93105 [details]
original
Comment 6 Jean-Baptiste Faure 2014-02-01 13:02:25 UTC
Have you tried to play with the parameters of the table ?
For example set the width to 100% instead to an absolute value ?

Best regards. JBF
Comment 7 bugzilla 2014-03-20 09:26:22 UTC
We played with the table again. 
With the original font: We found out that in LO 4.1.3 the tracking of the font is different. 2 more lines.
With font changed to Arial, the tracking seemed to be the same in LibreOffice and Word, but also with Arial the fields are moved as you can see in Comparison-LO-MSWord.jpg.

We re-tested the tracking in the original font also in LO 4.2.1 and found that the font was a bit more narrow, but this did not cause a problem in the table.
Comment 8 bugzilla 2014-03-20 09:28:46 UTC
Created attachment 96085 [details]
comparison LO 4.1.3 - MS Word, font Arial
Comment 9 tommy27 2014-06-16 08:31:40 UTC
tested under Win7x64 with LibO 4.2.4.2
test file is shown and printed as 2 pages instead of 1.
I set status NEW.
Comment 10 QA Administrators 2015-07-18 17:43:37 UTC Comment hidden (obsolete)
Comment 11 tommy27 2015-07-27 10:38:49 UTC
Created attachment 117462 [details]
PDF version of the DOC as viewed in DocsPal.com

bug still present in LibO 4.4.5.1 under Win7x64
.doc testfile still shown and printed as 2 page document

I'm uploading a PDF version of the .doc testfile as is correctly shown in DocsPal as 1 page only.
Comment 12 tommy27 2015-07-27 12:03:59 UTC
just found that the bug was not present in LibO 4.0.6.2 
so it's a regression of the 4.1.x branch and needs bibisecting
Comment 13 Robinson Tryon (qubit) 2015-12-14 05:33:50 UTC Comment hidden (obsolete)
Comment 14 Cor Nouws 2016-09-06 08:55:37 UTC
So comparing daily20160902 with 3.3.0.4, I see that cells
  A5, A6, D19, A20, A29, E35 
have an extra line, caused by wrong text rendering.

Note: I don't have the font UniverseR 45 Light in both versions of LibreOffice.
Comment 15 Xisco Faulí 2016-09-13 14:37:09 UTC
As per today, this regression can't be bibisected as it was introduced before 4.4 branch and there's no bibisect repository for the affected branch for windows, thus change 'bibisectRequest' to 'preBibisect'.
Comment 16 QA Administrators 2018-10-02 02:56:08 UTC Comment hidden (obsolete)
Comment 17 Timur 2019-09-11 09:33:19 UTC
I reproduce 2 pages in Linux with 6.4+. Must be wrong "UniversR 45 Light" replacement. Not clear what would be an appropriate substitute. There's "Univers 45 Light" font that has only commercial substitutes. Maybe Open Sans or Roboto or Milford. Univers has broad range and there's really no universal 'alternative'. 

I don't reproduce in Windows in any version. Maybe because I have MSO? But font in LO is shown as substituted. And this font is not in system fonts. Also in other cases, including with similar font, I see a difference. I can't say the reason.
Comment 18 Timur 2020-03-20 07:37:38 UTC
(In reply to Xisco Faulí from comment #15)
> As per today, this regression can't be bibisected as it was introduced
> before 4.4 branch and there's no bibisect repository for the affected branch
> for windows, thus change 'bibisectRequest' to 'preBibisect'.

Why Windows, looks like also Lin? I set again bibisectRequest.
Note: didn't test 7.0+.
Comment 19 Buovjaga 2020-06-08 15:18:49 UTC
Bibisect request seems bogus, or else the problem was not seen on Windows ONLY in the past.

I get the same 2-page result with Linux 43all repo, oldest, last35onmaster, last36onmaster, last40onmaster. Also with oldest and latest of 41max repo.
Comment 20 Justin L 2021-03-26 14:13:08 UTC
This entire report sounds bogus to me. You simply can't expect pixel-perfect sizing when you substitute an unknown font for something else. So what is the point of such a report?