Bug 46055 - support GPOS kerning
Summary: support GPOS kerning
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other Windows (All)
: medium enhancement
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: BSA target:5.3.0
Keywords:
Depends on: HarfBuzz
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2012-02-14 10:42 UTC by Dont Bother
Modified: 2016-11-06 18:39 UTC (History)
21 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot that shows missing GPOS kerning (31.80 KB, image/png)
2013-04-06 11:13 UTC, Georg Duffner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dont Bother 2012-02-14 10:42:55 UTC
Please support GPOS kerning as described here:

http://www.linuxlibertine.org/index.php?id=87&L=1

              
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Comment 1 Dont Bother 2012-05-04 08:58:48 UTC
I just received notification of this being moved from medium to high priority.

Yeeeehaaaa!!!

(Thanks)

:-)
Comment 2 Thorsten Behrens (CIB) 2012-05-04 12:31:53 UTC
(In reply to comment #1)
> Yeeeehaaaa!!!
> 
Well, it still needs someone volunteering to work on it.
Comment 3 Peer Heinlein 2012-05-16 02:01:29 UTC
We'd really appreciate working on this BIG problem.

Some commercial fonts are in otf-format available only. Our new standard-CD font Interstate is one example for that. We suddenly realized, that we aren't able to work with OO/LibreOffice, because OTF-Kerning-support is missing.

What should we do?

Change our CD and our standard-font (after one year working on it)?

No, we won't. The better (and easier) way would be: Change our writer software. So -- back to MS word? I'd dislike that. But what should I do?

So: OTF is the most modern standard font file format. Missing OTF-support is a real missing feature for OO/LibreOffice, makes it unusable in professional enviroments.
Comment 4 k-j 2012-05-17 23:09:10 UTC
(In reply to comment #2)
> Well, it still needs someone volunteering to work on it.

Can you describe what kind of volunteering you need. So maybe someone can do this or we can ask on the lists.
Comment 5 Maxim Iorsh 2013-01-19 09:33:23 UTC
Back in 2011, Khaled Hosny introduced a patch which fixed Arabic GPOS kerning (and Hebrew too on the way) for bug 31016. What happened since then? Was there some major change in underlying rendering engine?
Comment 6 Florian Effenberger 2013-02-18 12:16:04 UTC
I have tested with 4.0 final on OS X and Windows 7, and I cannot reproduce the bug (anymore).
Comment 7 Georg Duffner 2013-04-06 11:01:06 UTC
(In reply to comment #6)
> I have tested with 4.0 final on OS X and Windows 7, and I cannot reproduce
> the bug (anymore).

I can still reproduce this with 4.0.1.2 on Arch Linux.
Comment 8 Georg Duffner 2013-04-06 11:13:06 UTC
Created attachment 77520 [details]
Screenshot that shows missing GPOS kerning

This demonstrates missing support for GPOS kerning. Left is LO Writer (v. 4.0.1.2 on Arch Linux), right is a PDF (produced with XeLaTeX).
The fonts used are EB Garamond (top) and Linux Libertine (bottom).
Comment 9 Christian Herzberg 2013-04-28 17:18:24 UTC
(in reply to comment #4)
> Can you describe what kind of volunteering you need. So maybe
> someone can do this or we can ask on the lists.

I asked Phillip from Linux libertine about what someone could do to get GPOS-Kerning works in LibreOffice:

* implement the OpenType [1] specification [2] von Adobe and MS for "glyph positioning" (GPOS) Kerning Feature

[1] http://en.wikipedia.org/wiki/OpenType
[2] http://www.microsoft.com/typography/otspec/default.htm

It seems a good idea to work on the following at the same time
* implement "glyph substitution" (GSUB)
* implement more features from the specs
* do programming on the kerning-maschine in LibreOffice

The Pango developers implement some of this features to complete the l18n for all systems of fonts. May be some things that are not LibreOffice specific could flow together to help other projects like Scribus or Pango (an open source multilingual text rendering engine). May be we don't have to do all things twice.

Thanks a lot for all efforts
Comment 10 Linus Drumbler 2013-05-17 19:49:17 UTC
Would such an implementation be the first step on the road to implementing advanced OpenType features such as those described in bug 58941?
Comment 11 Christian Herzberg 2013-05-19 12:37:19 UTC
(In reply to comment #10)
> Would such an implementation be the first step on the road to implementing
> advanced OpenType features such as those described in bug 58941?

This bug report covers GPOS kerning. The lack of this make some professional fonts unusable with libreoffice like Linux Libertine. 

It's seems like the difference between the following commands to identify the abilities of a font
otfinfo --tables [path to font]
otfinfo --features [path to font]

So it may be a first step on the road. And implementing the whole OpenType standard would fix both.
Comment 12 stuttgarter 2013-07-23 09:17:07 UTC
Perhaps a workaround until the problem is solved.

Before printing choose the printer properties in the LO print dialog.
Then you click on device and there change the Printer Language type from PDF to PostScript.

And the output will be good as required.
Comment 13 Khaled Hosny 2015-11-07 05:13:20 UTC
GPOS kerning is supported on Linux and Mac already, marking it a Windows issue.
Comment 14 Volga 2015-11-07 05:25:37 UTC
(In reply to Khaled Hosny from comment #13)
> GPOS kerning is supported on Linux and Mac already, marking it a Windows
> issue.

It seems to me that this kerning works in LO 5.0.3 for Windows, but no way of turning off as <font name>:kern=0
Comment 15 Khaled Hosny 2015-11-07 05:29:03 UTC
The non-standard <fontname>:<tag>=<value> syntax has never been supported outside the Graphite layout code, and it is basically a non-portable hack to work around lack of font feature handling in ODF.
Comment 16 Volga 2015-11-07 09:32:32 UTC
(In reply to Khaled Hosny from comment #15)
> The non-standard <fontname>:<tag>=<value> syntax has never been supported
> outside the Graphite layout code, and it is basically a non-portable hack to
> work around lack of font feature handling in ODF.

I feel this syntax can be expand to OT layout if OT feature handling is implemented.
Comment 17 Khaled Hosny 2015-11-07 10:29:31 UTC
(In reply to General Kutuzov from comment #16)
> (In reply to Khaled Hosny from comment #15)
> > The non-standard <fontname>:<tag>=<value> syntax has never been supported
> > outside the Graphite layout code, and it is basically a non-portable hack to
> > work around lack of font feature handling in ODF.
> 
> I feel this syntax can be expand to OT layout if OT feature handling is
> implemented.

That would be the wrong approach IMO as it is non-standard and will not work in other ODF implementations. The proper approach would to extend ODF to support font features (OOXML already does), may be first as a LibreOffice extension then propose it for standardisation.
Comment 18 Volga 2015-11-07 13:05:45 UTC
I feel concerned if providing different way of operating OT and Graphite features will cause some inconvenient.
Comment 19 Khaled Hosny 2015-11-07 18:27:16 UTC
Graphite layout can always be “upgraded” to the new model, with the old syntax kept for backward compatibility (or even parsed at document load, but saved in the new form).
Comment 20 Volga 2015-11-08 07:18:44 UTC
Using this syntax to control Graphite feature in LO is well known, but introduce another operations for OT feature if you have abality to control OT feature in LO in the future may will pay more works on it, maybe also affect the user experience.
Comment 21 Volga 2015-11-08 07:32:21 UTC
The CSS property “font-feature-setting” is intended to setting the OT feature initially, but in Firefox this property is also used for Graphite feature.
Comment 22 Volga 2015-11-08 08:27:50 UTC
(In reply to Khaled Hosny from comment #17)
> (In reply to General Kutuzov from comment #16)
> > (In reply to Khaled Hosny from comment #15)
> > > The non-standard <fontname>:<tag>=<value> syntax has never been supported
> > > outside the Graphite layout code, and it is basically a non-portable hack to
> > > work around lack of font feature handling in ODF.
> > 
> > I feel this syntax can be expand to OT layout if OT feature handling is
> > implemented.
> 
> That would be the wrong approach IMO as it is non-standard and will not work
> in other ODF implementations. The proper approach would to extend ODF to
> support font features (OOXML already does), may be first as a LibreOffice
> extension then propose it for standardisation.

I have an new idea of turning GPOS kerning on or off, you can try to adding an check box in the “Character” dialog to let user change, see bug 58941.
Comment 23 Volga 2016-03-10 19:30:43 UTC
On LO 5.5.1 on Windows 10, the GPOS kerning seems closed. What does developers do?
Comment 24 tommy27 2016-10-13 04:13:37 UTC
I think you mean 5.1.5
did you try 5.2.1? is the behaviour different?
Comment 25 Volga 2016-11-02 04:22:54 UTC
It seems work with LibreOfficeDev 5.3, see attachment 128422 [details].
Comment 26 tommy27 2016-11-02 05:45:28 UTC
nice to hear that.
status -> RESOLVED WORKSFORME
Comment 27 Khaled Hosny 2016-11-02 09:51:29 UTC
(In reply to tommy27 from comment #26)
> nice to hear that.
> status -> RESOLVED WORKSFORME

The new layout engine is not enabled by default yet (and when enabled it should be FIXED not WORKSFORME).
Comment 28 Volga 2016-11-04 03:28:02 UTC
(In reply to Khaled Hosny from comment #27)
> (In reply to tommy27 from comment #26)
> > nice to hear that.
> > status -> RESOLVED WORKSFORME
> 
> The new layout engine is not enabled by default yet (and when enabled it
> should be FIXED not WORKSFORME).

Now tne new layout engine is enabled by default, so you can rest assured.
Comment 29 tommy27 2016-11-04 08:03:39 UTC
may we definitively label this as RESOLVED FIXED?