Issue 16032 - OOo should support optional OpenType features
Summary: OOo should support optional OpenType features
Status: ACCEPTED
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.0
Hardware: All All
: P3 Trivial with 216 votes (vote)
Target Milestone: not determined
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: oooqa
: 32869 (view as issue list)
Depends on: 43029
Blocks: 112466
  Show dependency tree
 
Reported: 2003-06-24 20:32 UTC by dgrant
Modified: 2015-05-18 16:03 UTC (History)
41 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Russian versus Serbian glyphs (25.07 KB, application/pdf)
2011-02-17 11:10 UTC, aleces
no flags Details
A sample file to try a ligatured font (11.83 KB, application/vnd.oasis.opendocument.text)
2015-05-17 19:29 UTC, JC Ahangama
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description dgrant 2003-06-24 20:32:58 UTC
OpenOffice should support opentype fonts if it doesn't already.  I haven't found
anything to lead me to believe that it does support it.  It looks like freetype2
does support it though.
Comment 1 mci 2003-10-22 12:04:37 UTC
set type to enhancement
reassigned to bh
Comment 2 hdu@apache.org 2003-10-22 12:56:31 UTC
HDU->David: Which OT features exactly are you looking for? 
 
We support OpenType fonts if platform specific layout engines support their 
features. We don't support all of the ever evolving OT spec like stylilistic 
alternates yet. 
 
Freetype targets in a different abstraction layer, it has little to do with 
OpenType layout. 
Comment 3 fa 2004-06-02 17:55:47 UTC
hdu: Can OOo on Linux load and show .otf files in the fonts menu yet?  What is
needed to support OpenType and what is the amount of work to do so?
Comment 4 silverex 2004-06-02 20:04:31 UTC
OpenOffice (1.1.1) supports OpenType fonts with TrueType outlines (*.ttf ones,
like recent Times New Roman versions), but doesn't support OpenType fonts with
PostScript outlines (*.otf).

I've filed a bug in RedHat's bugzilla a bit about lack of *.otf support
recently, it has more details:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125088

Also, there is more to OpenType than basic support, like discretionary ligatures
and swash glyphs. It would be very nice if OO.o supported them. All of them are
explained very nicely at http://www.adobe.com/type/opentype in simple words and
screenshots.

P.S. This doesn't apply to "Word processor" only, maybe "Component" field value
should be changed to ui or some more suitable one.
Comment 5 ralphie 2004-12-03 10:28:56 UTC
*** Issue 16032 has been confirmed by votes. ***
Comment 6 ralphie 2005-01-03 18:31:10 UTC
I think 32869 is more or less a duplicate of this bug.

As I wrote in IZ #32869 this is becoming more and more important, as Adobe is
going to stop selling Type1 fonts soon, leaving OTF as the only format to
buy new fonts in. Also all other major foundries are converting to OpenType.
Comment 7 lohmaier 2005-01-07 19:09:12 UTC
*** Issue 32869 has been marked as a duplicate of this issue. ***
Comment 8 ousia 2005-02-18 19:46:28 UTC
Will be OpenType fonts (with PostScript outlines) recognized in versions
previous to 2.0? (For some reason this has been already achieved in Windows but
not in Linux.)

Comment 9 ousia 2005-02-18 19:47:09 UTC
Will be OpenType fonts (with PostScript outlines) recognized in versions
previous to 2.0? (For some reason this has been already achieved in Windows but
not in Linux.)

Comment 10 akrioukov 2005-03-24 14:26:37 UTC
I think, this issue deals with 2 different problems, which should be treated
separately. So may be it was wrong solution to mark 32869 as a duplicate of this.

First, OOo needs support for OpenType-specific features, available both in Open
TrueType fonts and OpenType fonts with PostScript oultlines, no matter, whatever
their font file extension is (*.ttf or *.otf). I understand this task requires a
large amount of work, bot sometime this needs to be implemented.

Second, it should be possible to install OTF fonts (i. e. OpenType with
PostScript outlines) with spadmin, and OOo should be able to access OTF fonts
already installed system-wide. This problem has nothing to do with OpenType
specific features: it is just about the same level of support, which already
exists for other font formats (Type 1 or TTF). 

I think, the second task may be resolved easily, since OTF fonts are already
supported by freetype. Moreover, there are strong reasons for which it should be
resolved immediately. It's a shame, but OOo seems to be the ONLY serious X11
application, which still knows nothing about this font format, since all other
applications also use freetype and take advantage of its capacities. In fact,
the absence of OTF support in OOo is the only reason which prevents some free
font developers from publishing their works in this format, even if it may be
more convenient than ttf.
Comment 11 ousia 2005-03-25 02:23:53 UTC
I agree with Alexej: OT with PS outlines should be recognized in Linux before
version 2.0 appears, since FreeType handles these fonts right.
Comment 12 arthit 2005-05-17 10:09:42 UTC
change
Platform -> All
OS -> Unix, X11
Version -> OOo 2.0
Target milestone -> not determined

