Description: Using the Akira font from Ikiiko Type, I find that some letters (easiest to see on the letter j) if it's the first letter in the word on a line, will be drawn beyond the margins instead of the letter being moved further to the right. It doesn't happen in other word processors, so I'm guessing it isn't an error within the font itself? I don't know how I'd even check something like that. Here's a screenshot of a fresh document, font set to Akira, wrote some text at default 12 point size, then highlighted it all. You can see how the 'j', 'J', and 'A' draw slightly outside the margin. It will render this way when exporting to PDF, so it isn't simple a display issue. https://puu.sh/JBCnI/84857492bb.png It also happens with right justified text, such as on the 't' and 'n': http://puu.sh/JBCpg/22bdbbd6fd.png Steps to Reproduce: 1. Write some words in Akira font 2. Certain letters, such as J and j, will draw outside the left margin Actual Results: Leftmost letters, such as those listed, draw beyond the margin. Expected Results: The lines should have been moved far enough to the right so that nothing is drawn outside the margin. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 185958 [details] Screenshot showing left justified text outside the margin
Created attachment 185959 [details] Screenshot showing right justified text outside the margin
I don't own the font. But that and similar would be font metric issue where the swashes extend beyond em space by design. I believe it is expected.
I'm no expert on any of this, just an end user, but if the font is designed intentionally to let parts of letters overlap other letters (which it is I'm sure because of how this font works), that still shouldn't let it exceed the edges of the margin through, right? I assumed the margin would be the final authority on where a font is allowed to draw onto.
I think swash decoration extending beyond Paragraph, Cell, and draw Text object margins is the expected/desired behavior. IIUC for normal fonts the swash would be an alternate via gsub/salt lookup. But that would not change the font metric as here when the glyph strokes extend into -X values before the 0 edge.
If the glyph shapes go outside their advance widths, then there is no bug here, the font is being rendered as intended. You can double check with virtually any other application.
For me, it is a visibility bug. The presentation of the text in the text box is not optimal.
Sorry, it is a misunderstanding of mine. I think, it is not a problem if the text is outside the margin of the highlight, but it is one if the text is outside the margin of a text box.
Created attachment 185997 [details] Margin Border Example
That is how the font is designed, it might not look good for your case, but it is still not something that we want to address. Glyphs have advance widths, these control how much a glyph advances the line and then in turn controls line breaking decisions. The glyph shape is irrelevant and is never consulted for these decision. To get a uniform margin we can either: 1) clip the glyphs at the margin, but it will look worse than it is now and more people will complain 2) Use the glyph bounding box instead of the glyph advance at line breaks: this is not easy as it seems since it meant the glyph will have different advance width based on whether it is at the line margins or in the middle, and it would also be a breaking change as it can result in different line breaking than previous versions of LibreOffice and other office suites. 3) Align the glyphs at the margins without changing their advance widths: the change in width needs to get from somewhere, so we will need to alter letterspace to account for the difference, which will look worse and more people will complain. I also don’t know any other software package that does any of this, probably for good reasons.
I did the highlight to try and make it more visible what is happening, but you can see the page margin marker at the top of my screenshot. That's the left margin of the page from Format -> Page Style -> Page. I left it the default for this example. I've uploaded another example where I didn't highlight the text but I did turn on a border along the margins of the page, that also shows the overlap. Since you mentioned a text box, I drew one in the middle of the page and wrote some big text in the box. Clicking in the box highlights the edges of the box by default, so I took a screenshot. You can see it drawing outside the textbox as well. The reason I noticed this and reported it as a bug is because I've been using Libre Writer to publish a book on Amazon's KDP platform. When you upload your document as a PDF, it does some automatic error checking. Since I was using "no bleed", one thing it checks is that nothing is drawn outside the page margins at all. However I had numerous spots where my font was drawing slightly off the left or right edges of the pages into the page margin, thus causing errors I had to resolve before I could get KDP to give it a pass. My solution was to increase the page margins in my document to the point I no longer went outside the required minimum margins.
Created attachment 185998 [details] Text box example
(In reply to خالد حسني from comment #10) > That is how the font is designed, it might not look good for your case, but > it is still not something that we want to address. If things are working as intended that's fine, I'll just know for the future when using unusual fonts to make my page margins wider (to not exceed the actual intended real margin), or perhaps do my book interiors in the future "with bleed" instead of "with no bleed", then KDP might not enforce the margin rules anyway.
(In reply to Jonathan Roy from comment #13) > If things are working as intended that's fine, I'll just know for the future > when using unusual fonts to make my page margins wider (to not exceed the > actual intended real margin), or perhaps do my book interiors in the future > "with bleed" instead of "with no bleed", then KDP might not enforce the > margin rules anyway. I'll defer to Khaled as to "working as intended". So => NAB But maybe have a look at 'Page style...' and its Borders tab, where you can add "padding" when desired to offset/reposition for use of a decorative Script font like this. Likewise for draw text boxes and draw shapes via 'Text attributes...' where the Text tab Spacing to Borders values allow you to adjust "padding" for fonts with overwide or overhigh glyph strokes. Additionally just [1] for the sd Draw and Impress modules working with draw shapes you can assign/modify the same via the Text Graphics styles. =-ref-= [1] see bug 89369 for request to implement for Writer and Calc