LibreOffice 5.3.0 adds OpenType Layout feature support

LibreOffice 5.3.0 is a new version of the free office suite for Windows, macOS and Linux. Among its many new features is a fully-revamped text engine which uses HarfBuzz and supports both automatic and user-controlled OpenType Layout features for all scripts. The release notes say: 

  • OpenType layout is now supported on all platforms, and default OpenType features are enabled for all languages.
  • Graphite layout is now supported on macOS as well, not only Linux and Windows.
  • OpenType layout features can be controlled using the syntax previously only supported for Graphite fonts.
  • Improved Kashida justification for Arabic script.
  • Improved vertical text layout for CJK scripts to use HarfBuzz instead of the home grown solution(s).
  • All text layout now goes through HarfBuzz, there is no longer any distinction between so-called simple and complex scripts.
  • Many Windows-only and macOS-only text layout bugs have been fixed.
  • Improved and consistent calculation of inter-line spacing across platforms
  • Enable vertical “left to right” block direction, needed for traditional Mongolian and Manchu

The OpenType Layout features in LibreOffice are controlled by appending a suffix to the font name in the "Character" font dropdown list. For example, if I select some text and choose the font "EB Garamond" from the font list, I get the default features applied (e.g. "liga"), but I can edit the font name in the dropdown list and change it to "EB Garamond:dlig=1", then the "dlig" feature will also be applied, or I can specify: "EB Garamond:dlig=1&lnum=1&hlig=1" as the font name to have more features enabled. See this in action: http://recordit.co/wWIOisqkQ0