Component -> gsl ?
Comment 13 nospam4obr 2005-09-01 12:44:25 UTC
obr @ hdu: can you comment on this issue - doesn't OOo 2.0 support fontconfig ? 
Comment 14 silverex 2005-09-01 13:08:06 UTC
obr: no, it does not. See #46020.
Comment 15 philipp.lohmann 2005-09-01 13:12:08 UTC
pl->obr: yes it does, but fontconfig has nothing at all to do with whether we
can use OpenType fonts or not. See indeed issue 4602.
Comment 16 moyogo 2005-10-27 08:25:12 UTC
There is an OpenType TTF font that has OpenType features for Latin script. If
you want to do tests with it.
The GPLed font is here
http://home.sus.mcgill.ca/~moyogo/lingala/fonts/Junicode-Regular.ttf

The output with a patched Pango is here
http://bugzilla.gnome.org/attachment.cgi?id=53890&action=view
With this file http://home.sus.mcgill.ca/~moyogo/lingala/fonts/text.utf8 or that
one http://bugzilla.gnome.org/attachment.cgi?id=32984&action=view .

I wasn't able to reproduce this with the OOo2 I have by default on Ubuntu. 
The OpenType features kern, mkmk, mark for GPOS and ccmp, liga and clig are
required for IPA but more importantly for languages that must use precomposed
characters with diacritics.
Comment 17 hdu@apache.org 2005-10-27 08:52:40 UTC
Thanks for the pointer to this very nice unicode font. OOo supports Opentype
fonts already, but for Latin OpenType features this support is still incomplete
on both Win and Unx platforms even for the required features.
Comment 18 moyogo 2005-10-27 15:01:23 UTC
Is it VCL that handle OpenType features? Where can I look at code for working
Opentype features? Where is the Latin script handled?
Comment 19 hdu@apache.org 2005-10-28 07:48:40 UTC
> Is it VCL that handle OpenType features?

Yes and No. VCL is the "glue" to the system's layout engines, i.e. ICU on UNX,
USP on WIN and ATSUI on MAC.

> Where can I look at code for working Opentype features?

For WIN platforms it is in vcl/win/source/gdi/winlayout.cxx
For UNX platforms it is in vcl/source/glyphs/gcach_layout.cxx

Where is the Latin script handled?

For WIN platforms it is in the class SimpleWinLayout.
For UNX platforms it is in the class ServerFontLayoutEngine.

You probably want to redirect the handling of Latin OpenType to the classes
UniscribeLayout and ICULayoutEngine. The easiest way to do this is to remove the
optimization in ImplLayout in vcl/source/gdi/outdev3.cxx with the comment "//
disable CTL for non-CTL text".

Good Luck!
Comment 20 meneteqel 2006-02-11 09:54:42 UTC
I am a little bit uneasy with this issue because it handles two clearly 
distinct issues under the same heading: 
 
(1) OOo should support OpenType features like ligatures, diacritics, small 
caps etc. This would be an ENHANCEMENT to OpenOffice.org, and a very nice 
indeed. 
 
(2) OOo doesn't recognize OpenType fonts with PS outlines under linux. This is 
clearly a BUG (as other applications as e.g. KOffice can handle these fonts), 
and a very annoying one as more and more fonts are published in this format. 
 
I propose to split this issue in two distinct issues and that the secon issue 
(failure to render otf-fonts) is declared as BUG. 
 
Comment 21 meneteqel 2006-02-11 09:55:37 UTC
I am a little bit uneasy with this issue because it handles two clearly  
distinct issues under the same heading:  
  
(1) OOo should support OpenType features like ligatures, diacritics, small  
caps etc. This would be an ENHANCEMENT to OpenOffice.org, and a very nice  
indeed.  
  
(2) OOo doesn't recognize OpenType fonts with PS outlines under linux. This is  
clearly a BUG (as other applications as e.g. KOffice can handle these fonts),  
and a very annoying one as more and more fonts are published in this format.  
  
I propose to split this issue in two distinct issues and that the second issue  
(failure to render otf-fonts) is declared as BUG.  
  
Comment 22 moyogo 2006-02-11 10:18:13 UTC
> (1) OOo should support OpenType features like ligatures, diacritics, small  
> caps etc. This would be an ENHANCEMENT to OpenOffice.org, and a very nice  
> indeed. 

I have to disagree on that one. For many African languages diacritics placement
(or ligature substitution) is not just an enhancment but a REQUIREMENT.

