Created attachment 138411 [details]
Initial test scenario
* Create a cell with font "Consolas" and fill-in its content with several lines (10 / 20 in attached test scenario).
* Go to "File" → "Print Preview". Some text in the cell is not visible (cropped).
* Do "File" → "Export as PDF". With similar effect the text is cropped and overlaps with below cell.
Expected: The text is printed as seen on the screen.
This bug seems to be similar to bug #99635.
Created attachment 138412 [details]
Text as seen on the screen with red rectangle showing cropped text
Created attachment 138413 [details]
Sheet1 on print preview with some text cropped
Created attachment 138414 [details]
Sheet2 on print preview with some text cropped and overlapping
Created attachment 138415 [details]
Repro, more or less, even though the font is substituted as I don't have it.
Arch Linux 64-bit
Build ID: c3764c6848bd5ce0bbea2a82bedc3f0d55f01dce
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on December 19th 2017
Arch Linux 64-bit
I do not have that font, but the text is cropped and overlaps.
Tested with version:
- 188.8.131.52 (x64)
- 184.108.40.206.beta2 (x64)
Windows 10 64
Locale: bg-BG (bg_BG)
As a long time user I can say this is a very old bug, and very annoying as it makes the pdf unreadable.
I our case text gets printed on top of outer text. See Screen Shot.
Reason is that text on screen fits in a cell while when printing / creating PDF it doesn't.
It hurts a bit that no developer is even confirming this issue.
Created attachment 147498 [details]
(In reply to Buovjaga from comment #5)
> Repro, more or less, even though the font is substituted as I don't have it.
Please explain. If I substitute Consolas with Liberation or Arial, preview is fine. Which would indicate it's an issue only with this font.
(In reply to Ferry Toth from comment #7)
> I our case text gets printed on top of outer text. See Screen Shot.
Please attach you spreadsheet.
(In reply to Timur from comment #9)
> (In reply to Buovjaga from comment #5)
> > Repro, more or less, even though the font is substituted as I don't have it.
> Please explain. If I substitute Consolas with Liberation or Arial, preview
> is fine. Which would indicate it's an issue only with this font.
I mean the automatic substitution made by LibreOffice. I don't know how to find out what is used as the substitution font.
Now, I don't remember what the situation was in 2017, but now my normal view does NOT match attachment 138412 [details]
My normal view already shows the text "cropped" simply because the row height is too small.
So I'm not sure what to think of this report. Maybe invalid?
Arch Linux 64-bit
Build ID: 146f98e7100ae57ced080c7d9fa028f01df99ca8
CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Built on 20 December 2018
Test Windows 7 with Consolas font present.
Text as seen on the screen with 6.3+ (last one seen "30 json") is not as in attachment 138412 [details] (last one seen "28 unknown").
But "Print Preview" and "Export as PDF" issues still exist.
Title was "Text is cropped because cell height is small on print preview / PDF".
But if we set auto height, still an issue.
I'll change the title to indicate this font.
The problem is not caused by font substitution, is so I would just apply another font that doesn't get substituted.
The problem is caused because looking at the spreadsheet on screen gives a different text width then when doing a print / print preview / safe as pdf.
And because we have automatic text reflow on, the non fitting text flow to the next line. But the row height is not adjusted.
It's a bit nonsensical to ask for a sample spreadsheet. My platform will not have the same text width calculation as yours. I know this because I have Linux, my colleagues have Windows, we all see the same effects but not necessarily in the same cell.
And anyway it's very easy to reproduce.
But just to humor you, I have an example of the opposite too: on screen the row with 'm m m m ..' is wrapped, but in the print preview that is not needed causing an unneeded empty row.
Created attachment 147711 [details]
Example of the same problem but opposite
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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Interesting that MSO also has similar problem in printing this. Repro 7.2+.
Workaround is to add 0,5 cm to row height.
I just found another way to see the effect of the problem: open attachment 138411 [details] and then just zoom in/out (using the mouse scroll for example) – you will see that the contents of the cell gets either larger or smaller than the cell height.