Characters are truncated when italic, some respond to character spacing, some do not

[groovimus]

So admittedly jumped the gun and submitted a bug report on this because I would never have thought there is not an automatic calibration in the code to keep this from happening. I submitted an example of u.c. italic characters being chopped off at the top with an adjacent character. The answer was that in my document I should increase the character spacing globally in the document, which is a fix that seems less than elegant. I would prefer to rather increase the spacing in the places where needed, but now I’ve come across a situation where even adjustment of character spacing doesn’t provide a fix and this is where a non-beaking space after an italic u.c. character. In the image below the first line is the editing window with a Ĵ =5/4J with very generous 2 point spacing. The second line is the print preview. So the truncated RHS tops of the 2 'J’s is prominent.

So obviously I could use a solution to this behavior. But in a more general sense, is there no reason that the tool be able to inherently adjust a character display without user intervention? This from my standpoint is an issue and it seems that to fix the issue by the user modifying the character spacing globally. I do not have MS Word installed but I checked Wordpad for this behavior and it doesn’t exhibit it. Uploaded file:
smple italic J truncated.odt (9.5 KB)

as a final note here is the comment I got in the response from my submitting this as a bug:

"A direct format Menu/Format/Character/Position/Spacing – ‘Character spacing’ for the letters following those with the issue is set up to 0 instead 0,4 for the others.

Select all [Ctrl+A], clean the direct format [Ctrl+M] and apply italics, they are good for me."

[EarnestAl]

@groovimus

submitted a bug report

Please link bug report.

I don’t see the effect you describe. Do you have Arial, and Roboto fonts installed?

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-NZ (en_NZ); UI: en-GB
Calc: CL threaded

[groovimus]

OK thx folks for responding. I checked for background in the default page style and there is none. I’ll do the best workarounds possible but that non-breaking space after italic, well I’ll keep trying. Yes Arial installed. now in the bug report I didn’t know about the lack of workaround on the non-braking space. Otherwise the adjusting of character spacing is the only workaround except on the non-braking space. Original bug report: 157249 – Italic style will truncate some characters upper right especially noticeable wih diacritics

[EarnestAl]

I see Arial has issues.

The background is in the Character. Select the text and under Highlight, select No Fill

[ajlittoz]

Your font face specification is faulty. You probably copied the equation from some web page. In HTML, you can specify fallback alternatives in case a font face is not installed on your computer:

Roboto;arial;sans-serif means “use Roboto; if not available, Arial; otherwise, any sans-serif”.

This doesn’t work in Writer where only one font face can be given. Writer understands you request a Roboto;arial;sans-serif which obviously does not exist. It will try to find an installed “compatible” face but I guess it will be in trouble with such a contorted name.

When I replace this nonsensical name with Arial (which is not installed on my Linux computer and will be substituted), everything returns to normal behaviour.

[mikekaganski]

@ajlittoz

This doesn’t work in Writer where only one font face can be given

I was under an impression that this works in Writer (and everywhere in LibreOffice). Do you know how to check this problem?

See yellow-colored text marked Foobar;wingdings;arial; and green-colored one marked Foobar;arial;wingdings - I have both Arial and Wingdings on my system.

[ajlittoz]

@mikekaganski
Many years ago, when I worked in an “heterogeneous” environment (external M$ Word and my LO Writer documents), I thought of solving the cross-formatting issues by using such a specification for the font in my styles. This was a total failure and I reverted to “standard” font naming. I believe the semicolon was causing the problem. I don’t remember exactly; it should have been during the 3.x or 4.y releases era.

In your case, it may work because of a potential pattern matching algorithm (this is wild guess from my part). The complete font name does not exist. It is not in the dictionary of known fonts either (this dictionary is probably used to give hints for substitutions). Thus, I assume that the font substitution module scans the name to look for “similarities” with known names, first match wins.

So, statistically, it can succeed but I won’t rely on it for professional or important documents.

Anyway, the fact that changing the font designation solves the issue shows that font designation is also involved in the bad behaviour (beyond the highlighting).

[mikekaganski]

@ajlittoz

In your case, it may work because of a potential pattern matching algorithm (this is wild guess from my part).

I asked you exactly because I know that it is expected to work by trying the semicolon-separated names, not because of “pattern matching”. It might had been introduced around v.4.something - I have some vague memory… But no, it is not by luck.

And your test of “compare a set of names, none of which are present, vs. one name, which is also absent” doesn’t prove your idea - because it’s exactly the case where the other matching would be involved, after not finding any match directly, and then indeed it might give differences.

[ajlittoz]

Then I offer my apologies to all readers because I never retried after my failures and kept on thinking there was no such feature.

But how comes it worked when I forced a single font name?

[mikekaganski]

Possibly because one of the different substituted fonts had true italics, and another had only generated ones? This might very well have an impact on the font bounds calculations during painting of background…

[ajlittoz]

With the exponential complexity of software (urged by our ever growing expectations), I am always surprised that programs break up working. Text processing is one example with so many layers stacked over each other and interacting non trivially. Have a good day.

[mikekaganski]

You filed tdf#157249; it was in fact a duplicate of tdf#43643 - which is a real bug. It might be possible to improve your text - e.g., remove white background (which causes the problem), but the bug is there, and needs fixing.