Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||OOo should support optional OpenType features|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Priority:||P3||CC:||acquadoria, alex, arthit, avuton, bah_ooo, benjamin.dev, bugzilla, cwoollard, daniel.dorau, devel, fonts-bugs, grakic, grin, hans, hdu, hin.stone, iorsh, issues, jbf.faure, jc, jlp.bugs, kami911, liam, manens, masaya.k, moyogo, munzirtaha, nemeth.lacko, nicolas.mailhot, nusorn, oo, ousia, pesala, ralph, rgb.mldc, scott.baker, shanshandehongxing, simos.bugzilla, sven.burmeister, utomo.prawiro, vaidrius|
|Target Milestone:||not determined|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
|Issue Depends on:||43029|
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 firstname.lastname@example.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 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 email@example.com 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 firstname.lastname@example.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 email@example.com 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 firstname.lastname@example.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 email@example.com 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 firstname.lastname@example.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 email@example.com 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 firstname.lastname@example.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 email@example.com 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 firstname.lastname@example.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 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 shelfful or Schifffahrt, despite they are enabled ligature by default.
Comment 69 General Kutuzov 2015-03-24 14:43:55 UTC
(In reply to email@example.com 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 72 pesala 2015-05-17 20:00:16 UTC
rlig is required, liga is not. Both are on by default. http://www.microsoft.com/typography/otspec/features_ko.htm#liga http://www.microsoft.com/typography/otspec/features_pt.htm#rlig
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/