LO should provide an interface to enable optional smartfont features like liga, sups etc. and also to disable optional features that are enabled by default like calt etc. Ideally this interface covers all three smartfont technologies (Opentype, Graphite and AAT).
Absolutely and completely agree. I want stylistic sets, or stylistic alternates. Graphite isn't the only advanced font technology out there, and while support for it is great, a ton of fonts out there still use OpenType features.
Seems like a reasonable enhancement request, marking as such. Leaving as medium priority as I don't know how difficult this would be to implement or how many people would benefit from it. Thanks for the request/suggestion :)
Not exactly the same, but tightly related: Enhance existing UI elements to check for corresponding OT-features in the fonts and apply them if selected. For example smallcaps, superscripts and subscripts switches should check for smcp/sups/subs (or sinf) features and apply these features instead of artificially creating fake smallcaps etc. Should I open a new report for this?
Created attachment 73540 [details] Microsoft Word 2010's interface for OpenType features The menu in the attachment is accessed with Font > "Advanced" tab. For example, the drop down menu for "Number Forms" offers "Old-style" and "Default", and "Stylistic Sets" shows the numbers 1-20. I'd say this would be a reasonable interface for the features.
*** Bug 59603 has been marked as a duplicate of this bug. ***
Apple has released the source code of its simple TextEdit word processor, which has reasonable OpenType support, under a license similar to the BSD licenses. XeTeX has the best OpenType feature support on the market today, and it's released under the MIT License. Could LibreOffice make use of either of these?
See the diagram on the top right on page 25 of http://xml.web.cern.ch/XML/lgc2/xetexmain.pdf (or page 13 with the document's numbering). It's similar to LibreOffice's existing Insert Special Character interface (see bug 56301 for my complaints about that one), but when a user clicks and holds (hovers, perhaps?) all the alternate OpenType glyphs appear. I'd say that this would be an even better interface, or it could be supplemental to one in the style of Microsoft Word 2010.
It would be indeed helpful if LibreOffice supported the optional smartfont features of OpenType and integrated them into the user interface (for OpenType and Graphite)
Hi, I think this would be interesting due to compatibility with MS Word...
I don't know if that's a goal for which LO aims.
Although stylistic sets are designed to be mutually exclusive, it would be good if it were possible to activate more than one at a time.
(In reply to comment #11) > Although stylistic sets are designed to be mutually exclusive, it would be > good if it were possible to activate more than one at a time. Why should they be mutually exclusive?
Suppose the default glyph for "a" in a font has a long tail, similar to Helvetica or Arimo/Liberation Sans. Suppose that the author has created two stylistic sets: "ss01" removes that tail from the a, and "ss02" makes it a one-story a. This would create a conflict if the user activated both at once, so this problem would have to be addressed. Perhaps, if the user tries to activate two conflicting features at once, there should be an error message.
(In reply to comment #13) > Suppose the default glyph for "a" in a font has a long tail, similar to > Helvetica or Arimo/Liberation Sans. Suppose that the author has created two > stylistic sets: "ss01" removes that tail from the a, and "ss02" makes it a > one-story a. This would create a conflict if the user activated both at > once, so this problem would have to be addressed. Perhaps, if the user tries > to activate two conflicting features at once, there should be an error > message. This is not an issue for the rendering engine. It only has to cycle through the lookups and apply one active GSUB rule after the other. It’s the font designer’s task to make sure to prevent inconsistencies. In your case, there would be a feature ss01: substitute a by a.notail and ss02: substitute a by a.onestory. In this case, the program will find an “a” in a text, cycle through the lookups and find a match in ss01, so a gets replaced with a.notail. Then it continues but won’t find a match in ss02 because now there’s no longer an a but an a.notail for which no lookup exists in ss02. If the font designer wished to get a match here too, he would add substitute a.notail by a.onestory to his ss02 lookups. You see, the order in which the lookups appear in the font is important (there’s no fixed order, one is absolutely free to put ss02 before ss01 in their font), LO doesn’t have an influence here and there’s no need for error messages. It’s more a question of the font’s documentation.
That's a relief to know. So it is possible to activate more than one at once.
(In reply to comment #15) > That's a relief to know. So it is possible to activate more than one at once. Yes. You may even activate every single feature available in a font at the same time, even such contradictory ones like tabular and proportional numbers or sub- and superscript, and the worst thing that should happen is, that some simply won’t have any effect.
*** Bug 63076 has been marked as a duplicate of this bug. ***
If there'll be any work on this, please-oh-please don't emulate the MS's "we know what's good for you" encapsulation. Much more better (and logical) to have checkbox-list of font variants on a separate tab in character/paragraph dialogs. I understand the complete list of variants is extractable from font file for each "smart technology" (Graphite, etc.)?
On the other hand, Apple's mod of the 'insert character' dialog seems to be optimal (but is it implementable in LO?)
(In reply to comment #18) > If there'll be any work on this, please-oh-please don't emulate the MS's "we > know what's good for you" encapsulation. > > Much more better (and logical) to have checkbox-list of font variants on a > separate tab in character/paragraph dialogs. This seems reasonable. > I understand the complete list > of variants is extractable from font file for each "smart technology" > (Graphite, etc.)? At least for opentype, it is extractable. (In reply to comment #19) > On the other hand, Apple's mod of the 'insert character' dialog seems to be > optimal (but is it implementable in LO?) What does that look like? At least the title “insert character” doesn’t sound adequate for the desired feature.
I mean the Indesign dialog on page 25 of PDF which Linus linked to in comment #7.
(In reply to comment #21) > I mean the Indesign dialog on page 25 of PDF which Linus linked to in > comment #7. Ok, might be useful, but only in addition to a general feature selecting interface. This character table hack would make use of the aalt feature which needs to be implemented in the font (which isn’t the case for EB Garamond yet).
Of course, I didn't mean such 'Insert character' would preclude implementing a comprehensive font variant selector. 'Apples and oranges' :). The question of feasibility remains -- while variants may already be set (and saved) via the ":feat=1" mechanism in font face field, albeit not handily and not universally (#63076), is it at all possible to insert (and save) a glyph with variants? Wouldn't it require changes in OD file format, even?
(In reply to comment #23) > Of course, I didn't mean such 'Insert character' would preclude implementing > a comprehensive font variant selector. 'Apples and oranges' :). > > The question of feasibility remains -- while variants may already be set > (and saved) via the ":feat=1" mechanism in font face field, albeit not > handily and not universally (#63076), is it at all possible to insert (and > save) a glyph with variants? Wouldn't it require changes in OD file format, > even? A quick search found me this document: https://lists.oasis-open.org/archives/office-comment/201008/pdf00000.pdf It proposes two solutions to this problem of which one doesn’t need changes to the format and which seems to be used for Graphite already (else Graphite wouldn’t work either). So it is feasible.
Well, I didn't think of that (not that I know much of ODF). Anyway, personally I'm even more interested in #56076 getting fixed.
As you can see at http://blogs.linux.ie/caolan/2013/03/12/opentype-locl-localized-forms/, Caolán McNamara has implemented the OpenType 'locl' feature, but that's only one out of a wealth of typographic resources. Note: there is currently no OpenType implementation that supports slashed zero. Can LibO be the first?
Here's a complete Web implementation of OpenType: http://www.impallari.com/testing/ And its source code: https://github.com/impallari/font-testing-page
Will get (have got?) into the 4.1.0? Splendid. Thanks for the tip. Does someone know of any progress pertaining to the #56076 ? Actually, it's closed, and on quite a presumption, I think, but still? Seems to be one of those quite obvious things (and elementary in implementation, too, all needed things are already there) that nobody knowledgeable wants to dirty their hands with.
(In reply to comment #28) > Does someone know of any progress pertaining to the #56076 ? > Actually, it's closed, and on quite a presumption, I think, but still? This probably isn't the right bug to be asking that.
(In reply to comment #26) > As you can see at > http://blogs.linux.ie/caolan/2013/03/12/opentype-locl-localized-forms/, > Caolán McNamara has implemented the OpenType 'locl' feature, but that's only > one out of a wealth of typographic resources. > > Note: there is currently no OpenType implementation that supports slashed > zero. Can LibO be the first? What do you mean by that? Lots of applications support the 'zero' feature, among others Xe- and LuaTeX and Harfbuzz. I suppose, that ICU supports it too (it’s usually implemented as simple substitution, so nothing special to do there for the engine), LibO is only lacking an interface to activate it.
Oops. I was relying on an old chart about OpenType feature support, but it seems that several applications have implemented it since then. http://ilovetypography.com/OpenType/opentype-features.html
I've just found a free and open source implementation of OpenType (even if it is called "TrueType Viewer"). It's available at http://home.kabelfoon.nl/~slam/fonts/truetypeviewer.html.
Hello everybody, Supporting the locl substitution table is fundamental for Serbian because Serbian needs some special glyphs to be properly typeset. Have you set a roadmap for the implementation of these features? Regards,
(In reply to comment #33) > Hello everybody, > Supporting the locl substitution table is fundamental for Serbian because > Serbian needs some special glyphs to be properly typeset. That’s already implemented - on Linux at least. See bug 62154.
(In reply to comment #30) > (In reply to comment #26) > What do you mean by that? Lots of applications support the 'zero' feature, > among others Xe- and LuaTeX and Harfbuzz. I suppose, that ICU supports it > too (it’s usually implemented as simple substitution, so nothing special to > do there for the engine), LibO is only lacking an interface to activate it. @Georg Duffner: Since LibreOffice 4.1 Linux (and other X11 platforms) were ported to Harfbuzz. See here: https://wiki.documentfoundation.org/ReleaseNotes/4.1#Core So hopefully, this makes the implementation of smartfont features more feasible.
There are two issues to tackle here (aside from the actual coding): 1) Desiging a proper interface for activating the features (SIL had some document comparing different UIs for this, plus there own recommendation) 2) Figuring out how to save the feature setting in ODF cleanly (I assume ODF do not have a way to do this right now, so one will need to research other standards like CSS or OOXML and figure out what ODF extension we need). So, perhaps people interested on this can work on those two items (which should help improving Graphite support in LibreOffice as well, and I think there were some research on this when Graphite support was first introduced). Once we have a clear idea what needs to be done, I hope to be able to work on implementing it.
(In reply to comment #36) > There are two issues to tackle here (aside from the actual coding): 1) > Desiging a proper interface for activating the features (SIL had some > document comparing different UIs for this, plus there own recommendation) 2) > Figuring out how to save the feature setting in ODF cleanly (I assume ODF do > not have a way to do this right now, so one will need to research other > standards like CSS or OOXML and figure out what ODF extension we need). > Microsoft Word 2010's interface for OpenType features is an excellent starting point, except for the stylistic sets, which could be provided on check boxes.
The ODF 1.2 spec cites the CSS3 Text Module as a non-normative reference. The CSS3 Text namespace is typically included in ODT documents produced by LibreOffice Writer. Because of this, it seems logical and justified to use the [CSS Fonts Module Level 3](http://www.w3.org/TR/css3-fonts/) for all advanced typographic features. This CSS module takes into account the three major smart font technologies: OpenType, Graphite and AAT. It now has “Candidate Recommendation” status and it is set to become a Recommendation relatively soon. Using this module’s vocabulary in attributes on the `style:text-properties` element seems straightforward. An added benefit is that the `style:font-name` and other such attributes would not be overloaded with font feature names. Consider the following example: <style:style style:name='cited-author' style:family='text'> <style:text-properties style:font-name='Linux Libertine O' css3f:font-synthesis='none' css3f:font-variant-caps='small-caps' /> </style:style> This would be roughly equivalent to the following CSS: .cited-author { font-family: 'Linux Libertine O', serif; font-synthesis: none; font-variant-caps: small-caps; } Note that I use `css3f` to refer to the CSS3 Fonts namespace, which is coherent with the namespace prefix already used for the CSS3 Text Module (`css3t`) in ODF. [Appendix A](http://www.w3.org/TR/css3-fonts/#platform-props-to-css) (non-normative) begins thus: “Font properties in CSS are designed to be independent of the underlying font formats used”. Indeed, the new syntax for feature selection is different from the terse OpenType tags and is more in line with the rest of CSS’s vocabulary. This generality is very desirable for ODF as well. In addition to new @-rules and new `font-variant` properties, low-level control of OpenType features is also available through the `font-feature-settings` property, but this is less general and should only be used for complex and unusual combinations of OpenType features which cannot be expressed in another way. I cannot think of a better way to correctly model advanced typography in ODF. It is clean, standard and takes us away from the limitations of the Formatting Objects vocabulary. It would also give LibreOffice *quite an edge* over MS Office. It’s the way forward! ;-)
Here some UI mockups by type designers, just for reference: https://klim.co.nz/blog/towards-an-ideal-opentype-user-interface/ Generally, just recently, after the last ATypI conference a petition was started by type designers towards Adobe to have them include a better UI. Expect in the next weeks and months an intensive dialogue to surface.
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
I think despite you do not developed the interface, you should provide a full function and cross-platform API to make use of them.
@General Kutuzov no need to keep commenting on this enhancement as it doesn't add or move it forward. We know that it's an enhancement - as such, it will depend on volunteers to accept it and implement it. We do not give ETA's but just be prepared to wait a long time for this to be implemented. TDF (the non profit behind LibreOffice) has absolutely no power over what issues/enhancements get implemented, we're a team of volunteers and as such, your options are: 1. Fix it yourself; 2. Find someone to fix it (family, friend, etc...); 3. Pay for a fix; 4. Wait
(In reply to Joel Madero from comment #42) > @General Kutuzov > > no need to keep commenting on this enhancement as it doesn't add or move it > forward. We know that it's an enhancement - as such, it will depend on > volunteers to accept it and implement it. We do not give ETA's but just be > prepared to wait a long time for this to be implemented. TDF (the non profit > behind LibreOffice) has absolutely no power over what issues/enhancements > get implemented, we're a team of volunteers and as such, your options are: > > 1. Fix it yourself; > 2. Find someone to fix it (family, friend, etc...); > 3. Pay for a fix; > 4. Wait Oh~sorry for my fault. I found all the feature ID as U inputed only available for Graphite fonts, but OT and AAT fonts cannot access their features in this way. There are some opdn-source and powerful typesetting engines can handle these features, why not make use of them?
Created attachment 115067 [details] PNG illustrating "Th" ligature controle for Graphite and OpenType I'm aware that additional comments from simple users rather than coders does nothing to move this enhancement request forward (I see comment #42! ;) Still, it's worth noting that OpenType support is the most upvoted Q&A on AskLibreoffice, a community which seems fairly congenitally predisposed against voting on anything: http://ask.libreoffice.org/en/questions/scope:all/sort:votes-desc/page:1/ That's worth noting, especially in light of an early comment (#2): > Leaving as medium priority as I don't know how difficult this would be to implement or how many people would benefit from it. The latter question is fairly easy to answer, in fact: it would benefit every single user of LibreOffice Writer. I make good use of the Graphite enabled version of Linux Libertine, but it would be so, so good to be able to have similar control over the much wider range of Open Type fonts available. I attach a PNG illustrating one specific use case. Will continue to hope that this enhancement comes through sooner rather than later (is the GSoC territory?)!
Some food for thought on this topic from LGM 2015: http://www.freesoftwhere.org/2015/05/07/opentype-workshop-lgm-2015/
Created attachment 119303 [details] Office 2016 screenshot Here is the Advanced Typography UI from Word 2016, not much has changed.
Created attachment 119304 [details] screenshot from OS X general For completeness here is the UI from Apple Pages, though this uses the core OS X opentype support.
I think you can try to get this support via Pango. https://bugzilla.gnome.org/show_bug.cgi?id=738505
Pango is cross-platform, but does LO use Pango? Having a modern cross-platform text layout engine sure seems like an important upgrade for LO, and there are suggestions it will be easy to implement (comments from Caolan on a disappeared web page).
So what if using HarfBuzz on all platforms?
I found LO 5.0.3 for Windows supporting several OT features such as standard ligature and kerning, but they seems not optional, they can’t be controled via Typographic Toolbar extension (http://extensions.libreoffice.org/extension-center/typography-toolbar).
(In reply to General Kutuzov from comment #51) > I found LO 5.0.3 for Windows supporting several OT features such as standard > ligature and kerning, but they seems not optional, they can’t be controled > via Typographic Toolbar extension > (http://extensions.libreoffice.org/extension-center/typography-toolbar). This extension is for Graphite, not OpenType fonts.
(In reply to Khaled Hosny from comment #52) > (In reply to General Kutuzov from comment #51) > > I found LO 5.0.3 for Windows supporting several OT features such as standard > > ligature and kerning, but they seems not optional, they can’t be controled > > via Typographic Toolbar extension > > (http://extensions.libreoffice.org/extension-center/typography-toolbar). > > This extension is for Graphite, not OpenType fonts. I know this extension is designed for Graphite initially, but it seems to that this extension is just adding or modifing feature tag and value after font name, some of feature tags in this extension is also available in OT specification.
I think the OpenType feature 'locl' can be used through changing the language of text in “Character” dialog, this is very useful for Serbian and Macedonian speaking people.
I have more ideas for enabing optional OpenType feature, you can improving the “Character” dialog to providing oprations. First, the “Small capitals” effect (in Font Effects table) can be used for enabing true small capitals if a typeface inluding OT feature 'smcp', otherwise displaying scaled small captials instead (in this case the Effect option can adding “Pepite capitals” to handle pepite caps). Next, the “Superscript” and “Subscript” option in Position tab can be used for enabling corresponding OT feature, in this case you should adding a check box to let these options uses OT superscript and subscript if a typeface support. Third, the right of “Pair kerning” option can adding another option to enabing or disabing OT kerning.
(In reply to General Kutuzov from comment #55) > I have more ideas for enabing optional OpenType feature, you can improving > the “Character” dialog to providing oprations. First, the “Small capitals” > effect (in Font Effects table) can be used for enabing true small capitals > if a typeface inluding OT feature 'smcp', otherwise displaying scaled small > captials instead (in this case the Effect option can adding “Pepite > capitals” to handle pepite caps). Next, the “Superscript” and “Subscript” > option in Position tab can be used for enabling corresponding OT feature, in > this case you should adding a check box to let these options uses OT > superscript and subscript if a typeface support. Third, the right of “Pair > kerning” option can adding another option to enabing or disabing OT kerning. You cannot just redefine existing functionality as the OpenType replacement might not work all the time, for example most typefaces that support super and subscript features has very incomplete coverage, so just applying the features instead of scaling will result in some characters as superscript and some are not. This can be said for other features as well, so you will still need a way for the user to manually control the use of OpenType feature here, and this will eventually need to be saved to the file, so we are back to square 0; ODF does not support this AFAIK.
(In reply to Khaled Hosny from comment #56) > (In reply to General Kutuzov from comment #55) > > I have more ideas for enabing optional OpenType feature, you can improving > > the “Character” dialog to providing oprations. First, the “Small capitals” > > effect (in Font Effects table) can be used for enabing true small capitals > > if a typeface inluding OT feature 'smcp', otherwise displaying scaled small > > captials instead (in this case the Effect option can adding “Pepite > > capitals” to handle pepite caps). Next, the “Superscript” and “Subscript” > > option in Position tab can be used for enabling corresponding OT feature, in > > this case you should adding a check box to let these options uses OT > > superscript and subscript if a typeface support. Third, the right of “Pair > > kerning” option can adding another option to enabing or disabing OT kerning. > > You cannot just redefine existing functionality as the OpenType replacement > might not work all the time, for example most typefaces that support super > and subscript features has very incomplete coverage, so just applying the > features instead of scaling will result in some characters as superscript > and some are not. This can be said for other features as well, so you will > still need a way for the user to manually control the use of OpenType > feature here, and this will eventually need to be saved to the file, so we > are back to square 0; ODF does not support this AFAIK. Oh, I hope someone can submitting a draft to improve the ODF specification.
Additionaly, to avoid unexpected situations, I think the option that can be let OT superscript/subscript enabled shouldn’t be enabled by default.
(In reply to General Kutuzov from comment #54) > I think the OpenType feature 'locl' can be used through changing the > language of text in “Character” dialog, this is very useful for Serbian and > Macedonian speaking people. This way of controling 'locl' feature can be independent of saved file.
(In reply to General Kutuzov from comment #55) > I have more ideas for enabing optional OpenType feature, you can improving > the “Character” dialog to providing oprations. First, the “Small capitals” > effect (in Font Effects table) can be used for enabing true small capitals > if a typeface inluding OT feature 'smcp', otherwise displaying scaled small > captials instead (in this case the Effect option can adding “Pepite > capitals” to handle pepite caps). Next, the “Superscript” and “Subscript” > option in Position tab can be used for enabling corresponding OT feature, in > this case you should adding a check box to let these options uses OT > superscript and subscript if a typeface support. Third, the right of “Pair > kerning” option can adding another option to enabing or disabing OT kerning. I have rethought for this idea, only small caps feature can independent of saved file; other operations is required to be saved in a file, which need ODF specification support, I think someone can submit a draft to let user defines typographic feature.
> I have rethought for this idea, only small caps feature can independent of > saved file; other operations is required to be saved in a file, which need > ODF specification support, I think someone can submit a draft to let user > defines typographic feature. "Someone" - why not you? https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office Also, just a tip, spamming your own bug with 50ish clarifications makes the bug incredibly hard for any developer to look at. I would suggest going to the ODF site, maybe send them an email, close this bug as INVALID (because it's impossible to follow at this point), get clarification from ODF people, then report a new bug over here. I won't close it, but I can guarantee that almost every developer will look at this bug for 5 seconds and then move on because of how many comments (many of which don't enlighten the solution) there are.
> "Someone" - why not you? > https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office I heard ODF 1.3 is under formulating, but I don’t know how to send a draft to improve it.
SoftMaker has already decided to support optional font features for OOXML format. http://forum.softmaker.com/viewtopic.php?f=266&t=16021
Features can now be controlled for OpenType fonts in the same syntax as Graphite features. Proper ODF support and UI are still missing.
(In reply to Khaled Hosny from comment #64) > Proper ODF support and UI are still missing. 1. For ODF support, this can done via making small improves on LO if we discovered an error really affect file loading or saving, if we can get solution based on ODF spec would be better. 2. This seems not enough important to be considering, since an extension can do it.
(In reply to Volga from comment #65) > 2. This seems not enough important to be considering, since an extension can > do it. I disagree. LO could also remove Bold, small-caps and other settings from the UI too as an extension could do it. The goal should be to empower the user to create the best documents they can, and OT features really make a substantial difference to quality typography. I know that LO is constrained by the number of developers capable of working on these features, but I still think this remains important. If there is no UI, and even if there is only a hard-to-discover extension, the feature may as well not exist for the majority of users.
@Khaled Hosny: This is great news that optional smart font features are now supported by LO. I have two of questions related to this: (1) Where is a good list of supported smart font features and related commands for the font dialog. I know this one, but I am not sure whether there is any better documentation: http://www.numbertext.org/linux/fontfeatures.pdf (2) Wouldn't it make sense to close this bug as fixed and open four new bugs: (a) a proper UI, (b) support in ODF save/load, (c) support in OOXML import/export and (d) write proper help documentation for the LibreOffice Help.
(In reply to Gerry from comment #67) > @Khaled Hosny: This is great news that optional smart font features are now > supported by LO. I have two of questions related to this: > > (1) Where is a good list of supported smart font features and related > commands for the font dialog. I know this one, but I am not sure whether > there is any better documentation: > http://www.numbertext.org/linux/fontfeatures.pdf The official OpenType feature registry is: https://www.microsoft.com/typography/otspec/featuretags.htm Basically any feature listed there is supported. > (2) Wouldn't it make sense to close this bug as fixed and open four new > bugs: (a) a proper UI, > (b) support in ODF save/load, > (c) support in OOXML import/export and > (d) write proper help documentation for the LibreOffice Help. I have no strong feeling either way, if someone can file these bugs then I’m fine closing this one, except it has some good ideas, like using CSS Text-3 syntax for ODF, but probably we can copy/link them in the relevant new bugs.
(In reply to Volga from comment #65) > 2. This seems not enough important to be considering, since an extension can > do it. This entension I refered is “Typography Toolbar”, but I think creating an another entension to add an interface is welcome.
(In reply to Khaled Hosny from comment #68) > I have no strong feeling either way, if someone can file these bugs then I’m > fine closing this one, except it has some good ideas, like using CSS Text-3 > syntax for ODF This means adding font-feature-settings property or similar into content.xml, isn’t it?
*** Bug 105710 has been marked as a duplicate of this bug. ***
OASIS Technical Committees Issue Tracker have a proposal OFFICE-3414 releated to this bug.
(In reply to Khaled Hosny from comment #68) > (In reply to Gerry from comment #67) > > (2) Wouldn't it make sense to close this bug as fixed and open four new > > bugs: (a) a proper UI, > > (b) support in ODF save/load, > > (c) support in OOXML import/export and > > (d) write proper help documentation for the LibreOffice Help. > > I have no strong feeling either way, if someone can file these bugs then I’m > fine closing this one, except it has some good ideas, like using CSS Text-3 > syntax for ODF, but probably we can copy/link them in the relevant new bugs. Since OASIS planned to add it into ODF 1.3, I think we can get support in ODF save/load when this specification is released. For OOXML I have already created bug 104281, but we need a document created by MS Office for test.
(In reply to Volga from comment #73) > For OOXML I have already > created bug 104281, but we need a document created by MS Office for test. I have already uploaded a sample document.
GitHub HarfBuzz repository has a request for an API to expose which feature tags included in a font. Once HarfBuzz implemented this API, we can try to add new APIs to allow others write a new extension, to show what OpenType/Graphite feature tags are available in which fonts.
Created attachment 141006 [details] QuarkXpress OpenType interface examples The best interface I have seen for OpenType support is in QuarkXpress. The OpenType features are usually hidden and are accessed from a spinner. The application actually reads the font file and only activates the available features. Unavailable features are grayed-out. So the user knows what is available. This image shows examples for Liberation Sans and Minion Pro.
> GitHub HarfBuzz repository has a request for an API to expose which feature tags included in a font. Once HarfBuzz implemented this API, we can ... Is that https://github.com/harfbuzz/harfbuzz/issues/561 ?
(In reply to Dave Crossland from comment #77) > > GitHub HarfBuzz repository has a request for an API to expose which feature tags included in a font. Once HarfBuzz implemented this API, we can ... > > Is that https://github.com/harfbuzz/harfbuzz/issues/561 ? HarfBuzz has enough API to get anyone started in this, that is not the blocker the real blocker are (in descending order) 1) finding a way to store font features in ODF documents 2) implementing it in LibreOffice 3) Designing and writing a GUI to control the features 4) pushing this through ODF standardization process. Any help is welcomed, I personally have no experience with any of these 4 points.
I'd like to report a case in which the apparent lack of a way to disable ligatures very nearly made LibreOffice dangerously useless for me. I'm keeping my CV in LibreOffice, and generating PDFs from it. Turns out that for the last few years CVs seemingly tend to be parsed automatically by various softwares that extract the information from them and pre-filter them accordingly. And my CV contains a number of keywords that, once turned into a PDF and extracted as text, are broken: for example, "firmware" -> "frmware". This might make my CV useless! Luckily I found the ":-liga" thing and could apply it everywhere. But it took me enough to find this that I was already resigned to move (back!) to Word.
(In reply to hmijail from comment #79) > I'd like to report a case in which the apparent lack of a way to disable > ligatures very nearly made LibreOffice dangerously useless for me. > > I'm keeping my CV in LibreOffice, and generating PDFs from it. Turns out > that for the last few years CVs seemingly tend to be parsed automatically by > various softwares that extract the information from them and pre-filter them > accordingly. And my CV contains a number of keywords that, once turned into > a PDF and extracted as text, are broken: for example, "firmware" -> > "frmware". This might make my CV useless! That is was fixed in bug 115117.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bda33ba2ce4d53214e1bd9ee62b05ced0525e8db tdf#58941 implement retrieving font features and structures It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3aa8a048776bdf0d4868847baac2a72aa55cd6a3 tdf#58941 Manipulate with font features using FontFeatureDialog It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Could this changeset be the cause of bug 118301?
Here is a screenshot of the features panel for a Graphite font (with lots of features). The corresponding panel for an OpenType font lacks support for cvxx and ssxx features beyond their simple name. This is due to lack of cvxx and ssxx access API in harfbuzz and even then the ability to then lookup a nameid to get an appropriate string. We hope to address these subissues in due course
Created attachment 144081 [details] graphite features panel
(In reply to Commit Notification from comment #82) > Tomaž Vajngerl committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=3aa8a048776bdf0d4868847baac2a72aa55cd6a3 > > tdf#58941 Manipulate with font features using FontFeatureDialog > > It will be available in 6.2.0. ...> > Affected users are encouraged to test the fix and report feedback. I tested this with libo-master64_2018-06-27. It appeared to be a work-in-progress with multiple issues. I just tested with libo-master64_2018-08-08. Appears to be the same. Is this going to be the version of this dialog released? If so, this is may cause more problems than it solves. For example: - Users should not be able to enable features which are mutually exclusive. - There is no option for Default which is appropriate for certain features. This is nothing more than the fake bold & italic confusion times 10. The OpenType features dialogs in QuarkXPress 2018 have substantial improvements over 2017 which shows that they have been making improvements based on user feedback. It is much better. And still better than the InDesign OpenType interface. The grouping and logic work has already been done. I can even summarize it if it would actually be used to fix this interface. I would be happy to post multiple screenshots from QuarkXPress 2018 - if anyone would actually look at them, and - actually incorporate the better features. Not going to waste the time if no one is going to even bother to look at them again.
@Xisco: Should we reopen this ticket? Or better create a new one.
(In reply to Heiko Tietze from comment #87) > @Xisco: Should we reopen this ticket? Or better create a new one. Personally, I would prefer to create a new one. This one has 87 comments and is becoming hard to follow...
(In reply to LibreTraining from comment #86) > ... > I tested this with libo-master64_2018-06-27. > It appeared to be a work-in-progress with multiple issues. How about a more polite "Great work, but there are some glitches left" > - Users should not be able to enable features which are mutually exclusive. Sounds reasonable to me. Though the dialog just presents the feature that Harfbuzz/Graphite has and there is no such thing as dependency to Tomaz' knowledge (and I'm completely off). If you know more details please share with us. > - There is no option for Default which is appropriate for certain features. That option would reset all to off, right? Sounds like a nice to have to me. Anyway, please file new tickets if you think the implementation needs improvements. For what I see there is not much to do.
Merge tiles featuring mesmerizing images of Taylor Swift throughout her career, from her early days to her record-breaking achievements. https://taylorswift2048.io/