For example: Malagasy uses n with diaresis : n̈ <U+006E,U+308> N̈ <U+004E,U+308> ;
in Lingala the open e ɛ and the open o ɔ are used with diacritics : ɛ́
<U+025B,U+301> Ɛ́ <U+0190,U+301>, etc. Without these OpenType features it is
impossible to correctly render those character combinations, the diacritics
should go on top of the capital letters not over them. Diacritics placement or
ligature substitution could fix this.
Comment 23 meneteqel 2006-02-11 10:42:36 UTC
> I have to disagree on that one. For many African languages diacritics  
> placement (or ligature substitution) is not just an enhancment but a  
> REQUIREMENT.  
  
I won't disagree with you, but actually this issue has the type ENHANCEMENT. 
 
And still, supporting OpenType features and basic rendering of OpenType fonts 
with PS outlines are two distinct issues. 
 
Comment 24 pmjdebruijn 2006-06-02 16:18:05 UTC
OpenOffice 2.0.2 on Linux (Ubuntu Dapper), still seems to suffer from this issue:

Fine free OTF fonts can be downloaded here (for testing):
http://www.josbuivenga.demon.nl/fontin.html
http://www.josbuivenga.demon.nl/delicious.html
Comment 25 maison.godard 2006-09-07 17:47:13 UTC
if any problem
consider converting OTF to TTF as a workaround
http://fontforge.sourceforge.net/
Comment 26 softadm 2006-09-07 20:09:14 UTC
Just to emphasize this once again: TTF is not OTF, it is not even a workaround 
in some situtations. OTF contains more typographic features, it supports 3rd 
order Bezier splines vs 2nd order bezier splines in TTF. Almost any 
professional font is delivered as an OTF-file nowadays, opentype supports this 
format for quite a long time now and a missing OTF support is a real 
showstopper for people who want more than Arial and Times New Roman in their 
documents.

So many thanks to the OOo team for starting the development on this most 
important feature.
Comment 27 softadm 2006-09-07 20:13:07 UTC
Sorry, I meant freetype supports OTF for quite long time now, not opentype. 
Sorry for this typo.
Comment 28 ckolivas 2006-09-08 01:57:05 UTC
I've added a detailed entry in the wiki based on my experiences.
http://wiki.services.openoffice.org/wiki/Font-FAQ#Are_OTF_fonts_supported_in_OpenOffice.org_2
Comment 29 pesala 2007-03-07 18:24:37 UTC
I hope that at least some OpenType features can be implemented soon:

1) Common ligatures: at least ff fl fi ffl ffi - word count and spell-check should 
also allow for ligatures
2) Small Capitals if they exist in the font should be used for Small Caps Font Effect
3) Super/subscripts if they exist should be used for super/subscript effects
4) An option to select Old Style Figures as part of the paragraph style
Comment 30 a_p_sysoev 2007-04-11 18:06:24 UTC
I suggest that all who aren't indifferent to the support of smart font 
technologies like opentype would pay attention to issue 69129 and vote for it. 
It is about smart font technology called Graphite. Everyone who is acquainted 
with different smart font technolgies understand that by its concept Graphite 
is the best one, and the one that have potential to be universal, extensible 
smart font technology unlike OpenType. OpenType is not of course bad technology 
but graphite is far better one, but not so promoted.
Unlike OpenType, "features" in Graphite are not functional improvements, they 
are just options. I mean that if graphite is supported it is fullfunctional, 
i.e. it provides all Opentype features and more (like reodering), except what 
gives whatever options to a user, options that user can change. And then it is 
nessery just to make interface to give a user possibility to work with 
optionality. In opentype supporting any feature means giving some new 
functional improvement. In graphite supporting features means supporting 
options or possibility just to make some choice as to font rendering and we 
have already full functionality except optionality when graphite engine is 
supported.
For peoples with small languages with sophisticated script behavior Graphite is 
really indispensable, and Opentype has nothing to give sth as a good equivalent 
in those case.
I call for voting for issue 69129.
Graphite is also better for
Comment 31 a_p_sysoev 2007-04-11 18:12:10 UTC
Besides there are some builds of OOo in which graphite engine is supported, but 
features are not.
See graphite.sil.org
Comment 32 utomo99 2007-05-27 07:18:15 UTC
This issue has 97 votes. 
Bettina, can you please assign this issue to a developer please ? 

Thanks

Comment 33 mtrausch 2007-06-21 06:51:20 UTC
It seems that OOo isn't using the host system's support for these fonts; my
system (Ubuntu Feisty Fawn) has OTF support in all of the GNOME applications
that I use, save for OOo, of course.

