Ask Your Question
1

Writer automatically draws random black boxes after some words

asked 2016-02-23 12:36:40 +0100

rebar gravatar image

updated 2016-03-07 21:43:49 +0100

Alex Kemp gravatar image

You can't select them or delete them. At first, I thought it was a weird autocorrect thing, but turning it off didn't fix it. Any idea what to do with this? Thanks in advance.

P.S. I'm typing in Georgian script. This does not happen in any other script, including Latin.

image description

EDIT:

Hi, sorry for the late reply. Here's some info about my LO: Version: 5.0.3.2 (x64)
Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75
Locale: ka-GE (ka_GE)

I am currently running Windows 10 Home x64.

I attached the test .odt file here -> test.odt

edit retag flag offensive close merge delete

Comments

Can you select a text range that includes one of these characters and paste it in the question? Alternatively upload a sample document somewhere and link it here for others to test. My guess is that it may be a grammatical combining character.

oweng gravatar imageoweng ( 2016-02-25 13:22:57 +0100 )edit

@rebar: Also give the version of LibO and your OS, please.

Lupp gravatar imageLupp ( 2016-02-26 12:06:44 +0100 )edit

2 Answers

Sort by » oldest newest most voted
0

answered 2016-02-26 10:04:32 +0100

oweng gravatar image

updated 2016-02-26 10:15:20 +0100

Thanks for providing the additional detail. It may be a limitation in the encoding in the Liberation Serif for the Unicode range containing Georgian. The empty rectangles do look like a placeholder character for an unencoded code point. Examining the copy of Liberation Serif (v2.00.1) provided with v5.1.1.1 indicates these missing code points:

  • U+10c7 through U+10cf
  • U+10fd through U+10ff

There is a mismatch between these uncoded characters and that specified in the Unicode v8.0 chart for Georgian which has blanks in:

  • U+10c6
  • U+10c8 through U+10cc
  • U+10ce through U+10cf

Perhaps the problem relates to this mismatch? The fact that you cannot select the rectangles is strange though as generally even an unencoded character is still selectable. This is why I though it may be an automatically inserted grammatical addition, such as a space or word joiner (which is still a possibility, given it appears to only be occurring in LO).

edit flag offensive delete link more

Comments

Based on the new example posted as a piece of code and also linked in as an image of a 'Writer' view I would guess the boxes to be malformed "pilcrow" glyphs as used to indicate the break between paragraphs. In this case It should vanish as soon as 'Tools' > 'LibreOffice Writer' > 'Formatting Aids' >'Display of Paragraph end' is switched off.

Lupp gravatar imageLupp ( 2016-02-26 11:58:21 +0100 )edit

Regrettably this does not explain the first occurrence in the original example. There may, however, another case of 'Formatting Aid' be the background.
Again we find: Only the real thing (an attached .odt file in this case) is actually helpful. Images are not (or much less at least). I will "enkarmatise" @rebar sufficiently therefore.
Another hint: Clarifications an additional examples might better be appended to the OQ by editing.

Lupp gravatar imageLupp ( 2016-02-26 12:02:52 +0100 )edit

Hi. I have everything switched off both in writing aids and formatting aids, so that's definitely not it.

rebar gravatar imagerebar ( 2016-02-28 00:22:55 +0100 )edit
0

answered 2016-02-28 12:05:08 +0100

Lupp gravatar image

updated 2016-02-28 12:15:58 +0100

The "black boxes" look like placeholders as used for U-codepoints the specific glyph for is missing.
In fact they do not represent any character or codepoint, not even a not visible one. They are random artefacts caused by some "accident" during rendering next to a break in textflow.
The attached example is containing three specimens, two of them preceding a hard linebreak, the third and last one preceding the paragraph end. In all three of these examples the "black box" vanishes as soon as I insert an ordinary space between the last shown (Georgian) letter and the non-printable break. It also often disappears if I insert an additional space, some other whitespace or even a zero width space (U+200B) elsewhere in the line concerned.
Thus I would judge we view consequences of a strange error (bug) related to calculations concerning the metrics of lines during rendering. On my system the bad display is also viewed in print preview, but does not actually print. (LibO V5.1.0, Win 8.1, Kyocera FS-1030D with KX driver)
(Tried also with Apache OO 4.1.2. It spoilt the text completely. Rendering Georgian writing seems to be a difficult task. As I do not know anything about the implementation of metrics in fonts, I cannot help any further. Either the OP or someone knowing a bit more should file a bug report concerning the issue.

Editing: I also copied the Georgian text posted in the self-answer of @rebar into a virgin 'Writer' document, eliminated the textflow marks and replaced them with 'Writer' standard. This way I also got the bad view. It seems to be fully reproducible.

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2016-02-23 12:36:40 +0100

Seen: 646 times

Last updated: Feb 28 '16