I just received notification of this being moved from medium to high priority.

Yeeeehaaaa!!!

(Thanks)

:-)

(In reply to comment #1)
> Yeeeehaaaa!!!
> 
Well, it still needs someone volunteering to work on it.

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.

(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.

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?

I have tested with 4.0 final on OS X and Windows 7, and I cannot reproduce the bug (anymore).

(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.

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).

(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

Would such an implementation be the first step on the road to implementing advanced OpenType features such as those described in bug 58941?

(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.

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.

GPOS kerning is supported on Linux and Mac already, marking it a Windows issue.

(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

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.

(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.

(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 feel concerned if providing different way of operating OT and Graphite features will cause some inconvenient.

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).

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.

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.

(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.

On LO 5.5.1 on Windows 10, the GPOS kerning seems closed. What does developers do?

I think you mean 5.1.5
did you try 5.2.1? is the behaviour different?

It seems work with LibreOfficeDev 5.3, see attachment 128422 [details].

nice to hear that.
status -> RESOLVED WORKSFORME

(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).

(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.

may we definitively label this as RESOLVED FIXED?