It looks as if this has been an issue for quite a while now; what's the stopper
keeping it from being fixed?  This is an important issue for many reasons, one
of which is consistency with the rest of the system (see
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/121294 for what I
mean; I use an OpenType font for the rest of my system's user interface, and it
doesn't work in OOo at all, including widget and menu rendering, which makes it
look very ugly when compared with the rest of the system).
Comment 34 hdu@apache.org 2007-06-21 08:51:02 UTC
@tmtrausch: we can display them (e.g. in Web-Layout mode), but subsetting them is not implemented yet 
so any application that wants to print or PDF-export them ignores them. Implementing the CFF subsetting 
feature is no high priority yet, because on an off-the-shelf system usually there are no CFF-fonts. Voting 
for this issue helps to raise the priority though...
Comment 35 hdu@apache.org 2007-06-21 08:58:18 UTC
In my previous comment I should have added the pointer to issue 43029 (CFF-subsetting) and 
differentiate this issue here by emphasising the UI-aspect that enabling/selecting optional OpenType 
features has.
Comment 36 moyogo 2007-06-21 09:05:45 UTC
If this helps figuring out the priority of this bug, even some TTF fonts have
OpenType features. On recent Linux and Windows systems there are off-the-shelve
fonts that provides some of these features, some of which are necessary for
proper language support. DejaVu fonts, Segoe UI, the latest Arial, Times New
Roman and Tahoma all provide features required for some languages.

In the context of those requirements, simple text editors like Notepad, Gedit or
Kate are more useful that OpenOffice. Should I mention OT features are working
in Word?
Comment 37 hdu@apache.org 2007-06-21 09:37:32 UTC
@moyogo: OpenOffice.org already supports the OpenType features that are REQUIRED for scripts. Are you 
aware of any required feature that is not supported?
Comment 38 moyogo 2007-06-21 10:26:53 UTC
@hdu: See comment http://www.openoffice.org/issues/show_bug.cgi?id=16032#desc17

Feature for Standard scripts are listed at
http://www.microsoft.com/typography/otfntdev/standot/features.htm
There features are not required in OpenType fonts but if present using them is
REQUIRED.
Quote: ‘‘ While none of the features listed below are required in OpenType
fonts, they are 'on' or activated by default. Note; there are many more features
(that can be activated at the user's discretion) which can be included in a font. ’’

ccmp, liga, clig, kern, mark and mkmk are thus REQUIRED becuase activated by
default.
These are NOT enabled in OpenOffice, yet ARE REQUIRED for Standard scripts like
Latin, Greek, Cyrillic, etc. Most languages don't need them but some REQUIRE them.
The latest Uniscribe applies locl, ccmp, rlig, liga, clig, calt, kern, mark,
mkmk to Standard scripts. The specifications are not in sync with what Microsoft
is doing. They haven't update them yet. I strongly suggest enabling what
Uniscribe applies.

Did I miss a checkbox somewhere?
Comment 39 hdu@apache.org 2007-06-21 11:32:24 UTC
@moyogo: the missing checkbox is exactly the reason why the optional features are not enabled by 
default. E.g. when XP_SP2 changed the default behaviour for ligatures in Palatino we could have done 
the same thing Notepad does: just use them.

Unfortunately there is a thing called "document backwards compatibility" that is a very important 
feature for a productivity suite. Some users just don't like it when the book they just wrote is formatted 
differently after they applied a OS service pack. Companies don't like it either when a form or a 
spreadsheet has line or page breaks that depend on subtle OS differences. 

I agree that advanced typography features should be enabled, BUT ONLY if the user allows it. The user 
interface to allow and select details of optional OpenType features needs to be defined => this is why 
the task is assigned to the UI team
Comment 40 moyogo 2007-06-21 11:53:35 UTC
@hdu : Yes, advanced features should be enabled by the user in an interface.
However you fail to understand one thing, or I just fail to understand what you
say. The OT features ccmp, clig, mark, mkmk are absolutely necessary for proper
language support, failing to enable by default is like choosing to let the user
choose whether they want to enable the character 'a' to be displayed or any
other thing they use to write normally. 

I agree that 'kern' and 'liga', kerning and standard ligatures, probably should
be enabled by the user since their effect can seriously change layout.

'rlig' and 'clig' are most probably required, rlig is "required ligature" and
'clig' is "contextual ligature". But one could argue against enabling them by
default.

If you manage to find a case where enabling the following by default is bad,
please let me know.
'ccmp' and 'calt' are required because they allow some character substitution in
some context. For example, i+combining_accent should be substituted with
dotlessi+combining_accent, just as i_ogonek+combining_accent should be
substituted with dotlessi+ogonek+combining_accent or
dotlessio_gonek+combining_accent. Not enabling it by default just makes no sense.
'mark' and 'mkmk' position diacritics on base characters or stack them. Why
would you want diacritics to be mispositioned by default? Not enabling them by
default just must no sense.
'locl' substitutes some characters by language specific variants. If a user sets
a document or some text in a language, they surely want it to follow the style
of that language. Not enabling it by default makes no sense.
Comment 41 comcepta 2007-06-21 11:56:37 UTC
To make a long story short: Our company can't use OO productively, because our
company font is OpenType. E.g. it is not possible to create a PDF with the
correct font embedded. That's why we have to use Word and Acrobat. 
Comment 42 ruedin 2007-06-21 12:11:48 UTC
I agree with Moyogo concerning 'ccmp', 'calt', 'mark' and 'mkmk'. It makes no
sense to write or read a text in a language when several caracters are replaced
by '?' or squares.
Comment 43 nmailhot 2007-06-21 12:47:32 UTC
@hdu The argument about not enabling font features because they may change the
layout is very weak. Every OO.o release brings bug fixes which have layout
effects, sticking to old bugs for "stability" sake is ultimately self-defeating.
Users do notice you're the not-evolving doomed dinausor in the ecosystem (with
all the desktop apps implementing new font features for quite a long time now
the OO.o situation is beginning to look very bad).

