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.
Created attachment 152953 [details] PDF-Example
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
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.