Description: When a character that extends below the baseline becomes a drop cap, the bottom of it appears to be cut off in the editor (Occurs often with capital J in some fonts). Exporting to a format like PDF shows the drop cap rendering correctly, so it seems like it’s just a minor visual bug in the program. Steps to Reproduce: 1.Use a font with characters that go below the baseline 2.Begin a paragraph with one of the characters that go below the baseline 3.Format the paragraph to have a drop cap at the start Actual Results: The part of the character which extends below the baseline will not render. Expected Results: The entire character should be visible. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: CL threaded
Created attachment 193442 [details] Sample text beginning with the word John
Hi, Thank you for raising this ticket. Can you please specify the font name to help me verify this issue?
(In reply to Naresh from comment #2) > Hi, Thank you for raising this ticket. Can you please specify the font name > to help me verify this issue? No problem. The font name used in the screenshot is MTBaskervilleETW08-Roman I believe the bug should be reproduceable with any font that contains characters that go below the baseline, though.
Thank you for the update. I tried the same but was not able to reproduce the issue. attaching screenshot. Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-IN (en_IN); UI: en-US Calc: threaded
Created attachment 193561 [details] screenshot
Can you try with a recent version? Maybe even with a daily build as there were fixes recently to just these kinds of issues: Win-x86_64@tb77-TDF from https://dev-builds.libreoffice.org/daily/master/current.html
Are you perhaps using subscript formatting? Then this would be a duplicate of bug 136078, which I still reproduce even with a fresh build.
It seems reproducible (no "subscript formatting"). Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (pl_PL); UI: en-US Calc: threaded
Created attachment 196110 [details] Demonstration: in .odt and in .pdf (Export as PDF)
(In reply to nutka from comment #9) > Created attachment 196110 [details] > Demonstration: in .odt and in .pdf (Export as PDF) Please attach the odt so we can test.
Created attachment 196113 [details] Writer doc for testing
(In reply to nutka from comment #11) > Created attachment 196113 [details] > Writer doc for testing Thanks for the example. Bibisected with linux-64-7.5 to a18a74d6762e56a20093ca51cfd12925697c2524 tdf#150200 tdf#150438 sw, DOCX: fix drop cap dash, quotation etc.
So perceived issue is that the full glyph(s) used for the DropCap are not stamped onto the document canvas as rendered to display, but are printed/exported? The exported PDF does show the drop cap and over height descender for glyphs extending beyond a calculated 3 line against the font 'X' box size. While our Epub export is pretty course and does not, but that is probably best. So is the ask to have the descender extending beyond the drop cap bounding box (as calculated now) *show* as an overstamp on the LO document canvas display? Or the enlarge the calculated bounding box (to a font metric height other than X height) to contain the descender?