Also once exported as PDF or .doc font features will be applied anyway so you're
artificially introducing import/export layout consistency problems.

Moreover if you wanted that kind of layout stability every OO.o file should
embed the exact font used by the original author, as font themselves change
slightly from version to version (when they are not substituted by the OS). If
you don't OpenType features are really the last of your layout problems.

Lastly OO.o is used to produce text documents, correctness and
feature-completeness of the text rendering engine should have the highest
priority. If OO.o text rendering is suboptimal there is ultimately no good
reason to use OpenOffice at all.
Comment 44 hdu@apache.org 2007-06-21 12:50:32 UTC
Ah, now I see your points. As far as I see most of the problematic cases moyogo mentioned could be 
solved by detecting them as CTL-text.

Since this issue has been way too broad at the beginning (CFF-embedding, optional and required OT 
features, ...) and converged into a task to specify a UI for optional OT features I opened a separate issue 
78749 for the "some Latin text needs CTL processing" aspect.
Comment 45 hdu@apache.org 2007-06-21 13:44:33 UTC
@nmailhot: layout changes introduced by version changes are considered regressions here => please file 
issues so a layout regression can be evaluated/prioritized/fixed. A layout change that improves the 
"interoperability" aspect usually doesn't get the highest priority though.

Since the discussion here has become way too broad already and the other points raised in your comment 
(OOo should embed the exact font file in the doc, PDF files don't display correctly, OOo should end its 
quest to become platform-agnostic/interoperable/backward compatible ...) deviate even more from the 
point of this issue I suggest to submit new enhancement requests and a bug report for the PDF display 
problem...
Comment 46 mtrausch 2007-06-21 17:43:12 UTC
@tmtrausch: we can display them (e.g. in Web-Layout mode), but subsetting them
is not implemented yet so any application that wants to print or PDF-export them
ignores them. Implementing the CFF subsetting feature is no high priority yet,
because on an off-the-shelf system usually there are no CFF-fonts. Voting 
for this issue helps to raise the priority though...
---
I am a bit confused here.  CFF?  I thought I was adding to an OTF bug.  If you
check out the small screencast that I linked to, you can see what I mean; no OTF
support at all.  I can use TTF fonts just fine, but no OTF—even the user
interface ignores OpenType fonts.
Comment 47 mbayer 2007-06-21 18:10:50 UTC
I hope that doesn't mean the main target of this issue and for which we
currently have 112 votes, that is full implementation of OpenType support, will
drop out of sight.

This is currently a Top-10 voted issue (see
http://qa.openoffice.org/issues/buglist.cgi?resort=1&issue_type=DEFECT;issue_type=ENHANCEMENT;issue_type=FEATURE;issue_type=TASK;issue_type=PATCH;issue_status=NEW;issue_status=STARTED;issue_status=REOPENED;email1=;emailtype1=exact;emailassigned_to1=1;email2=;emailtype2=exact;emailreporter2=1;issueidtype=include;issue_id=;changedin=;votes=80;chfieldfrom=;chfieldto=Now;chfieldvalue=;short_desc=;short_desc_type=substring;long_desc=;long_desc_type=substring;issue_file_loc=;issue_file_loc_type=substring;status_whiteboard=;status_whiteboard_type=substring;keywords=;keywords_type=anytokens;field0-0-0=noop;type0-0-0=noop;value0-0-0=;newqueryname=;Submit%20query=Submit%20query&order=issues.votes%20desc%2C%20issues.issue_id
). I fear 5 or 6 issues covering only a single aspect of OpenType support each
won't ever get the attention of the community and hence the priority that one
single issue covering all aspects of OpenType support has.

So, given this and the fact that on the long term there is no way around full
support for OpenType anyways, may I ask to take this issue more seriously into
account for implementation. I don't feel twisting with other people's words or
making bizarre generalizations is helping for that scope: This issue is not
about embedding fonts into the ODT files, nor is it about making OOo agnostic to
interoperability, or backwards compatibility. It is "only" about full support
for OpenType (PostScript outlines) fonts, 2 years after Adobe announced to
"phase out" PostScript Type 1 fonts and to target only on OpenType fonts. This
has already been stated in the comments #5, #7, and #11 of this issue.

