Bug 52575

Summary:	0310 COMBINING CANDRABINDU double-rendered in Graphite font
Product:	LibreOffice	Reporter:	Shriramana Sharma <samjnaa>
Component:	Writer	Assignee:	Not Assigned <libreoffice-bugs>
Status:	NEW ---	QA Contact:
Severity:	major
Priority:	high	CC:	caolanm, jmadero.dev, martin_hosken, mst.fdo
Version:	3.6.2.2 release
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Test material to reproduce and test the bug Results of testing on LibO 4.2 release

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.

Changing:

Version - 3.6.3.2, 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 4.1.1.2 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.