How do I highlight around text, rather than the text itself?

[theoware]

Hi,
I want to have a background colour for a line of text, that excludes the text itself.

In my search for an already open Issue, I found the issue “How do I highlight around the text, rather than the text itself?” (can’t link it since I’m a new user).
I’ve tried the two sample solution documents, but they leave a few ugly pixels around the text (see attachment). What’s even weirder is, that when exported to a PDF, there also appears a line below.

I looked at the file in Inkscape and the issue appears to be, that the white highlighter is a bit too small for the red background.

15747891961790511.odt (5.8 KB)
15747891961790511.pdf (5.2 KB)

OS: Fedora Linux 39 (Workstation Edition) x86_64
How do I highlight around the text, rather than the text itself?
LibreOffice Information:

Version: 7.6.2.1 (X86_64)
Build ID: 60(Build:1)
CPU threads: 12; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: es-ES (de_DE.UTF-8); UI: de-DE
Calc: threaded

Link to original question edited by ajlittoz

[ajlittoz]

What is strange is that your PDF displays as expected here (F39, KDE Plasma desktop while you seem to under Gnome, LO 7.6.2.1) though Okular warns me it found errors in the PDF which may then not be rendered correctly.

Your .odt display with a thin red line above “Heading”, linking the Area painting of the Heading 1 paragraph.

I tried to fool Writer by modifying the implicit character style defined in Heading 1: I added a border without padding. Border is coloured white.

Then it seems there are 2 bugs:

• there is a very thin line at bottom of paragraph, below the border
  This thin line is hardly visible at 600% magnification but is really visible and annoying at common magnification, e.g. 80%.
• a much thicker line a top of paragraph above the border
  This seems to be the same line as in your case, but since I added a thick border, the line was offset the same. The line keeps the same thickness when zoom factor changes.
  
  I think this is a bug of “stick and interval” kind related to the way pixels are accessed. I remember that in the original Inside Macintosh (which is nearly 40 years old now) there was a chapter exposing the mathematical principles of QuickDraw. The coordinate system was not on the pixels but on infinitely thin lines between the pixels. This simplified considerably the issue and avoided many problems like the one you’re facing. There was no confusion between pixel and coordinate.
  
  I am not sure this principle has been followed. At least from what I understand about GTK+ or Qt, this is not the case. Text in LO has its own rendering of which I have no technical knowledge. It looks like there is something like an (accidental?) offset adding its own idiosyncrasy here, though.

See my attempt to fix it in 15747891961790511-ajl.odt (11.3 KB)

Since it can’t be done, I tried to use the bug. In my second attempt, I draw a border around the paragraph and I tweaked the settings to make it look nearly symmetrical. But this looks weird.

Finally I found an acceptable workaround. Instead of requesting center alignment for text, I use tabstops: one in the center with center alignment and one to the right with right alignment. You now type your heading as Tab <the_heading> Tab

CAUTION! Typing an initial tab is very difficult because Heading n creates a list item (even when not numbered) and an initial Tab changes the list level. So type first a character to disable the feature et remove it afterwards.

Now we have some “real” text on both sides of the heading, be it a Tab character, and we can apply a character style to it. I created Highlight Red for that.

Study my patches to Heading 1-3 and the definition of Highlight Red. Adapt to your taste.

[theoware]

Hi,

thanks for the work. Heading 3 looks just like what I wanted, but I’d prefer to have the colour integrated into the templates, since when using the tabs solution you’ll have to manually change the highlighter colour. I will also attach a pdf of your document just in case it looks different on your system.

15747891961790511-ajl.pdf (20.8 KB)

I would also be fine with using alignment to the left in case that helps.

[ajlittoz]

@theoware

I’d prefer to have the colour integrated into the templates, since when using the tabs solution you’ll have to manually change the highlighter colour.

This can be taken care of with an AutoText entry.

@theoware

I would also be fine with using alignment to the left in case that helps.

Describe exactly what you want and I’ll give you a solution.

[theoware]

I’ve edited a PDF export in the way I’d want it to be. That can be achieved by extending the highlighting a bit to all sides.

Edit.pdf (16.0 KB)
Document.odt (6.5 KB)

[ajlittoz]

I do the same trick: I transfer the Area solid colour from paragraph style Heading 1 to a new character style Highlight Level-1. I remove the Area colour and I create a tab stop at right indent of paragraph style Heading 1.

In your document, I press Tab at end of heading and I apply Highlight Level-1 on this tab.

Personally I don’t like the look of these headings. Perhaps starting all colour bars from the same position (requires a second tab stop) would mitigate my impression. Another solution could be to colourise the empty chapter number at left. There you can have a fixed size colour bar and this could improve the look. Experiment. The principle remains the same: use a character style. If you go for a left colour bar, the process can be fully automated because the character style can be configured in Tools>Chapter Numbering (Oh! I see that it is now names Heading Numbering in 7.6).

Revised sample file: Document-ajl.odt (13.2 KB)

I filed bug report tdf#158193

[mikekaganski]

FYI: Version: 7.6.3.1 (X86_64) / LibreOffice Community
Build ID: c4af5b1259bceea6e979e6fe2435dbee7a5a87c2
CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL threaded

shows this for your bug doc in tdf#158193:

and it becomes “a line at the top”, when Skia is enabled.

[LeroyG]

@ajlittoz

sample file

This is what I can see with version 7.5.8.2 on Windows:

[ajlittoz]

Warning! The first heading with deep purple bar is fixed with my workaround using “highlighted tab”. Second and third headings are as posted by @theoware. Fourth heading is a counter-proposal of mine using a character style on the number.

[ajlittoz]

@mikekaganski

FYI: Version: 7.6.3.1 (X86_64) / LibreOffice Community
[…]
shows this for your bug doc in tdf#158193:

OK, then it is dependent on the OS (or rendering engine): line at top under Linux, line at bottom under Windows.

What about the other issue (I know, I should have followed the “one problem, one report” principle) I thought was related: intermediate coloured lines between paragraph lines when leading is added (spacing > 1 line)? This one needs introspection about the extent of highlighting: does it include extra leading or not?

Answer is difficult because some authors would like “glued ribbon” effect, others no.

[theoware]

Thanks, totally forgot this wasn’t a bug report. Thanks for filing it.

Since I’d prefer the original variant I’ll just wait for a fix. But thanks a lot for providing the workarounds.

[koyotak]

I defined only the non-sign area of a row (left side and right side of words) with background colour, so the signs-area has the background colour of the side, and not the white colour.

[ajlittoz]

Is this an answer to the question? If so, explain more clearly your solution and provide an example file for analysis.

[koyotak]

here this is my unusual solution
15747891961790511-ajl_Texte farblich hinterlegt.odt (10.9 KB)
15747891961790511-ajl_Texte farblich hinterlegt.pdf (122.2 KB)

[ajlittoz]

Don’t use answers for what are not answers! You’re confusing visitors. When answering to a comment, use a comment. If you want to add up to some other contribution of your (comment or answer), you can edit it to modify or add.

Basically your solution is the same as mine, i.e. based on character styles.