I don't think the target "not determined" of this issue reflects the community's
wishes and prioritizing for OpenType support appropriately.
Comment 48 ralphie 2007-06-21 18:34:05 UTC
hdu,mtrausch: thanks for making this issue clearer by splitting it up.

There is one aspect that deserves another issue of its own, though,
and this is possibly what mtrausch was talking about:

On Linux, CFF/.otf OpenType fonts do not appear in the menu at all,
so another Linux plattform bug to bring the CFF support at least
to Windows level (supported on screen, no embedding) would be
needed. This is not a general Linux plattform problem btw, other
Linux/Gnome programs support CFF/.otf flavoured OT fonts
just fine. Only OpenOffice has problems, e.g. Gnumeric (a Gnome
app) has not. 
Comment 49 mtrausch 2007-06-21 20:33:40 UTC
>There is one aspect that deserves another issue of its own, though,
>and this is possibly what mtrausch was talking about:
>
>On Linux, CFF/.otf OpenType fonts do not appear in the menu at all,
>so another Linux plattform bug to bring the CFF support at least
>to Windows level (supported on screen, no embedding) would be
>needed. This is not a general Linux plattform problem btw, other
>Linux/Gnome programs support CFF/.otf flavoured OT fonts
>just fine. Only OpenOffice has problems, e.g. Gnumeric (a Gnome
>app) has not.

Precisely.  The user interface and the font selection suffers when OTF fonts are
in use.  There are ways to convert these fonts, but all of the conversion
methods are lossy:  PS Type 1 fonts are limited to a certain number of glyphs,
and TTF fonts can't preserve vital kerning information, as I understand it.

It was my impression that OOo was built on GTK+; seeing this strange behavior
with the fonts leads me to believe that this is not the case, as other apps that
are built on GTK+ (Firefox, Pidgin, Gnumeric, Nautilus, Evince, and Abiword)
have support for viewing and printing such fonts, including Fontin.

I suppose, then, that the question comes down to whether or not the wheel has to
be reinvented or not; it looks like that OOo doesn't use the font engine of the
host system, but uses its own instead.  Would it be difficult to use the host
system's font engine?  After all, if someone desires a proofed copy of a
document, that's what PDF is for, isn't it?
Comment 50 hdu@apache.org 2007-06-22 09:55:07 UTC
For clarification: This issue has been split into three parts, because it has become much too broad.
- issue 16032 for selecting optional OT features
   => this will probably have to be split up into UI/GSL/import-export issues
- issue 43029 for better PS-OpenType support (aka. "OTF-Fonts" or "SFNT-Fonts with CFF glyphs")
- issue 78749 for problems of text that is detected as Latin but needs unicode combining
- there are hundreds of other potential issues for implementation details of supporting each and every 
feature defined in http://partners.adobe.com/public/developer/opentype/index_tag3.html and http://
www.microsoft.com/typography/otspec/ttoreg.htm

@mbayer: I'm not sure if there is too much overlap between users requesting support for each of the 
distinct points mentioned above. Though I agree that there are unfortunate aspects to splitting an 
important issue like this into manageable parts. E.g. it would probably be easy to get thousands of 
votes on an issue named "fix all interoperability issues with other office suites" but this wouldn't help 
much except to raise awareness and visibility of an important long term goal.
Comment 51 ckolivas 2007-06-22 12:38:33 UTC
In that case I urge people who have voted for this issue to move or add their
votes to the respective issues. For me the requirement for support of the now
almost universal defacto standard font format .otf with postscript glyphs is
desperately lacking from oo.o which would make it issue 43029 . On linux .otf
fonts do not work at all in oo.o.
Comment 52 xwaver 2007-07-06 01:52:25 UTC
Note: *NIX/Linux PostScript Outline .otf display support has been moved to a new
issue <a href="http://qa.openoffice.org/issues/show_bug.cgi?id=78858">78858</a>.
 Please transfer your votes!
Comment 53 grakic 2008-12-16 14:35:33 UTC
Is 'calt' what is required to support language based glyphs selections?

This feature is required for writing Serbian Cyrillic as most TTF fonts contain
only Russian glyphs. There is an example on pango.org:
http://www.pango.org/ScriptGallery?action=AttachFile&do=get&target=OpenTypeLanguage.png

Comment 54 nmailhot 2008-12-16 15:29:44 UTC
For this part you need locl not calt

http://www.typotheque.com/fonts/opentype_features
Comment 55 grin 2010-01-28 15:12:08 UTC
What is funny that GIMP can render _beautiful_ text from Linux Libertine font,
with advanced kerning, alternative glyphs and everything yummy from the pack
while OOo doesn't seem to grab the concept at all. (True, neither does Scribus.)
Comment 56 bettina.haberer 2010-05-21 15:17:20 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements". 
Comment 57 nemeth.lacko 2010-07-21 07:02:51 UTC
I suggest to change the summary to 

OOo should support optional smartfont features

