Coloring individual diacritical marks in LibreOfficeWriter

Hello everybody,

I want to write some biblical Hebrew and I need to color the diacritical marks (vowel signs etc.) in different variants.

I managed to do it to some extent by using the search and replace function of LibreOfficeWriter. The only problem is that everything that’s being colored shifts to the left and that the marks and letters aren’t properly aligned anymore. I added a screenshot to illustrate what I mean.

I tried playing around with the format settings in ‘search and replace’ but haven’t had any success so far. I would be very grateful for a workaround for this problem.

With regards


Unfortunately I’m afraid the solution is only one → run the Draw, Convert the text to Curves, color the diacritical marks and Copy/Paste to Writer as grafical object or SVG :frowning: (for tens or hundreds objects the SVGs are faster)

I solve the same problem but in my work with Quran, and there is possible to put Draw object and Hidden text (Format/ Character-> Font Effects / Hidden) behind this graphical object, because Hidden text isn’t visible, but it is highlighted (at least a little bit) for Ctrl+F or Ctrl+H.

Interestingly enough, while searching for an answer on google, I found a website which explains how to color the Arab marks. It says that the misalignment can be solved by changing the font size but, at least for Hebrew, it doesn’t work. Italso links a LibreOffice extension for directly coloring tashkeel but there seems to be no such thing for Hebrew.

See here:

Your workaround is helpful though. It doesn’t matter to me if the letters are ‘real’ or just graphical objects as long as they look good.

Thank you!

In link you gave, it only seems it is possible to color arabic marks, but it isn’t true. It is only no-well-tested example with the fortune of firstly used font and OS substitutions for fonts :-).
LibreOffice hasn’t rendering to render different formatted marks well. I knew only Firefox had rendering for different formatted arabic marks, but I tested it about before 7 years.

Here is comparison of images from the link, there is used font DejaVu Sans in both images, instead Minion Pro declared in 1st image. So it seems the Minion Pro hadn’t arabic letters and OS did automatical font substitutions to DejaVu Sans. And I added thin orange lines to see the shift of marks.

And example how the macro from link colors some other fonts :-). It could be sufficient with some fonts in some dilletante-thinks-he’s-an-expert design, but really it isn’t able for precision work :-).

And example of my work with Quran.

See my answer. It works with any diacritics in any language. In addition it is perfectly integrated with LO (or rather with any font renderer) and does not cause offset in diacritics position.

I avidly tried it, but there is the same problem like when I set colors to marks with direct formatting. The marks are strewn, less for some fonts, even more for other fonts. And ligatures are canceled. I also used Alt+RightArrow and Shift+LeftArrow to select the marks.
Moves of cursor via Alt+Arrow described in ODT is for settings: Tools/ Options/ Language Settings/ Complex Text Layout/ Cursor Control → Visual
arabic-marks.odt (31.8 kB)


With the accent set to 9 pt (letter in 12 pt):

Letter and accent should have the same font size so that the composition algorithm positions the glyphs correctly. Otherwise I don’t know what happens. Is there some scaling to get equal sizes? This may effectively offset the accent. How combining glyphs are positioned is described in the font and supposes that the diacritic comes from the same font and has the same size.

The anchor point is defined independently from the specific diacritics. There are “top center”, bottom center", “top left”, “top right” and other anchors. They are not optimised compared to a pre-composed character. Some imperfect aesthetics should be expected.

IMHO, the “à” example is ill-chosen and I avoided it just like all other pre-composed accented letters in Latin-1 block. The sequence U+0061 U+0301 is illegal in Unicode (it is an overlong encoding) because there exists U+00E1 (in principle conforming applications must convert the overlong encoding into the shorter encoding; but then it becomes impossible to decorate the accent separately from the base letter). Consequently, there may be differences between the pre-composed “à” and the combination of “a” and grave accent.

1 Like

The solution is a bit tricky.

First create a character style to group the highlighting attributes. For example, call it VowelMark and set font colour to Red in Font Effects tab.

All is then needed is to create the correct Unicode sequence letter+diacritics:

  1. type your consonant as usual
  2. type the diacritic encoding in hexadecimal, e.g. 5b6 for segol (see this Wikipedia page for Hebrew diacritics encoding if you don’t know them)
  3. select the hexadecimal encoding and apply your character style (VowelMark in the example above)
  4. without deselecting (or with the cursor at the immediate right of the encoding), press Alt+X

The last step turns the encoding into a glyph (the diacritic mark) and since it is formatted it keeps its formatting during the operation. The formatting can be different from the one on the consonant (just apply a different character style or rely on the paragraph style).

If you have several diacritics on the same consonant, each one can have a different colour (=character style) if you wish so.


You can’t select a diacritic by itself. It is a combining mark, it needs a base character to be visible. The only way to select a diacritic is to make it behave like a non-diacritic. Therefore I enter it using its hexadecimal encoding onto which I apply the formatting I want. Once the hexadecimal string has received its formatting, I turn it into a real diacritic (with Alt+X) and it combines with its base character as expected.

Even if the diacritics is available from your keyboard, don’t enter it with its key. The keyboard is managed by the OS. The OS expects combining “accents” in reverse order compared to Unicode sequences, i.e. diacritics first followed by base character. This will not allow you to “decorate” your diacritics. Once the key is pressed, keyboard is in a special state (called “dead key”) where nothing is displayed on screen (or some special clue) waiting for the next key press. And the keyboard manager will filter combinations it does not know. Consequently you can’t really create any character+combining diacritics which is allowed by Unicode semantics, even if this combination does not exist in any language.

1 Like