Bug 52575 - 0310 COMBINING CANDRABINDU double-rendered in Graphite font
Summary: 0310 COMBINING CANDRABINDU double-rendered in Graphite font
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other All
: high major
Assignee: Not Assigned
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
Reported: 2012-07-27 09:31 UTC by Shriramana Sharma
Modified: 2019-11-08 21:34 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Test material to reproduce and test the bug (114.27 KB, application/x-zip-compressed)
2012-07-27 09:31 UTC, Shriramana Sharma
Results of testing on LibO 4.2 release (164.28 KB, application/zip)
2014-02-03 05:21 UTC, Shriramana Sharma
PDF export in 6.4 nightly (20.22 KB, application/pdf)
2019-11-03 16:26 UTC, eisa01

Note You need to log in before you can comment on or make changes to this bug.
Description Shriramana Sharma 2012-07-27 09:31:39 UTC
Created attachment 64767 [details]
Test material to reproduce and test the bug

Please find attached a ZIP file with requisite test material. I've adapted the Lohit Tamil font (https://fedorahosted.org/lohit/) to Graphite under the name Krishna Tamil. (Note: I removed all OT tables.)

I've included the plain TTF without Graphite tables, the GDL and the compiled Gr-Enabled TTF. Please install the Gr-Enabled font and open the ODT. 

The first page shows many instances of 0BCD TAMIL SIGN VIRAMA applied to various Tamil clusters (whole set of Tamil syllables in fact). The combining mark is programmed to be centered above its base and that it does. 

The next page shows the same text with 0310 COMBINING CANDRABINDU instead. You can see that the candrabindu is duplicated in many cases. It seems that for vowels U and after both as independent vowels and vowel signs (see fifth item onwards per line) the duplication occurs. It also occurs for TTII (fifth row fourth item). 

Curiously, if I break the line before any item with doubled candrabindu, the doubling disappears for the first few items of the newly broken line. Again, sometimes it's three items and sometimes it's four. 

For comparison I've included the output of XeTeX which does not duplicate the candrabindu.

Bug reproducible on LibO 3.5.3 release version on Kubuntu Precise, 3.5.4 on Win XP, and yesterday's daily* of 3.7.0 on Win XP.

* = http://dev-builds.libreoffice.org/daily/Win-x86@6/master/2012-07-26_02.09.47/master~2012-07-26_02.09.47_LibO-Dev_3.7.0.0.alpha0_Win_x86_install_en-US.msi
Comment 1 Joel Madero 2013-01-15 17:50:13 UTC
Confirmed, I think we have quite a few issues with Indian languages as I've seen this with Telugu as well.


Version -, I have confirmed that the problem exists at least to this point, probably indefinitely into the past

New (Confirmed)
Major (prevents entire languages from being used correctly in LibO)
High (default for major)

This bug really makes it so entire populations cannot use LibreOffice efficiently or effectively. Hopefully someone tackles this one

Related: https://bugs.freedesktop.org/show_bug.cgi?id=48303

I closed that one but maybe it should be reopened - need independent confirmation
Comment 2 Shriramana Sharma 2013-10-13 07:49:56 UTC
Bug persists as of LibO installed from DEBs on Kubuntu Precise.
Comment 3 Shriramana Sharma 2014-02-03 05:21:41 UTC
Created attachment 93258 [details]
Results of testing on LibO 4.2 release

I have tested this bug with the recent LibO 4.2 release. The behaviour has somewhat changed. There is no more doubling of the candrabindu as earlier reported. However, the character is being spaced in many cases and disappears in some cases.

It is true that the relevant glyph in the font has a non-zero advance width. However as per native Graphite behaviour as seen via HarfBuzz NG and XeTeX, an attached+positioned glyph should lose any advancewidth it is given in the font -- at least that is what I have understood/assumed so far from the behaviour observed via HBNG/Gr and XeTeX, though whether that is appropriate is open to debate.

So I even tried removing the advancewidth of the candrabindu (i.e. making it zero) but even then the spacing persists.

And even this does not explain why the glyph disappears in some of the cases...

Should the bug summary be updated since the behaviour has changed?

I am somehow guessing that when shaping a text run which involves a Graphite font, LibO is making some assumptions about the spacing, combining or other properties of the characters instead of simply passing the encoded string and the font information to the Graphite library and following the output glyph order and positions. 

In the case of OpenType, perhaps it is necessary for the application calling the shaping library to make such assumptions, but all bets are off when it comes to Graphite since for taking care of minority and unusual orthographic requirements, Graphite font programmers ask for non-standard spacing and other such behaviour. 

So at least when it comes to Gr, LibO should not make any assumptions about character properties and just send in the text plus font info and render as Graphite tells. It would seem that this is what XeTeX does, and we (users of rare orthographies) are happy with that.
Comment 4 Joel Madero 2015-05-02 15:42:59 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2016-09-20 09:36:55 UTC Comment hidden (obsolete)
Comment 6 ⁨خالد حسني⁩ 2016-10-04 19:51:54 UTC
It looks like what is happening here is that Graohite shaping is failing and we are getting fallback shaping. It is not clear if this is a font bug, Graphite bug or LibreOffice bug, some deeper debugging is needed.

It seems bug 89870 does not make any difference here, so I’m dropping the dependency.
Comment 7 QA Administrators 2017-10-23 14:08:09 UTC Comment hidden (obsolete, spam)
Comment 8 eisa01 2019-11-03 16:26:19 UTC
Created attachment 155487 [details]
PDF export in 6.4 nightly

This has greatly improved, the only difference I can see to the Xetex output is the black glyph at the end of the document

Build ID: 80109586e6cb6d3e2e0a53a9079c3125ec9b8368
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 9 ⁨خالد حسني⁩ 2019-11-08 21:34:18 UTC
Resolving per the comment above (the black box is an error in the XeTeX document).