Comments

  • James PuckettJames Puckett Posts: 1,363
    Are they going to add buttons for the OTL features? This seems like a rather odd way to activate OpenType features given it’s in a major release and not an alpha.
  • John HudsonJohn Hudson Posts: 1,027
    Buttons?! Didn't need no stinking buttons in WordPerfect 5.1.
  • Adam JagoszAdam Jagosz Posts: 65
    edited February 1
    You can also just select the feature without any assignments, and the hyphen-minus sign before the feature tag disables it, e.g. "EB Garamond:-liga&dlig" disables standard ligatures and enables discretionary. That is a little bit more concise, but I find the ampersand the bottleneck: it would be so much easier to just type another colon.

    Stinking buttons? I would even go for checkboxes, with the current state of affairs it is hardly possible to set features for arbitrarily chosen fragments of a passage of text and then change the font. And that's something I would like to do with my Blackletter design consisting of two layers, of which one is used for rubrication. If I want to customize the text to include ligatures and scribal abbreviations for some words and not for others (e.g. replicating a manuscript) and then copy the text and overlay the copy but only change the font to the rubrication font then LibO will erase all my work from the copy.

    Okay, I know that's not something a lot of people need or care about... But still.
  • It's great that the support is there, and a pity that it is implemented so poorly that I see no reason to bother getting LibreOffice to play with it, as yet.  :(

    This is a fine example of how and why average software users might get the impression that Open Source software is not for them.
  • Does this include variable fonts?
  • No, variable fonts weren’t even announced yet when this work was being finished.
  • I have been waiting ten years for this, so I am happy, even if it is not yet user-friendly. 

    If you're willing to edit a few styles to enable features that you need, e.g. Small Capitals in headings, Ordinals and/or Alternative Fractions, etc., in Body Text, then it is not difficult to apply those styles to text as required. 

    I have added a few notes to my review page for LibreOffice to get non-geeks started. 

    Hopefully, within another year or so, someone will volunteer to do the necessary work to implement a GUI to make this more convenient to use for ordinary users. Ordinary users think that the Private Use Area is something entirely different to a set of code-points set aside for OpenType Glyph Substitutions or whatever else the font designer might want to use it for.
  • SiDanielsSiDaniels Posts: 201
    I think it is time for OpenType/Open Font stakeholders, and volunteers, to organize an effort to produce an open, standardized reference UI for font features.
  • Bhikkhu PesalaBhikkhu Pesala Posts: 82
    edited February 3
    SiDaniels said:
    I think it is time for OpenType/Open Font stakeholders, and volunteers, to organize an effort to produce an open, standardized reference UI for font features.
    There are a lot of registered tags for OpenType features. It would take a long time to arrive at any consensus.   
  • Thomas PhinneyThomas Phinney Posts: 703
    edited February 4

     There are a lot of registered tags for OpenType features. It would take a long time to arrive an any consensus.   

    Many features can be grouped by commonalities in how they work and apply. Aside from language-related features that should happen automatically and need no interface at all, the number of distinct groups that need different treatments is not very large.

    Simply defining and enumerating such groups is itself a key part of the work (call it stage 1), and I don’t think consensus would be hard for that.

    That said, arriving at consensus on interface (stage 2) might indeed be hard. But I don’t know that the reference UI itself needs to be driven by consensus.
  • James PuckettJames Puckett Posts: 1,363
    The problem with an OpenType UI as a volunteer project is that there's no money for user research and testing. Without that we could end up with lots of developers implementing a design users hate, and the situation would be no better.
  • Thomas PhinneyThomas Phinney Posts: 703
    edited February 4
    On the one hand, I have to agree that user research and user-based testing would be very helpful.

    Yet, despite that.... Absent a designed interface, you'll get a menu-driven monstrosity users hate anyway. The interface can't get much worse than what happened in Office and Creative Suite.  :(

    Plus, compiling the stage 1 info is independent of the actual UI, but important to have prior to defining that UI.
  • yes, it is user research, interaction design and user testing that is needed, on multiple UI platforms (desktop, tablet and mobile).

    it is UI infrastructure work (‘just deal with everything for everyone’) which makes most people’s head explode when just contemplating it. I guess that is reflected in that no one wants to talk about enabling (i.e. budgets) these kind of projects. I have experienced that before; it is typical for infrastructure.

    so although it is 21 months ago that I got involved (by request) in this, and did last year preliminary work for TYPO-labs—getting a good feel for the complexities and the disgust in the font designers and typographers world that this is still an open issue—I have not been able to get the stars aligned (i.e. a budget) and make this a serious project.

    I look forward to seriously work on this, I would appreciate any help in getting towards that goal.
  • Bhikkhu PesalaBhikkhu Pesala Posts: 82
    edited February 13
    I would appreciate any help in getting towards that goal.
    If you take a look at how OpenType features work in Affinity Designer for Windows (or Mac), it might give you some inspiration. Since it's a new program, designed by Serif who implemented OpenType support many years ago in PagePlus X5, their developers have some experience to base the design on. Dave Harris is the man when it comes to typography.

    His response to one of my threads.

    However, so far it does not support Complex Text Layout for Asian scripts. 
  • sure I can look at how program X, Y or Z does otf UI… there is a time for that in any structured design process.

    my request for help was for enabling such a project—for instance by getting the main players at one table and get each to chip in their share of a design budget.
  • SiDanielsSiDaniels Posts: 201
    I might be inclined to start by contacting Vlad at Monotype and suggesting that a subgroup be established under the umbrella of the Open Font Format working group to work towards developing reference UI(s). Perhaps with a meeting set up at TypeCon or ATypI where interested parties could get together and come up with an approach. That would likely draw the main players to the table, where funding would be one of the issues to discuss.
  • TypeLab in Berlin is coming up in early April, seems like the next good venue for this 
  • hey SiDaniels, thanks for that initiative.

    TYPO labs takes place literally at the end of the (short) street where my studio is. joining the discussion should not be a problem.
  • Adam TwardochAdam Twardoch Posts: 198
    edited March 14
    I had some conceptual input on the UI implementation of OT features in Affinity Designer, in Corel Draw X5, in Mac OS X and in the CSS3 Fonts syntax. 

    I think the advent of variable fonts means that there is a chance app developers will be revisiting their font selection UIs. I think the best community effort would be to debate and prototype UI for font selection in general.

    Discussing a UI only for OT features is a bit like discussing a UI for color brightness and saturation without ever thinking of color swatches or different color models. 

    I think most users are interested in **getting the desired type**, not applying OpenType Layout features.

    Whether the desired type is specified via picking a family, picking a static style or a dynamic variation, applying a feature or specifying an external numeric parameter such as size, leading or tracking, is somewhat secondary. 

    Also an important aspect is glyph input. For example, today, keyboard layouts seem to be completely disconnected from any notion of typography. There are virtually zero methods to input combining marks on any platform, and entering 90% of Unicode characters is extremely difficult. 

    If I typeset a text in Russian, in a bold sanserif font, and I want to use a horizontal rightwards arrow that visually matches the text, I don't really care if that arrow comes for the same font as the Cyrillic letters, or from a completely different one. But currently, it's virtually impossible to find and enter such a matching arrow, in all systems and all apps (or it requires you to use several apps). The fact that it's then tricky to choose the OpenType swash variant of such an arrow is almost secondary. :)

  • I agree with Adam that ot features is not the only problem with type specification today, nor the top level concept. 

    However I'm even less sure how to quantify the impact of the other issues...
Sign In or Register to comment.