Bug 126514 - LINE SPACING: Diacritics in fonts are displayed cropped but printed uncropped
Summary: LINE SPACING: Diacritics in fonts are displayed cropped but printed uncropped
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Paragraph-Line-Spacing Diacritics
  Show dependency treegraph
 
Reported: 2019-07-23 08:25 UTC by canned
Modified: 2024-05-24 14:10 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example (11.73 KB, application/vnd.oasis.opendocument.text)
2019-07-23 08:25 UTC, canned
Details
PDF-Example (11.42 KB, application/pdf)
2019-07-23 08:25 UTC, canned
Details

Note You need to log in before you can comment on or make changes to this bug.
Description canned 2019-07-23 08:25:00 UTC
Created attachment 152952 [details]
Example

Paragraph style with font size 30pt and line spacing 30pt -> The dots in German letters Ü, Ö, Ä... are displayed cropped, also in the print preview. When I print the document however, the dots are output uncropped. It is irritating that one sees something else on the monitor than printed on the paper.
Comment 1 canned 2019-07-23 08:25:23 UTC
Created attachment 152953 [details]
PDF-Example
Comment 2 Dieter 2019-07-28 07:50:02 UTC
I confirm it with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 8f98a7c4e5b1f0b249c026577805a378b8a533d5
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-23_00:30:19
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

Same with other line spacing values => I changed bug summary to a more general topic
Comment 3 V Stuart Foote 2019-07-28 14:23:30 UTC
Easily demonstrated by selecting the paragraph(s) to show its bounding box--the 30pt spacing is cropped, while the "single" (or 100% proportional) spacing is drawn directly from font metrics--including the correct internal 'leading' of the font. Ascenders and descenders fit the within the "single" line height--while 30pt line height is insufficient to hold a 30pt font size.

On screen, the VCL layout of document canvas is correctly cropping the font masked to the line height. While Print preview simply builds a bitmap from VCL that shows the cropping.

But when actually printing: for formats that embed the glyphs (PDF, XPS, PRN) export stamps the glyphs according to the scaling applied by the 30pt line height.
Not will export/print crop them to constrained paragraph (or sections) bounds, not clear if any implemented export or printing routine could crop/mask the text runs.

If there is an issue, it is with clipping mask(s) for PDF export and print. We know we have issues with our poppler based PDF importing, e.g. bug 86211

But this 'quirk' was inherited from OOo, not clear it use case merits the work it would take for printing/export (PDF Epub) to fix it.