because we need a common interface to OpenType, Graphite and AAT optional features.

OOo has already supported optional Graphite features, but only by extended font
names (used also by some extensions:
http://www.thanlwinsoft.org/GraphiteOOoExt/,
http://extensions.services.openoffice.org/en/project/typo).

Minimal requirements:

Common UI: Font features menus to the character formatting/font settings dialog
and to the local menu, see also http://silgraphite.sourceforge.net/ui/studynote.html

Possible issues:

Common localization: OpenType and AAT features are standardized
(http://www.microsoft.com/typography/otspec/features_ae.htm,
http://developer.apple.com/fonts/Registry/index.html), so it's possible and
recommended to centralize their translations. If a Graphite font uses standard
OpenType or AAT feature names or descriptions, the translations can be
associated to the Graphite features, too.

Common Smartfont taskbar: with the centralization of the smartfont features, the
most important features can be placed on a taskbar, too.
Comment 58 hdu@apache.org 2010-07-21 08:42:46 UTC
FYI: there is an experimental project in this direction
http://wiki.services.openoffice.org/wiki/OpenOffice.org_Internship/Projects/2010/Optional_OpenType_fe
atures
Comment 59 joh_walt 2010-09-12 10:10:27 UTC
Regarding a common Smartfont taskbar have a look at the Typography toolbar
extension (http://extensions.services.openoffice.org/en/project/typo).
Comment 60 aleces 2011-02-17 11:09:25 UTC
Hy there, I'd like to point out that as far as Serbian typesetting is concerned,
OpenType is not a cute add-on but rather a mandatory requirement since the
default Cyrillic glyphs of certain characters (you'll find relevant information
in the attached .pdf) are actually Russian glyphs and for that reason
inappropriate in Serbian texts. These glyphs should be avoided but even if a
font does contain Serbian glyphs, without access to the locl table, there is no
way of displaying them in Writer.
Thank you
Comment 61 aleces 2011-02-17 11:10:54 UTC
Created attachment 75853 [details]
Russian versus Serbian glyphs
Comment 62 General Kutuzov 2015-01-23 11:05:24 UTC
I also found some of open-source fonts such as Linux Libertine, EB Garamond, have some special rendering, such as alternative glyphs and swashes, optional / historic ligatures, need OpenType feature tags to be passed to the font. MS Office 2013's component such as Word 2013 have a GUI operations to choose OpenType variants in the "Font" dialog, but it is a proprietary software of Microsoft. Some TeX-based free softwares, such as XeTeX or XeLaTeX, can use some OpenType feature, but you muse use lot of codes to implement. so I wish you to support OpenType feature handling and add some operations to the Font dialog.

Here are some samples using OpenType feature:
http://www.linuxlibertine.org/index.php?id=87&L=1
http://www.numbertext.org/linux/fontfeatures.pdf
https://github.com/georgd/EB-Garamond/blob/master/specimen/Specimen.pdf?raw=true
Comment 63 General Kutuzov 2015-01-23 11:16:47 UTC
(In reply to General Kutuzov from comment #62)
> I also found some of open-source fonts such as Linux Libertine, EB Garamond,
> have some special rendering, such as alternative glyphs and swashes,
> optional / historic ligatures, need OpenType feature tags to be passed to
> the font. MS Office 2013's component such as Word 2013 have a GUI operations
> to choose OpenType variants in the "Font" dialog, but it is a proprietary
> software of Microsoft. Some TeX-based free softwares, such as XeTeX or
> XeLaTeX, can use some OpenType feature, but you muse use lot of codes to
> implement. so I wish you to support OpenType feature handling and add some
> operations to the Font dialog.
> 
> Here are some samples using OpenType feature:
> http://www.linuxlibertine.org/index.php?id=87&L=1
> http://www.numbertext.org/linux/fontfeatures.pdf
> https://github.com/georgd/EB-Garamond/blob/master/specimen/Specimen.
> pdf?raw=true

Here is a screenshot from the Font dialog of MS Office 2010, this version also support to switch OpenType variant by GUI:
https://bugs.freedesktop.org/attachment.cgi?id=73540
Comment 64 General Kutuzov 2015-01-23 11:24:18 UTC
I found an idea for OpenType User Interface to be reference:
https://klim.co.nz/blog/towards-an-ideal-opentype-user-interface/
Comment 65 pecita 2015-01-24 00:24:15 UTC
(In reply to General Kutuzov from comment #64)
> I found an idea for OpenType User Interface to be reference:
> https://klim.co.nz/blog/towards-an-ideal-opentype-user-interface/

As a font designer (Pecita, Aghja), the only interest I see to act on disabling eg common ligatures is to break the font.
My view is to not allow to act on the features that are supposed to be active by default: if the designer used them, it is not an accident!
See http://www.microsoft.com/typography/otspec/features_ko.htm#liga
"Liga: This feature serves a critical function in some contexts, and should be active by default."
Comment 66 General Kutuzov 2015-03-12 11:39:55 UTC
Issue 58592 have the same request about this.
Comment 67 General Kutuzov 2015-03-12 11:53:49 UTC
(In reply to pecita from comment #65)
> (In reply to General Kutuzov from comment #64)
> > I found an idea for OpenType User Interface to be reference:
> > https://klim.co.nz/blog/towards-an-ideal-opentype-user-interface/
> 
> As a font designer (Pecita, Aghja), the only interest I see to act on
> disabling eg common ligatures is to break the font.
> My view is to not allow to act on the features that are supposed to be
> active by default: if the designer used them, it is not an accident!
> See http://www.microsoft.com/typography/otspec/features_ko.htm#liga
> "Liga: This feature serves a critical function in some contexts, and should
> be active by default."

I found some of open-source fonts such as EB Garamond and GNU FreeFont have some rules to avoid some ligatures making ambiguous for some words such shelf‌ful or Schifffahrt, despite they are enabled ligature by default.
Comment 68 General Kutuzov 2015-03-12 12:04:44 UTC
Issue 4638 have the same request about this.
Comment 69 General Kutuzov 2015-03-24 14:43:55 UTC
(In reply to hdu@apache.org from comment #2)
> HDU->David: Which OT features exactly are you looking for? 
>  
> We support OpenType fonts if platform specific layout engines support their 
> features. We don't support all of the ever evolving OT spec like stylilistic 
> alternates yet. 
>  
> Freetype targets in a different abstraction layer, it has little to do with 
> OpenType layout.

Despite you don't support all of the ever evolving OT spec like stylilistic alternates, you should provide APIs to handle all OT specs, to let other people write an extension to use them.
Comment 70 JC Ahangama 2015-05-17 19:29:27 UTC
Created attachment 84745 [details]
A sample file to try a ligatured font

This file has a paragraph in Latin-1. The font aruna.ttf will convert it into a complex native Singhala script.
Comment 71 JC Ahangama 2015-05-17 19:35:24 UTC
I have been developing a TTF font since 2004 that follows the OT standard. It is a proof-of-concept that Indic can be first romanized and then presented in the native script using an orthographic smartfont. The idea may be controversial but it might help to shed light on how fonts are rendered by different applications and by operating systems.

My font has only standard ligatures (2500!). Many people think that standard ligatures are things that can be turned on and off. They are not, at least not according to OT Specs. Somebody here quoted on that directly from the OT specs.

liga: Standard, meaning it must show by default
clig: Same set of letters take this shape only in a certain surrounding 
rlig: Special feature by the particular font, that it demands should be shown, but the application is not obligated to do it

As far as I understand and tested, only standard ligatures are mandatory. The categorizing the ligature features is to allow the user to invoke them or not, but not the standard ones. Therefore, an app need not even be aware if a font has standard ligatures. When the user types, the font hands the glyph and tells the app where it begins, next to the letter already there or to replace one or more that are already there.

Take my font (http://www.smartfonts.net/ttf/aruna.ttf), open a text editor in Windows or Linux (Notepad, Geany) and using the font, type 'kxma' (means 'instant' in Sanskrit) and observe what happens.

As you'll see, the four-letter ligature formed after you hit 'a'. These basic TEXT EDITORS are not asking anything outside to help render the text. They simply took whatever the glyph the font gave and puts it up. They are only aware of the rows of Unicode codepoints underneath (called text runs). The sizes of the words and line are all calculated according to the size of the glyphs, and it all makes sense.


> We support OpenType fonts if platform specific layout engines support their 
> features. We don't support all of the ever evolving OT spec like stylilistic 
> alternates yet. 

Good, but please stop asking the Platform for help. OO and LO shows ligatures perfectly inside Linux but not in Windows. Windows screws up Word, OO and LO without discrimination.
Comment 73 JC Ahangama 2015-05-18 01:20:38 UTC
Thank you bhante with respect.

It is a case of understanding what is meant by 'required' and what should be available by 'default'. So, as the links you give say, both should be there by default and I correct myself and say, 'required'.

So, from the links you gave,

LIGA: (by default -- virtually all scripts)
-------------------------------------------
UI suggestion: This feature serves a critical function in some contexts, and should be active by default.

Script/language sensitivity: Applies to virtually all scripts.

RLIG: (by default -- mainly Arabic and Syriac)
----------------------------------------------
UI suggestion: This feature should be active by default. It is recommended that this feature not be turned off to avoid breaking obligatory script shaping.

Script/language sensitivity: Applies to Arabic and Syriac. May apply to some other scripts.
Comment 74 nmailhot 2015-05-18 16:03:43 UTC
The state of the art on opentype features (as of May 07th 2015) is summed up here:

http://www.freesoftwhere.org/2015/05/07/opentype-workshop-lgm-2015/